The documentation definitely needs to grow. Online documentation is coming including more example scripts, video tutorials, etc. Until then and after - we are very open to give support and respond to feedback so please let us know any problem areas you have and how we can help.
We are still hooking up some of the error handling mechanisms to the Unreal Engine assert system. It should help once this is in place.
Since you are in the beta also please enter any problems or learning pains that you may experience in our bug tracking database and we will jump on it. Or the new (as you have done), this UE4 post, email, etc.
The next beta update should go out either by this week or the next by May 19th. If you haven’t already, please follow the instructions here and let us know that you would like to be a part of it.
We have definitely made a lot of progress and there are a number of interrelated changes that all need to be in place before we can put a new beta release up. As mentioned previously, one of the more significant updates is the plug-in has moved from around 180 engine bindings to almost 6000.
uploads/default/31/1e66268a4381dcca.png
We’ve added to our team and now have 3 full-time software engineers working on the plug-in.
After the next update the plan is to start the open beta and to make the plug-in available via GitHub so people can have access to more frequent updates - and also offer patches of their own to share for everyone’s benefit.
The zany mad scientists at Agog Labs have unleashed a new and megalomaniacally improved beta drop of the Unreal Engine 4 Plugin, the script-tacular power tool that will revolutionize how video game developers work with Unreal Engine 4!
/images/blog/-ue4-plugin-view.png
Since our last update we have worked day and night (not to mention the eerie twilight hours between day and night) to make more than 300 changes and additions to the UE4 Plugin, to integrate deeply and elegantly with Unreal Engine 4 and drastically improve user experience. Of particular note, we have hooked into the UE4 scripting reflection system (the same used for Blueprints) to provide you with close to 650 new classes and 6000 new engine bindings.
It has been a while since we posted here about the UE4 plugin - things have progressed significantly.
Code plugins are coming to the Unreal Marketplace soon and we’ve just started participating in the submission process for the plugin.
In the meantime, if you are interested in more information and updates, the has become increasingly active and we continue to give out the latest release of the UE4 plugin for those that sign up for the beta.
Any struct (such as HitResult) can now be passed into Blueprint exposed functions, and be returned from Blueprint exposed event nodes
Default arguments are now generated for all UE4 engine functions labeled as BlueprintCallable, so you don’t have to specify each and every argument any more when you call into the engine from
Plus the following minor updates, improvements and fixes:
changed class method Name.none into constructor Name!none
after class is updated remotely from the IDE, any Blueprints that have errors are recompiled as such errors might have been caused by improper script files
pretty formatting of generated method parameter list
export all valid structs and enums known to UnrealHeaderTool at header parse time, not just the ones referenced by exported classes
removed Vector and Plane - parented to Vector3 instead
fixed include path issue with iOS build
numerous bug fixes making more stable than ever
**
Get your hands on it**
If you are signed up for our closed beta, simply click here for further download instructions. If you are not signed up yet, join our closed beta now!
**
Updated demo projects!**
The syntax makes me feel a little uneasy especially due to the lack of documentation. Versus the amount of documentation of C++ how does compare (free version) to writing in Unreals API with C++ for missions, AI, UI, and so on? The syntax just seems very hackish compared to regular C languages syntax which makes me question if this is a good idea to push my programming team into when we may be better off keeping to a language that has a larger documentation regardless of how C++ deals with Unreals API in difficulty.
I’m trying to make the decision of transitioning a team project and coders (beginners and experienced) into this language and it’s mainly these things make me want to stray away from it (syntax, documentation, and limitations of free).
This is just my opinion on the syntax btw, before anyone starts on me about programming language syntaxes I get it, not all are the same. I’m speaking from my perspective and my teams who are not used to a language like this. I’m simply concerned about what the pros and cons are in investing the time for everyone to learn a language in the long run since it’s my responsibility and before I decide not to choose Skookum I would just like to know for sure of how soon will documentation be fleshed out, and the languages limitations on core mechanic development for free users.
We understand this and respect the position that you are in. The language you work in can be a big decision. Hopefully it will be “decide to choose Skookum”.
We are working to ensure that this choice will become easier to make (our goal is for it to be a “no-brainer”) and that once you choose you feel better and better about it as your project progresses.
**Documentation
**
Fuller documentation is being written right now. An initial primer/tutorial should be available by the end of this week.
Please feel free to ask any additional questions you may have either here or in the forums -
That being said - you can get up to speed with quickly and it is a great experience to develop in it - for both beginners and experienced.
The AAA projects that have used it so far did so without a manual. (Having one is better of course. It was an in-house tool and those almost never have a manual.)
One example I often mention is that one of the mission designers on a big team (Sleeping Dogs) was expecting to use the world editor for their job - primarily placing 3D objects in the world, changing their settings, making some links, etc. The world editor wasn’t finished yet (it was their own custom engine - though it was using ) so he was told to give a try. He was daunted since he had never done any coding before. After some encouragement he tried it out and after looking at a few other mission scripts (no manual) he wrote 3 of the core missions in just two weeks. Everyone thought that the missions were fun and were asking him to give advice on how he had done it. So he went from never having coded to sophisticated AAA mission scripts in just 2 weeks using .
In this vein, we are in the process of making more example levels (with code to examine) and tutorials that will help you though the process.
Here is the first in a series of video tutorials (there are currently 8 tutorial videos online) that you can also check out. These are just a first pass - more are coming with greater depth.
://vimeo.com/145168771
**Ease of use
**
I really like C++ and it is what itself is written in. However, writing game logic with is way faster and more power per line of code - especially with concurrency. Perhaps just as or more important in is that the turn-around-time of your workflow is almost instantaneous and this has a huge impact on everything. Even though C++ is very close to the metal of the computer, I find that it is often easier to write more efficient code in since it is easy to spread work over time.
Writing concurrency in a logical iterative fashion is ridiculously easier than trying to write re-entrant code or with OS threads and mutexes and semaphores. The C++ coders on teams were often surprised to learn that missions would have hundreds of simultaneously running tasks and the whole game would have tens of thousands - and nobody’s brains melted.
I can’t imagine doing missions or AI without - and people using it for UI said that it was a fun experience.
The best practices for on UE4 are something that depends a lot on the type of project that you are creating - though I’m certain that your development experience will be better with the addition of .
**The syntax
**
The syntax is definitely different.
Rather than being hacky or random - it is the result of a lot of evolution on many teams and projects. It borrows from many other languages and most importantly describes new concepts that don’t exist in other languages - so new syntax is also necessitated.
One of its biggest oddities is that it uses square brackets ] for grouping. This is actually by design. It started out using square brackets since it was initially patterned after Smalltalk which also uses them. On one project we experimentally changed them to use curly braces { } such as C++/C#. The results were surprising - people made more mistakes. If you were working with both and C++ code your brain didn’t change gears and people would try to write C++ in and in C++. If the languages are visually different at a glance it is easier for people to switch between them.
The goal of is to make the time - after you know it - much easier. Getting to learn it is a small fraction of the time compared to the time you will work with it afterwards - so that is where we optimized things. The learning ramp up time is still quite fast.
Using is not an all or nothing decision.
It works great with Unreal as a powerful command console. While your game is running, you can change settings, create objects, teleport characters to different locations, loop stuff, etc. Fairly sophisticated logic can be done in just a few lines - even setting up whole scenarios or tests.
Most people working with use this as a means to evolve up gameplay ideas. Try a couple of things, make a few changes, try again, etc. until they quickly get to a polished hunk of code that they want to keep. This could be used for prototyping or just put the polished scripts in a routine that you keep for later use.
This alone is a feature that is worth having on your project.
The shipping gameplay can still be written in C++.
I think that you will find that people will just stick with for the shipping gameplay. Many projects assume that they will rewrite routines that need to be especially fast as C++ though I know of no team that has in the end felt the need. This is even after profiling - is plenty efficient. It is heavily optimized C++ under the covers.
You can pick the best for any particular situation - , C++ or even Blueprints. I recommend a hybrid approach. Certain languages are better in certain situations and is an embedded language that can easily call C++ or be called from C++ and the same with Blueprints. No need to limit yourself. Unreal Engine 4 is a pretty rich environment with many C++ functions bound into scripting so it may be possible to do everything or almost everything with just or Blueprints - though again you can decide what mix works best and this is an advantage.
**Standard (Free) vs. Professional (Paid) IDE versions
**
The runtime is exactly the same for both Standard and Pro IDE versions.
The primary difference between Standard and Pro is that Pro has more sophisticated debugging. Most people on a project that aren’t creating missions or interactive audio, etc. will not need sophisticated debugging - they will just use the SkookumIDE console.
We are frankly setting it up so that the Standard version is very powerful. There must be some reason reason to pay for the Pro version and most scripting systems have horrible debugging (and no IDE) anyway so the Standard IDE is still way better.
You can also mix Standard and Pro on a team - they can read and operate on the same files, connect to the same game runtimes, etc.
If you have some concerns about Standard vs. Pro - please just ask.
** in the future**
Another advantage of is that we are in this for the long-haul. There is a team of nuts out there (us) who will be doing everything in our power to make game development more awesome and add it to - and to use these awesome features you will pay a fraction of what it would cost to make it yourselves.
We will be adding many more language and IDE features that really help game development. Other languages like C++, C#, Javascript, Lua, etc. are general purpose and will never be biased towards games as will continue to be in its evolution.
I hope that you will give the to change how you develop games for the better.
Thank you for your time, it’s actually really tempting and I’ll actually now consider doing some test and see how it compares and the possibilities for us in the long run (this is why I worried about documentation). My only question now is if the Skookum editor will be broken down and possibly editable? As great as this language sounds I do a lot of UI design and the first thing that catches my eye is the environment I work in and how clean it is or how customizable it is. Nothing that will effect me majorly in my decision but something I think that would be great to know.
We strongly believe that the development environment can be just as important as the actual language.
The SkookumIDE definitely looks a bit… dated. This is primarily because we have been focused on the underlying tech.
Don’t let that fool you - under that dated look lurks a lot of power. Particularly focusing on having a quick turn-around in your workflow.
The fact that the SkookumIDE can connect to any platform and send live commands while a game is running is huge for productivity. Take a look at the SkookumIDE Console and its Workspace Window (REPL) - /docs/v3.0/ide/console/workspace/ It changes how you develop the gameplay, UI, tests, editor commands, etc.
This is just scratching the surface since you can also update routines and whole sets of classes at once - all while your game is running. And we have lots of plans to make this area even more powerful - making the development system work on your behalf.
The SkookumIDE is lagging in a few areas compared to all the amazing text editors that are out there - but again it is designed to work with other tech. If you hit Ctrl+E while in the SkookumIDE Editor it will automatically load up the file you were working on your favorite text editor [SUP]TM[/SUP] that you have associated with the .sk extension. And it is easy to make Ctrl+E (or some other key accelerator) in your favorite editor [SUP]TM[/SUP] switch back to the SkookumIDE.
The SkookumIDE makes it easy to lend its superpowers to other applications - /docs/v3.0/ide/command-line/
All of this is available in the free version of the SkookumIDE now.
Improving the IDE
Of course we want to make the SkookumIDE even better.
We will be updating the IDE to a more modern UI that allows more custom graphics and visualizations. We are currently planning to use the same Slate UI used by the Unreal Editor and evolving it as needed. The timeframe for the new UI has a planned completion date in the first quarter of the new year.
Another major goal of the SkookumIDE is to make much of the functionality of the IDE readily available as scripting commands and to make the majority of the IDE implemented as embedded script commands. This should make the SkookumIDE extremely customizable both for an individual and for particular projects.
We have big plans.
We’ve been working in the trenches of the video game industry for decades and we are passionate about making a better game development experience. This is stuff that we want for ourselves.
Currently the IDE runs only on Windows. We have begun work on a new, slicker cross-platform (Windows, OSX, Linux) IDE though and are planning on having it ready for GDC 2016 (early March).
Looking into the language more I found that you have a price tag on IDE Pro and shows support for consoles…for 15,000. So I’m guessing the free version cannot be exported and ran on PlayStation 4 or Xbox One? I was really hoping the real time editing was the main difference when it would come to this and not the actual compatibility at launch. As much as I want to use this language we can’t afford to pay that much sadly, and it would be better if we kept to C++ and Blueprint if is the case.
Yup it would be a bummer. Indies are indies, no matter what platform they target. Just because they develop for PS4 doesn’t mean they magically have more cash to spend.
We want everyone who can benefit by developing with to be able to do so.
The Pro IDE is only $200 per seat for a perpetual license for that version and it will work with a runtime on any platform. The free Standard IDE will also work for any platform.
The free runtime doesn’t include consoles.
We can make pre-compiled binaries for consoles and give these to indies - this will be reflected in our pricing.
Sure. The big hardware vendors are really opening up to smaller development teams. This is reflected in our pre-compiled console binaries pricing.
Our initial prices include early bird discounts and there will be extras for teams who contribute in the beta.
Hopefully this will address anyone’s concerns with barriers in the form of licensing costs.
Both the Standard (free) and Pro (paid) versions of the runtime and IDE allow real time editing. Both with commands from the SkookumIDE console and with recompiling code on live games.
The Professional IDE has sophisticated stepwise concurrent debugging - the Standard version does not. That is the current difference between the paid and free SkookumIDE.
Both the Standard and Pro SkookumIDE can make games that are otherwise identical and both types of IDEs can be mixed on the same project.
What I meant to say was somehow you managed to allow real time programming via console platform such as a simulation of the hardware but that was an assumption. I been seeing in earlier post about Pro being 200 dollars, will this be covered in the next update and expect project royalties if there are any?
The SkookumIDE runs on MS Windows (and eventually Mac OS\X and Linux) and connects to the game runtime (using TCP/IP) on whatever platform it is on:
Desktops - MS Windows, Apple Mac OS\X, Linux
Mobile - Apple iOS, Android
Console - MS Xbox One, Sony PlayStation 4
If Unreal Engine 4 supports a platform then so will . New platforms should be easy - for example we have already made sure that compiles for Apple tvOS and we will support it as soon as UE4 does (expected in 4.11).
The UE4 plugin beta currently supports MS Windows and Apple iOS.
Supporting more platforms is easy - is very platform independent - we are just keeping things simple during the beta.
The Pro IDE is expected to be $200 (less during an initial early bird phase) and it is a lifetime license for version 3 (with free minor version upgrades) and there are no royalties.
The beta has most Pro features in it. We expect to split the SkookumIDE into Standard and Pro versions around February 2016.
Hey Noolarch, I was introduced to recently and so far really like how it looks. I am an audio person and would love to use this for adaptive music and sound design but as an audio person I use mac. Is there a way to be an early tester for mac? Very excited to see full release of and hope I get to use it soon.
