Any plans for another scripting language besides blueprints/C++

Some time ago I think I remember reading something about there being plans for another scripting language besides C++ & blueprints. What happened to that? Lack of scripting other than these 2 is the single largest reason I’m reluctant to use Unreal more. It also doesn’t help that 90% of all tutorials is in blueprints. I feel that C# is the single largest reason so many people still favor Unity over Unreal, so having another scripting system would be very ideal. Unity has C#, Godot has GDscript, and unreal needs something similar if it’s not suppose to lose relevance over time among smaller devs whom don’t have pre-existing experience with C++.

That’s very likely Epic is working on something. Although I wouldn’t expect any announcement until they have something working and ready to showcase. Like with Chaos or UE5 :wink:

I’ve used both engines, and others as well. In my experience, C# gives you nothing over C++ and blueprint, except garbage collection pauses. The reference counted GC from blueprints generally works better IMO.
What’s needed, though, is more C++ help to get started. They’ve made it better (more support in the editor, more intro content) but it’s not quite fully there yet.

That being said, I would be stoked if blueprints could be stored on disk as text files. Ideally, one line per node, propertly, and component, with some simple structure. (Worst case, XML, but XML with good linefeeds so diff tools work.) That way, I could git pull/merge them, and maybe even edit them manually when needed!

When you copy/paste blueprints it is a text code that goes to the clipboard. Not fully human readable because some look like long memory address references and so on… but it wouldn’t be that hard to turn it into a standard text based coding language if Epic Games wanted to.

Wasn’t ready in 2019. Might be now though:

Also, a related thread was just started here:

Lol at “Lack of scripting other than these 2 is the single largest reason I’m reluctant to use Unreal more”… If you are not savvy in C++, just either learn it, or use BPs. I don’t get why people scared of using BPs. The only downside is inability to do proper version control of BP code. If Epic fixes this issue (by storing BP code as code and not binary asset, and perhaps I am oversimplifying this case), there is absolutely no reason to ask for a scripting language.

It’s like saying “I’d use Unity, but because there is no native solution like Blueprints in UE4, I am not going to use it”.

BP visual scripting is a mess to code complex algorithms. It is a huge waste of time. Just like UML really isn’t used to code that much. UE4 C++ lacks updated public documentation … if Epic Games had updated complete documents for UE4 just like Apple does for all of its APIs both Swift and Objective-C then there would be no issue using C++ for everything. If it was possible to write BPs in text form there would have been no real need for another scripting language.

This is not true at all. The only issue with BPs is that they give you more freedom to “write” ugly code, because they don’t encourage good practices as much as the written code does. But person who knows what they are doing, and utilizes functions, macros, and custom events co reduce complexity, can create blueprints much more readable than a written code. It’s just most people don’t bother to, as it’s easier to manage in written code, where you can just shuffle the rows and names around, but in BP you actually have to spend time cleaning up nodes every once in a while.

What doesn’t help is that in many official Epic examples, such as turn based RTS, you can often see giant, ugly, long blueprint snakes. That creates a bad example, but visual scripting is only mess if the user makes it a mess, in the same way text based coding can be made a mess too, if one chooses to.

Here’s one of my marketplace Blueprint assets:…b36c09be17c5c2

It does a lot more under the hood than is apparent, handling many corner cases which could make fences behave weirdly in rare scenarios. Despite that, at the top level, this is how the entire BP looks:

Where the rest of the complexity is encapsulated, as would happen with a written code too.

What makes you think if they add C# it will be well documented ?!

I don’t think this is true. The documentation is generated from the header/source files, and thus is up to date with the latest version.
Also, the documentation for “where to start looking” is much better now that it was a few years ago, so it’s clearly improving.
And if you really need to know what’s actually going on, you can just search the headers, or source code. Ctrl-Shift-F; find in entire solution; this searches the source and headers of the engine, even if you’re not building the engine yourself (the code gets installed with the engine download.)
Ctrl-F12 or Ctrl-1, Ctrl-t are other good navigation tools. There’s nothing like that for Unity, because you don’t get the underlying source, so you just have to guess.

I never asked Epic Games to use C#. C# is just a bad Java clone and Java is a mess compared to C++ to code anything with.

Take a look at Apple Developer Documentation of all their APIs Apple Developer Documentation
Can you see the difference compared to what Epic Games is offering to the public ?
With what Apple makes public it is pretty easy to anyone wanting to code complex algorithms to do it. With UE4 public documents it is a huge pain if not impossible to code properly. Having to waste time going thru the ever-changing source code with millions of lines is just silly… only medium to large software houses can afford that paying 1-2 or more employees to do what Epic Games doesn’t unless full documents are given to large software houses paying exclusive expensive $500,000+ licenses to use the engine for their AAA games. Poor indie developers and small to very small software houses are in pain to use UE4 properly.

My biggest gripe with blueprint is there is no ‘practical diff’ between commits. It is fine if you are a solo programmer but in a team, you always end up asking your teammate - ‘hey what were the changes you did last time with this bp’?

I would be very happy if Epic can just offer something like skookum script - I heard that the guys behind the script get hired by Epic, so maybe they are working on something similar, or improvising…
The complex nature of C++ shouldn’t be replicated for the new script. It should be simple but powerful enough for a lot of programming task.

Eeh, no… Please no. I’d much rather script using plain old C than skookum script.

Why ? Skookum Script just works. A better improved version of that would be way better than any visual programming like BPs. I would prefer Python to BPs as well. Whatever Epic Games comes up with as long as it is well documented and allows access to all BPs and C++ APIs then it would be way better than what it is available right now.

I am not a programmer per se, but when I look at C/C++ code, I kinda get an idea about what’s going on. When I look at Python or Skookum code, I go: “WTF is going on here?! It’s gibberish!!!”

Skookum has been used in shipped games - it is performant and powerful. It even has IDE that you can debug in it - breakpoint, variable watch… name it.


Maybe it looks gibberish because it has to be simple and yet powerful… C may be easier to understand, but it takes many more lines to do the same thing. And do not write off python - its userbase is growing fast nowadays…

I began writing code on the Mac! Inside Macintosh was a bible! And we needed that bible, for two reasons:

  1. The underlying source code wasn’t available (other than disassembling) so we had to trust Apple to document what we needed to use.
  2. Apple was building an API that would never change – a program built for version A would still keep working on version A+3.

Tons of games being shipped by studios big and small seem to disagree with this statement.
Note that Unreal doesn’t define the API as un-changing – they reserve the right to break code between any engine version update.
This is needed to provide the highest performance gaming experience across the targets that are supported.
Building games is different from building an operating system.
Apple-level (or Win32-level) compatibility across versions would be BAD for the vast majority of games being developed, because that level of backwards compatibility comes at a significant cost.
That being said, Epic doesn’t break older code “just because they want to” – when they break it, it’s for good reason. But they do have that opportunity, because of the particular business they’re in.

It’s true; to become a good Unreal Engine user, you need to build up knowledge. This knowledge can take months to build up, just for the particular parts of the engine you care about.
It may be that you personally don’t want to invest in the skill of searching the documentation for keywords, reading the headers, and, worst case, stepping into the source code when you need to know how something actually works.
If you don’t want to, then you can try some other game engine, where you don’t get the source code, and see if the documentation available is more to your liking.
When UE4 was new, the documentation wasn’t that great, and very early on it was even a chore to get the source code. Compared to that, I think they’ve reached a very practical point by now. Is it perfect? No. But “perfect” doesn’t ship games!

And do you think that big software houses have many employees wasting months if not years to study millions of ever changing source code lines then ? They pay $500,000+ per AAA title for exclusive 24/7 support which surely includes way better documents than what is made public along with the fact that they can get custom code written for them at that price. I can’t believe any big software house wasting resources and so money just to create a proper documentation of all the APIs to be able to code with UE4 C++ a … And yes they are paying a lot of money but in that case full updated documents should be made available to everyone just like Apple does if they exist. Apple is not giving big software houses better documents and poor indie developers just incomplete ones.