Epic Is Considering Adding an Intermediate Script Language to UE4 and Why This Is Bad

Hello there.

So, there was an article on wccftech: Epic Is Considering… and then there was a discussion thread on reddit: It seems people at Epic are… An Epic guy left a question in the thread asking people for their opinion:

We’re discussing this a lot internally. We like the idea. We see the introduction of another programming layer as a decision that’s binding on everything we do for a decade or more so we are cautious about quick patchy decisions.

We like the simplicity of C# but we don’t like the impedance mismatch between C#’s containers and managed runtime and C++ data structures. This makes it tough to share data between the C# and C++ world. UnrealScript had a much more direct mapping between the two worlds, yet still the burden of mirroring data was significant.

We love the even greater simplicity of Python but see similar issues there and are wary of dynamic typing. Lua is nice too.

We are generally scared of JavaScript.

There is also the possibility of a custom language, as UnrealScript was, that’s carefully crafted to interoperate with the engine and solve game focused problems.

We welcome all of your thoughts.

I did not have a chance to participate in that discussion, so I am going to express my opinion right in my blog (isn’t a personal blog a good tool for this?)

Well, I think this is not really good. But that’s not that simple. Let’s see the arguments.

From a novice developer point of view this will make things harder. I did dive into new technologies many times in my software engineer career and from my experience I can tell, that having one more layer of abstraction is just an additional burden the Epics give newcomers. You open an UE4 getting started page, trying to comprehend all of the things needed for game developers and you get 33% more information. Now, the question – is that information useful or not? Hard to answer, but I believe for newcomers the answer will be NO.

Seasoned game developers may have a different opinion. And that is what Epic Games trying to find out in the reddit thread I posted above. I am not an experienced game developer, but I still do have a lot of experience crafting software, so I think my two cents kind of relevant here too. And one thing in whole this story really stands out. It’s the documentation or a lack of a good one. Yes, there is a lot of articles and tutorials on their official website but honestly it’s nothing in comparison to what “typical” software engineers have these days. Frameworks, languages, tools – all of them produce a lot of documentations along with their products. If they don’t, then clients will go to their competitors. The Epics on the hand  still need to work a lot in order to make their C++ and Blueprint documentation pass the OKay mark. And now they want to add one more language…

The third side (who said there only two sides) – is the Epic side. What they are trying to achieve here? Let Tim Sweeney from Epic speak for themselves:

One problem is qualify-of-life issues such as the ease of typing in code, iteration times for code changes, and helpful tooling. Most of the scripting languages do well on this front.

Another problem is building bigger worlds and simulations. This is where things become very interesting, and the possibilities are less explored. Part of this is performance; if we can run gameplay code with higher performance then we can update more objects per frame.

UE4 addresses performance with high-efficiency C++ code, and constraints its complexity by running it all in a single thread.

Frostbite goes a step further by multithreading gameplay code, thus more scalability, but that exposes gameplay programmers to all of the data races and synchronization complexity that comes with shared memory multiprocessing.

Unity is exploring an interesting direction with their ECS (Entity-Component System), which aims to escape the overhead of C# by moving data away from high-level objects linked by pointers to much tighter data layout, as is commonly seen in graphics programming and particle systems, and is less explored in gameplay programming. What’s unknown is the productivity cost of recasting gameplay programming problems within the more constrained data model, and whether it would scale to e.g. a triple-A multiplayer game developed by a large team.

Another possible direction for scaling is message-passing concurrency in the Erlang style, running a simulation across nodes in arbitrarily large data centers, in a model where multithreading and distributed computing fall out of the same framework. Much of Improbable’s early work was along these lines. The challenge is that messages are too low-level of primitive for high-level interactions; often gameplay outcomes will need to be negotiated atomically, such as whether a player on one machine successfully hit a player on another machine, with the player gaining points and the other losing health. Negotiating all of these atomic interactions between machines require ever more elaborate protocols, which can be hard to debug. Remember all of those MMO object duplication bugs?

Of course, databases have enabled simple query-and-update languages like SQL to scale to high concurrency for decades. Their strategy? Transactions. By guaranteeing all individual queries are ACID (Atomic, Consistent, Isolated, and Durable), the programmer doesn’t have to worry about data races. The database sorts that out using its own internal logic. Can we extend transactions to general purpose programming as early Haskell research has suggested? Can they scale to tens of millions of concurrent users at 60Hz?

Finally, there’s the question of what the ultimate usage scenario is. Is it a single team building a game, and generally knowing and trusting each other? Or is it something like the metaverse, with a million programmers each building independent components that are expected to interact together under a sandboxed framework where they can’t interfere with each other?

Each of these strategies has a pretty sweeping impact on the nature of a scripting language. The directions that would 2x ease-of-use differ from those that would 4x performance in a single-player game or 1000x server scalability in a multiplayer game

So, as a summary, I don’t really think that for me as a novice UE4 developer this is a good move but who knows, maybe it will turn out really good for all. I will be more than happy to switch to a new script language in preference to C++ if that’ll really make my life easier.