UE4 Scripting Language

Most existing languages weren’t written specifically for making games, let alone integrate fully with UE. To be useful, they would need to be changed so much that they would no longer conform to whatever standard defines them (which also might cause issues with whoever defines that standard).

Sometimes it really is better to reinvent the wheel, if you’re trying to do something that wheels weren’t designed for.

Fortunately, Epic just bought a company that created a language that was written specifically for creating games and can integrate with UE4.

Yes, but they didn’t make any official statement about new hires working on new language. That is just general assumptions.

From my understanding they are still just working on editor scripting tools for VFX studios. While there’s no official word about a runtime scripting language, to me nothing has changed.

And the reason why not C# or Python have already been discussed. They have their own GC environment, Unreal have its own too. Two GC systems on a professional game engine would be irresponsible and plain dumb thing to do.

The creators of Blueprints can help with this, no?!
Why not develop an scripting environment that makes use of the already existing Blueprint Kismet Compiler, instead of forcing an “alien” isolated system, ignoring the fact that Kismet Compiler already exists…

Yes, it is an assumption that a scripting language is being (or will be) worked on, but in general you don’t buy a company that specialises in a particular product or service in order to put them to work on something unrelated.

Actually that’s quite common practice: talent acquisition. Especially if given talents are experienced with your product/service.
And Epic is very hungry this days, i.e. they opened small offices in Stockholm just get engineers from DICE and other Swedish studios.

Speaking of Python, it’s simply to slow for video games.
It’s usually used in content creation tools because it’s super fast and easy to write scripts, saving a lot of time while working on asset.

However it’s the popularity of the engine that may also be behind the idea of “making it easier”, I came to Unreal specifically for it’s strong C++ stance, I don’t want to deal with C# around here honestly, C# is fine in a Winforms/WPF applications, just don’t want to deal with it in what is suppose to be a high-caliber engine.

Aren’t other engines focusing more on developer comfort, I don’t like one-for-all solutions, UE4 should take the HARDCORE path and focus and improve the capabilities of and all of that can be improved and polished on the developer usage side without making technical sacrifices.
[HR][/HR]

You have projects like Dolphin-emu that go strong on doing everything in C++ and it’s not the end of the world, it all works out, you don’t need Qt’s XML or UI files, no need for the Qt Creator, only a base Qt build libraries and runtimes for a total of 120MB is required that you don’t even need to install externally, it’s downloaded as a git repo submodule, it all works out of the box. Yes it’s not as convenient in development where you can visually build the GUI, but it’s not a big deal, some people and I like it that way, this is what some people forget that the convenience is a tradeoff, you may get some convenience here and lose it somwehere else, not to mention technicalities.

I once wanted to join a C# open source project once, it was an absolute nightmare dealing with nugets and dependencies that the whole VS2017 would just **** out, maybe I wasn’t skilled enough to figure it out, despite so many attempts, a clean reinstall, clean nuget cache, following all the steps, nothing would work. Sure it may have not been the project’s fault it self, but the project OPENED IT SELF TO THAT RISK BY WANTING CONVENIENCE OF FASTER PROGRESS by using so much external code that it would be hard to keep track of everything when maintaining, things could clash, etc.
[HR][/HR]

People should make the convenience opinions clear, if something in C++ takes 5 minutes and it could take 3 minutes in MAH-ULTIMATE-MIDDILE-LANG then it’s mosts likely a very cheap argument/reason and those people need to EXPLAIN themselfs if their reasons are strong enough, if something that should take 5 minutes takes 30 minutes in C++ then that’s more of a valid reason and they should explain it in detail so that they are understood correctly.

EPIC has to be cautious at invalid or at least very low-effort reasons such as “oh I’m used to C# in my 1st grade student class and I want it in UE4 too” well no, Unreal Engine should not be your class mentour or your babysitter either. Unreal Engine should strive for HIGH-END and not appease to every newbie student out there, please. When people get in something new thay have lots of ideas and some of the solutions for their problems may exist they simply having discovered the whole environment yet, it happened to me many times where I wanted some feature only to be told another feature would do that more efficiently/differently and it already existed.

It’s all a viewpoint and balancing too, having something in the middle to maintain takes the resources away from improving the top, making it a “self-fullfilling-prophecy” sort of (proper term?), to solve it all you’d have to do is to wait until it matures or the developer’s skills mature, so it may be all down to unwillingness to learn, and this has to be developed with that in mind that the middle-language needs to solve GENUINE inefficiencies in the C++ and/or BPs without it being solely a convenience reason.

This is not about some kind of bad will against developer convenience or newbies, it’s about protecting UE4 image and honor and ultimately the brand it self. When you put that epic logo on the trailer or a brand new tech demo you want that “POWERED BY UNREAL” sound masterful and professional, ultimately it’s representing the great professional community of architectural design, film industry, automotive industry, you want it sound bad-***.
You don’t want it to sound like “POWERED BY PHP-4-KIDS”, right!?
There is enoguh of the industry professionals and I do not believe EPIC has to hunt down every random student who are ALWAYS biased toward WEB stuff encouraged by the universities/courses.

Let me quote one professional you most likely all know about, John Carmack once said that “the magic that runs the web is scarry scarry stuff” commenting on how inefficient and broken the WEB infrastructure is, it’s not anything a skilled programmer focusing on performance would do want things. (paraphrasing as close as possible, he said it in one of the quakecon keynotes, it think in the WEBGL segment, John Carmack on WebGL, JavaScript and the Web platform at QuakeCon 2012 )

But the WEB has lower skilled target audience, it may be that that’s all there is to it, the audience is okay with the bugs and inefficiencies, they aren’t striving for anything better so that’s what allows the developers to be cheap. They want things faster and broken, they seem to be fine with it, but we shoild want things GREAT and WHEN IT’S DONE in UE4 and we shouldn’t let this couch-potato lazyness phenomena seep into UE4.
THEY SHOULD LEARN TO OUR STANDARDS!!!

It makes sense right: The LOGO and the MOTTO has to represent the DEV community, not the target end-user audience, it’s about who made it, and if those tech demos and big game releases are made with C++ with some ASM cherries on top and 200 professionals then they most likely used all the advanced features in the editor and did not rely on all the shortcuts and compromises, so the image should correctly and justifiably have the bad-*** professional feeling to it as it has to represent that high-grade work and effort that was behind it.

[HR][/HR]

I just would agree with something that would make sense for UE4 and that it would be specific to UE4, but not so alien, but it should be thought out and I really don’t want it to resemble anything from the world of WEB, it needs to have all it’s UE4 high-caliber terminology that makes good technical sense without any gimmickry that someone pulled out on a raining sunday, the namings of some open source projects are horrible sometimes but then it sticks and when a project is big everyone’s forced to use the established terminology and scared to it, UE4 shouldn’t have those restrictions “oh the devs are used to that” while it’s clearly wrong, however, the main point is also that it works well with the engine that it doesn’t put any additional concern or steps for the people who wouldn’t need or refused to use it.

I would also hope that it distances it self from the WEB, because the last thing I want to see in UE4 is some kind of JavaScript or some lookalike (similar syntax), it’s like taking a Ferrari and splashing pigeon droppings on it, I’m sorry but that’s how it feels, the WEB has it’s own place, as if it’s not big enough already, they don’t need to take over UE4 as well, we just need our HARDCORE corner where I can relax without having to look at gimmickry.

There could be a rule for this middle language, that it must not hamper the engine’s capabilities in any way, and also that it doesn’t take over the whole development process, it should be some kind of a helper when it comes to repeating a ton of similar code, repetitions, something that would solve those specific things very good, cause they you have yet another way of making almost everything in then most people would start with the easiest way and have all the tutorials and focus on that, then more people would start asking “how do you do this in C++” and “how do you do this in blueprints” which makes those people somewhat forced to also jump on the middle-bandwagon and it does not promote diversity, as the most popular side is going to pull things in like a magnet, newcomers come and guess what, if most tutorials and most people are talking the middle language, then they would skip to it and out of convenience again never find much of a reason to progress.

If everyone had some kind of inherent tendency to always improve it would be different, the key problem is they DON’T move up, they keep themself’s inside that convenience bubble, which is a magic circle again, their lack of interest to learn C++ reinforces their opinion about how they find it hard to do something in C++, and that goes for everything else, but I’m using C++ as an obvious example in this case.

All those skill-based reasons for convenience need to be filtered out and not taken as seriously as the genuine inefficiencies in harder languages/systems, that’s one of the TLDRs

Hi, guys, has there been any news on the IL at GDC? I was hoping that Unreal would make some sort of announcement but I wasn’t able to find any. IL,

I think it is the last missing link in Unreal Engine. I really hate to see ~90% of the Marketplace Assets are written in BP and they seems to proud that it’s 100% BP. BP makes sense for procedural stuff but not for the logic. People cannot help but abusing it too much, to make an appeal to non-programmers. And even the well designed BP is unreadable, let alone maintainable in my opinion. Epic should act fast to save us from the BP hell.

Thanks.

Blueprint have given me the opportunity to have two games in steam.
I do not think I could finish the games using the archaic linear programming full of stupid grammar rules but I guess not everyone is smart enough to handle the logic behind that party of lines and boxes.

I’ m mostly an artist who likes to script. As I love node based systems like Fusion, Houdini and so on, Blueprints are perfect for me. I probabely would never touch anything else. But I still would like to see C# integrated for the following reason. I had contact with lots of companies who are now starting to get into the realtime business. Mostly for product, automotive and architectural visualisation. Most of them go with Unity for the simple reason it uses C#. I recently got a comment like. “Well yeah we only use Unreal if we really need the best graphical quality. For everything else we use Unity because of C#”. It ‘s simple, there are lots of people out there who are more into programming than I am that don’ t like node based systems but also think C++ is a bit of an overkill. With C# beeing added to Unreal Unity would probabely seize to exist :wink:

I keep reading “C# is simple, and C++ is overkill”. The truth is you rarely even write in pure C++ in Unreal. The standard language is wrapped in so many Unreal structures, data types, etc… Scripting gameplay in Unreal C++ isn’t harder than in Unity C# if you’d take into account you have full source code here.
Obviously, UE4 is still missing fully working “live recompilation” - will see if LiveCoding++ coming 4.22 in experimental state is solution for this.

And you need think get some practice in using 2 languages/IDE: C++ and blueprints. And know people wants to add C#. It actually would complicate most of stuff in project. Adding C# would duplicate C++ with advantage of little simpler syntax only…

Programming language is just a tool. There’s no huge difference for professional programmer between Unity C# and Unreal C++. Just get Visual Assist plug-in to Visual Studio to work efficiently with huge C++ codebase.

And I’m saying this as technical designer, guy who switched from scripting languages and Blueprints to C++.

Been thinking about this again and sad that Epic didn’t announce anything yet.
Seems like Agog guys were really hired to develop Editor’s Python scripting and no scripting for runtime…

A complete “wrapper” around the engine like C#, I have absolutely zero interest in; but something to facilitate modding support would be good.

Something like a “scriptable game framework”, exposing to scripts only the classes that deal with gameplay code and nothing else, allowing us to load those scripts at runtime. Would be halfway in to let us build a visual scripting feature in-game for players to use.

Python has smooth syntax, but even a single integer variable in Python is like an entire UObject*, everything in Python is heap memory, that’s insanity.

I think something about this can move forward, but with mix of things - Epic probably can announce something on initiative lightly funded by them, but it is done by pool of outsiders… So it is not official, but Epic does have interest in it…

My personal preference is lua or anglescript or something like that - very fast, very light but make sure it has debugger (I think there are good IDEs for lua out there). Epic can probably license it for UE4 uses. One of my big gripes with BP is it is not easy to diff (ie you have to know quickly what are the last changes).

Edit:
Why I am not so favorable toward C# is because yes, it is powerful but to support it requires a lot of effort. That can easily hamper C++ development (resources are spent a lot on C#). If we are to create 3rd ‘language’ for UE4… it has to be different. Consider these:-

  1. C++ is hardcore, you can do pretty much anything with it. The fastest code is achieved here, but you need good machines and skills to use it.
  2. BP is for artist, prototyping or in fact production code, but not in critical areas.
  3. Third script (my preference: LUA) is meant for programmers, but can be very quickly executed, and can even be authored/modified in packaged (package differently). Can be diffed of course!

It doesn’t mean anything though. They could spend year on research itself with announcement at all. And show off scripting environment when it’s ready and other parts of the engine have been changed to work well with it.
They didn’t announce Chaos until it was ready to create demo with it.

Fingers crossed :slight_smile:

Came back to unreal after awhile and I was a big fan of skookum before, but didn’t go all in because it was third party. Can’t believe they sold to epic and it’s not even updated anymore…

And it should not add more external bloat and runtimes, less bloat then better it is to manage engine itself too in far future. Integrated out of box solution would be best.

I was learning about NetCore5, they say it is “compact”…
Maybe it is when compared to Mono, but it’s still “another world”, there’s no way to have CSharp integrated for real without creating a separate C# engine inside the engine just to run C# code zzz

I finally manage to read the lastest messages that you guys have posted and is good to see this thread back to life because yes, we, really, need something like this, what it needs to be done is not a one step proccess (i mean, ofc it won’t be like that), what i propouse, and what i have talk to with UE4 developers and Evangelist is this.

  • Epic should fork/adopt an IDE or a modulizable text editor (say VSCode/Atom/Sublime Text), that is hopefully FOSS (Free and Open Source) and start working to make the best integration with UE4, this way the Engine can be even more cross-platform (for the Linux users) and easier to use, my suggestion will be to use KDevelop, second best option VSCode, KDevelop already has a plugin for UE4 and is FOSS, develop by the guys at KDE (who also work on Krita which reciently got an Epic Mega Grand boost), in my opinion is the best option
  • There should make a new language that integrates the best of the necesities for the Engine, i want to mention Haxe for this one, they decide to go that route, their system is focus not only in gaming, but in crossplatform development and modularity, on this system games like Dead Cells were develop, the guys at Godot follow this path to, they first start with python but after realizing that it didn’t cover much of their needs they decide to make the GDScript which has a similar syntax to python, the language should have a syntax similar to C like languages (C, C++, C#, PHP as example) and cover UE4’s needs

This way we get the best of both worlds, we have a runtime coding system that doesn’t rely on third party dependencies that cripples the engine which, is a huge issue and we not lost connection with low level development

A guick glance at their website seems to suggest Haxe is good, and there is even a github (GitHub - proletariatgames/unreal.hx: Unreal.hx: Haxe Integration for Unreal) which integrates Haxe into UE4… interesting

Haxe + Heaps is impressive.
But there are things in Unreal.hx in particular that I don’t like, it’s the same issues of having Python or CSharp, they introduce a parallel world with a blackbox virtual machine and another garbage collector.
And that is part of the reason why Epic removed UnrealScript so not sure if it fits, but if Epic is really not working on anything Haxe would be in top of my list as well, because HashLink code can be compiled down to C files when packaging a final build, that alone beats all the other alternatives.

Would be perfect if they tried to integrate their code with Kismet tho, so we could code in Unreal.hx → gen K2 graphs → nativize blueprints when Shipping. That would make easy to access functions and types declared from scripts in graphs like they were created in blueprints… but seems like nobody of these third-parties want to go that much deep into Unreal Engine, they want their langue to be as global as possible so I still believe that Epic should make their own, integrated to Blueprints and their Kismet Compiler.

Unreal.hx is not really running through a virtual machine. The Haxe code is compiled directly to c++ so in the end the result is similar to writing c++ yourself. Meaning you have access to the full native ue api, and will run at native speed. Yes Haxe has its own garbage collector that will run for specific parts but this will mix with the ue4 GC. But, it is possible to compile specific parts of code to run via cppia, a virtual machine you can use for rapid prototyping and development but when packaged this will also be compiled as native static c++ code and not running via a VM.

Its a really good solution all in all, and works different from C# and Python integration. The only downside as of now is somewhat longer compile times because of the integrated Haxe toolchain for static code, and the need to have the plugin updated to work for each new engine version.
​​​​​

​​

​​
​​​​​​

Would it be an option to develop a language that’s just syntactic sugar over C++, and compiles to C++? This would obviously be a middle ground, as the “syntactic sugar” can’t go too far with changes to some fundamental concepts. But it could potentially make C++ programming much more pleasant, especially if coupled with a good IDE with code completion etc. (I’m not sure if “syntactic sugar” is the right expression here, I hope you get my noob point)

My experience with what I’m talking about is Kotlin, just for comparison’s sake. It’s a great language that saved the crude Java world for many people. It is interoperable with Java and uses the same virtual machine. (By the way, it can also compile to native code, but from what I heard it’s not performant enough yet to suggest it here.)