UE4 Scripting Language

Tim Sweeney commented on this reddit: “It seems people at Epic are considering adding some intermediate script language between C++ and Blueprints”
https://www.reddit.com/r/unrealengin…dering_adding/

Posting here so the topic has more exposure.

I would love to see Python tightly integrated in UE4. I think it’s ideal for bridging that gap between BP and C++.

I worked with Unity for a few months and hesitated to make the leap to Unreal because I wasn’t sure my C++ could hack it. At first glance, I was lukewarm about Blueprints because they looked like feeble, fake programming (now I think BPs are superb, btw).

There’s often a cost / benefit analysis performed when starting new project or selecting a new engine…

Python is a standard introductory language in school and is employed in countless projects around the world, So for many, the cost of learning UE’s scripting language is low or non-existent.

Likewise, if you do absorb the cost of learning a scripting language for UE, the benefit is huge because you will have learned probably the most pervasive and widely-applicable language there is.

I know we’ve been through the rafters before on this subject but here’s my 2c anyway. The problem with C# in a nutshell is it’s not massively different from C++, the reason it works so well in Unity is because of their component architecture. Sure intellisense always works properly, compile times are quick, it’s far easier to read and even though UE has MM / GC ALOC w/ C++ so does C#, Unity’s implementation was slow (due to GC) but C# can be very fast (In Xenko and a framework I made with OpenTK it was). There’s apparently memory management options in C# 8.0 as well if anyone wants it…

Standard C# will still confuse beginners and Unity defectors, it’ll add some overhead (which may be a problem or not?) it’s a massive effort to implement (even with binding scan tools) and then it’ll need to be documented. Wouldn’t it be more prudent to just document the C++ API properly with examples? Make sure hot reload works properly, uncouple and optimise some of the convoluted parts of the engine, help with intellisense issues and try to reduce compile times? Although if Epic did the implementation right then sure I’d snap their arm off for it.!

LUA? Nah.! Debugging’s a chore and you have to find issues at runtime, I’ve never once met a programmer who doesn’t do things a little WYSIWYG with plenty of trial and error… We all screw up, if that wasn’t the case UE4 would be completely bug free and most AAA titles with some of the best programmers wouldn’t crash etc. etc.

Python could work there’s a couple of “intellisense” (well sorta) options with pre-runtime debugging, visual studio and Eclipse are both super excellent with it.! Yes it’s a fatter than LUA but worth it.

Custom? Again not seeing the point.

If they go with scripting, its syntax must be easy like Python, but can’t generate garbage like Python does.

And no Virtual Machines, please.
Whatever it is, must be compiled to “Unreal Class” to avoid developers dealing with two separate engines in one.

Then UBT compilation time must be reduced to 300% faster. Otherwise all the effort won’t be meaningful…

I kind of like the idea of making a new Unreal Script for this problem. That is inspired by Python syntax for example, so is easy to use, to read, and to handle, and by that i mean debugging and the like.

Python is obviously not an option, far too slow.

UnrealScript was not easy to debug at all (from a programmers perspective).

I’m not saying to use the UDK’s UnrealScript, I’m saying that a new Unreal Script for the UE4 that is inspire by Python could be an option

I vote for , a language that was specifically designed for games and has been battle tested in games already. Python is not a good fit, its creator made design choices that make the language a poor fit for game development.

2 Likes

I start reading about the and yes, I kind of like it, it looks powerful and easy to use, the thing is, what about the license? I mean, I know I can use free, but is says debugging and other tools are available in pro version and stuff. I still quite yet no understand about the licensing of the tool

1 Like

The license would be irrelevant with epic solving that for everyone. But skookum script syntax/ide is super strange… it has very cool async features but that’s about it

2 Likes

I quite like the syntax tbh, I think is just matter of getting use to it, like in everything, I haven’t use , but I will sure try it out soon

How do you want to make a Scripting Language without a Virtual Machine though?

What I want are three things:
More exposure to Blueprints (maybe “Expose by Default”. So many things are hiddin in C++. It makes even prototyping hard in BP if I don’t have the full functionality.)
Reduced Compile Overhead. Fewer / No Macros in any Source File. Plain C++ code should work with Unreals Memory Management.
Reduce the Base Classes (AActor, UObject, AGameModeBase, AGameStateBase) to the bare minimum of their functionality.
AActor for example is heavily bloated with stuff that should be decoupled into Components.
Replication, Spawning should be the only things present in AActor.
Input, Damage, Navigation, Rendering, Camera are things that should be either put into their respective Components or put into new components.

Honestly, I would welcome something text based with the simplicity of C#. I am just worried that it could come at the expense of Blueprints. Right now, we are in the situation that occasionally one has to delve into C++ even if the intention is to use Blueprints only, because some obscure things aren’t exposed to Blueprints yet.

I am worried that we could end up with 3 levels of that. That the new features would be only half-exposed in Blueprints, with the intention that the deeper usage can be accessed with the scripting language, and then even deeper of its feature would be accessible from C++ only. That could end up very messy.

They build a compiler that generates C++ code instead. Or use the already existing Blueprint VM.

If they add yet another VM then I won’t use it…

Just please, something with static typing, I don’t think it would be handy to have variables that can change their type at any point and class variables that can be constructed at any time, so from me it’s no for python and javascript. UnrealScript “4” would be probably best fit for the engine but new language means new IDE (or atleast plugins for available IDEs), tons of documentation, streams, active support and deep integration into engine and current workflow. Regarding the current activity of epic stuff on forums and community I don’t find this options as best because it would need a lot of epic resources which likely are not available now.

I think that most important reason for scripting language is improving iteration times. Compiling to c++ is amazing when it comes to performance but it would not be that win when it comes to iteration times. Sadly, I don’t find improving UBT compilation time improvements realistic. if they would improve compilation time by 3000% then there would be no need for scripting language.

How is “generaing C++ Code” different than compiling and hotreloading how it is now?

Generating c++ code would result in garbage compile times and broken hot loading and solve nothing.

Reusing the blueprints would be interesting, but not very good runtime performance…

That’s also another reason for adopting , they already had a solid foundation for this. The other topic is about IDE, in my opinion epic should focus UE4 for now on to work best with VS Code, since is a crossplatform text editor that can be used has IDE with some tweaks, it can be extended, and the only thing missing is to UE4 to make the workspace, build, and debug files, files that could be generated has any other VS20XX or XCode file

I wouldn’t expect them to integrate any third-party solutions.
Because this is something that Tim Sweeney enjoy to do it himself. It’s his geeky fixation, I believe he created Unrealscript all by himself as well, I’m not sure tho…