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. 