I'm currently using Godot 3 for my solo indie project. It's a six-degrees of freedom space shooter. I use rigid bodies and physics very extensively, but what have proved to be very hard-to-remove bottlenecks were the scene tree and scripts.
At some point the game was spending more time on those things that on the physics simulation.
I have rewritten some code in C++ over time and parallelized as much as I can. However I'm starting to think that scripting languages are a false economy. There is no intrinsic reason you can't have a concise and easy to use language that can be quickly (in debug mode) compiled to the metal and dynamically linked to the project.
I might look at godot-rust at some point although It's a bit late considering the amount of code I have written already.
>However I'm starting to think that scripting languages are a false economy.
Yet, Epic after following the path of deprecating UnrealScript in name of C++ and BluePrints, has decided to hire Simon Peyton Jones from Haskell fame, to design their new scripting language called Verse.
I really do not understand game engine designers insistence on inventing a new language for their scripting needs. There are dozens of well built languages that can be used for simple scripting. Just pick one of those.
There are many engines that use existing languages, with Lua being one of the most common scripting languages used by games. However usually when an engine has its own scripting language it is because the existing languages wouldn't fit and/or the custom language can work better with the underlying engine.
For example if a game engine keeps track of asset references, scripts could be themselves assets like any textures, levels, materials, etc and have asset references as literals in the code that the script compiler understands, allowing automatic and precise extraction of asset dependencies the scripts (and the assets that refer to those scripts) can have. This is, e.g. what Blueprint does (BP is just a visual scripting language that uses a graph with a visual editor instead of parsing text to generate an AST but the same idea applies).
- Memory management that doesn't destroy frame times
- Easy to embed, ideally with a small runtime
- Can target whatever ISAs and OS's that the game runs on, like consoles.
There are not dozens of languages that fit these criteria, particularly memory management, embedding, and toolchain support for consoles when you're using a proper JIT compiler and not a bytecode interpreter.
When you are sidestepping the GC and have your object graph mostly in types built in the base language, Lua is no longer a pleasant language to use.
I think UE is a situation where writing a new language specifically for scripting it is absolutely the correct choice. The user base will be large enough to support it properly, and there are a lot of things that are a lot more ergonomic when the language will be built to support them after the base system is already built, instead of the other way around.
My guess is that existing scripting languages don't mesh well with all the parallelized staged simulation, entity content systems, and lack of tracing GC that game engines like Unreal tend to have.
I don't know much about Verse but looking at the preview I already see a type called a type called `<latent>` (async Promise?) and a `race` keyword (seems like a built-in `await Promise.all`?). I bet building these directly into the language fixes much impedance mismatch.
A similar but opposite argument could be made that every application's scripting language will necessarily be a DSL focused on that application, so might as well design a new language.
I suspect they could easily use an off the shelf language, or at least build a language that is a strict subset of one that allows for isomorphic code between that language (if targeting the subset first).
I strongly agree this is a superior approach to a custom language. Even better if the games industry standardized a single purpose fit scripting language
FWIW Blueprint is basically a scripting language, except instead of having you type something like "vector Foo = bar.GetPosition()" it has you create a "variable reference" block, a "variable assignment" block, a "GetPosition" block, a "reference to bar" block and then connect all of those blocks using "wires" alongside a wire that specifies execution flow.
But for all intents and purposes it is a scripting language - the blocks are even converted into an AST-like intermediate representation that is then either converted to a bytecode VM or is used to generate C++ (though the BP-to-C++ conversion generates very weird code since BP allows -conceptually- multiple things to run in parallel).
But the Blueprint "front end" can be replaced with another (text based) scripting language that generated the same IR and the rest would work the same. While i haven't seen UE3's source code so i can't be 100% certain, i'd bet that the IR and VM have their roots in UnrealScript - and chances are Verse is also targeting the same IR.
Verse doesn't sound like it has to be a scripting language though, it sounds more like it's a high level simulation oriented language. Scripting languages nowadays have all the same constructs as typed languages, they just lack types. I would expect Verse to be a whole different kind of language, rather than just C++ without types.
I’ve spent time in Godot and Godot Mono- if you’re interested we could pair and investigate some of your bottlenecks. I’ve managed to remove those that I’ve encountered.
Here’s a simple example of a few steps, dramatically improving performance.
It points to a few great tips- things like, being very intentional about node type, collision layers, monitoring/monitorable, and other concepts like pooling and the physics server.
What kind of game are you working on? I have managed to actually removing a lot of these bottlenecks by parallelizing or rewriting in C++. The ones I'm left with I believe are now more on the GPU side. I'm trying to use portal rendering / occludes for that.
>However I'm starting to think that scripting languages are a false economy. There is no intrinsic reason you can't have a concise and easy to use language that can be quickly (in debug mode) compiled to the metal and dynamically linked to the project.
I’m a big fan of interpreted languages like python and the python like godot script. The power of quickly accomplishing tasks because of their fast and loose nature is great, but as I’ve built up some large repos at work written in pure python, I’m starting to regret the loose typing. Bugs caused by a small loss of data because of implicit type casting have been a source of much wasted time. I’m starting to convert to rigidly typed systems of program just for that peace of mind that any calls I make to an API will not compile because I am not passing the right type. It makes sense to switch to a language like CPP/Rust for big projects like a game.
No, not really. It's not about the 3D capabilities (I have different types of issues there) or about GDScript per se (other scripting languages have even worse issues like the GIL in Python), but the issue I had is that a lot of time was spent doing these:
- Counting references.
- Variant related conversions.
- Resolving methods.
- Interpreting the bytecode.
- Sorting nodes before calling update functions.
- Triggering callbacks etc.
All of these would amount to a good percentage of the time spent in the main thread.
I managed to optimize by a combination of parallelism (gladly GDScript has no GIL!) and by rewriting somethings in C++.
I still have some bottlenecks with the rendering but that should be easier to scale back.
> However I'm starting to think that scripting languages are a false economy. There is no intrinsic reason you can't have a concise and easy to use language that can be quickly (in debug mode) compiled to the metal and dynamically linked to the project.
The Revenge of Lisp strikes again. Yet another reason for why your program should look like a big ball of mud?
I have very fond memories of Quake C. It was a bit more like pascal in some ways than C but the compiler came with quake (the first one with the NIN soundtrack). It had the source for the existing bits of the game that were written in it, which was all the behaviours, and you could change it and recompile to a new dll. It was easy to use and quite performant.
I'm definitely remembering quake1 but I might be wrong about the dll? I remember doing very poor version control copying the dlls into and out of the main folder.
> However I'm starting to think that scripting languages are a false economy. There is no intrinsic reason you can't have a concise and easy to use language that can be quickly (in debug mode) compiled to the metal and dynamically linked to the project.
It’s a very easy and well documented free engine. If you have used and like python, you can learn the ropes quickly. But as OP mentioned there are drawbacks to the loose type system. But I would encourage anyone looking to make their first game to try Godot as it gets out of your way so you can start making your sprites move around and interact with the world.
At some point the game was spending more time on those things that on the physics simulation.
I have rewritten some code in C++ over time and parallelized as much as I can. However I'm starting to think that scripting languages are a false economy. There is no intrinsic reason you can't have a concise and easy to use language that can be quickly (in debug mode) compiled to the metal and dynamically linked to the project.
I might look at godot-rust at some point although It's a bit late considering the amount of code I have written already.