Hacker News Reader

Comment by m4nu3l | Hacker News Reader

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.

View on HN

>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.

https://discourse.haskell.org/t/an-epic-future-for-spj/3573

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.

You can see how it looks like on these screenshots, https://twitter.com/saji8k/status/1339709691564179464

Afaik it's not known yet whether verse is compiled or not.

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.

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.

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).

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.

There really aren't. You need:

- Fast to compile

- Fast to run

- 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.

Well, there is luajit at least (the GC isn't very performant, but people who care about this sidestep it). Maybe Chez or Gambit scheme as well.

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.

NaughtyDog was able to do amazing things with their in house lisp GOAL[1]. I expect SPJ's work to be in a similar vein.

[1]: https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

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.

You are of course right, I should have phrased it in a different way.

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.

https://www.youtube.com/watch?v=_z7Z7PrTD_M

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.

Profiling is the source of truth. Try setting up a scenario that exacerbates the issues you think are happening.

I've seen shaders cause problems due to branching logic- I'd try disabling them or making them perform a no-op.

I've focused on 2D with Godot, but often with a very high volume of nodes at once.

Of course. I use both the built in Godot profiler and perf.

Which led me to change many things in the implementation and I also ended up patching the Engine multiple times.

One example is this (which I have patched on my Godot version): https://github.com/godotengine/godot-proposals/issues/4050

I profile my game all the time, but sometimes it's not clear if there is a bottleneck or if there are just too many things at the same time.

Also the bottleneck can change in different parts of the game. Sometimes I have removed a bottleneck on the CPU just to find another in the GPU.

>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.

Coming from C#, I couldn't handle the untyped nature of GDScript, and quickly took up its static typing.

It supports optional types. It's not perfect but I use them consistently and it helps.

Another option is Nim. Looks and writes like Python but closer to C in performance. It also has static typing so I prefer it for scripting as well.

People have built a few games with the Nim Godot bindings:

https://github.com/pragmagic/godot-nim

There’s also an interesting project to do hot reloading using dlls:

https://github.com/geekrelief/gdnim

>However I'm starting to think that scripting languages are a false economy.

This is likely more an indictment of Godot's 3D capabilities or GDScript than scripting languages as a whole.

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.

You're probably remembering Q3's QVM: https://fabiensanglard.net/quake3/qvm.php

QuakeC was for Quake 1, also compiled, but not to a DLL: https://www.gamers.org/dEngine/quake/spec/quake-spec34/qc-me...

Modern QC compiler: https://www.triptohell.info/moodles/fteqcc/README.html

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.

Ah yeah, progs.dat. So not a native compilation? The mod I was proudest of I called summoner that let you make a pet shoggoth that fought for you.

> 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.

This might interest you:

* https://reader.tymoon.eu/article/413

* https://github.com/Shinmera/talks/blob/master/gic2021-highly...

and the very recent still front-page discussion on hn:

* https://news.ycombinator.com/item?id=32043026

How hard is Godot to learn? I have no prior game developing exp.

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.

Thanks!

Reply on news.ycombinator.com