11 ms·

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 ha

by m4nu3l 4y ago

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.

medo-bear 4y ago
> 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://reader.tymoon.eu/article/413 * https://github.com/Shinmera/talks/blob/master/gic2021-highly-dynamic/paper.pdf 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 https://news.ycombinator.com/item?id=32043026
krapp 4y ago
>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.
- m4nu3l 4y ago
  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.
pjmlp 4y ago
>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 https://discourse.haskell.org/t/an-epic-future-for-spj/3573
- selfmodruntime 4y ago
  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.
  - deleted 4y ago
    [deleted]
  - t-3 4y ago
    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.
  - badsectoracula 4y ago
    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).
  - pshc 4y ago
galangalalgol 4y ago
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.
- klaussilveira 4y ago
  You're probably remembering Q3's QVM: https://fabiensanglard.net/quake3/qvm.php 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-menu.htm https://www.gamers.org/dEngine/quake/spec/quake-spec34/qc-me... Modern QC compiler: https://www.triptohell.info/moodles/fteqcc/README.html https://www.triptohell.info/moodles/fteqcc/README.html
  - galangalalgol 4y ago
    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.
    - galangalalgol 4y ago
      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.
hackeroldz 4y ago
How hard is Godot to learn? I have no prior game developing exp.
- thealienthing 4y ago
  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.
  - hackeroldz 4y ago
    Thanks!
jasonjmcghee 4y ago
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.
- jasonjmcghee 4y ago
  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 https://www.youtube.com/watch?v=_z7Z7PrTD_M
- m4nu3l 4y ago
  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.
  - jasonjmcghee 4y ago
    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.
    - m4nu3l 4y ago
      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 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.
thealienthing 4y ago
>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.
- citizenkeen 4y ago
  Coming from C#, I couldn't handle the untyped nature of GDScript, and quickly took up its static typing.
  - m4nu3l 4y ago
    It supports optional types. It's not perfect but I use them consistently and it helps.
- elcritch 4y ago
  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 https://github.com/pragmagic/godot-nim There’s also an interesting project to do hot reloading using dlls: https://github.com/geekrelief/gdnim https://github.com/geekrelief/gdnim
jhgb 4y ago
> 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?

by m4nu3l 4y ago

medo-bear 4y ago

> 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://reader.tymoon.eu/article/413 * https://github.com/Shinmera/talks/blob/master/gic2021-highly-dynamic/paper.pdf 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 https://news.ycombinator.com/item?id=32043026

krapp 4y ago

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

m4nu3l 4y ago
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.

pjmlp 4y ago

>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 https://discourse.haskell.org/t/an-epic-future-for-spj/3573

selfmodruntime 4y ago
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.
- deleted 4y ago
  [deleted]
- t-3 4y ago
  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.
- badsectoracula 4y ago
  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).
- pshc 4y ago

galangalalgol 4y ago

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.

klaussilveira 4y ago
You're probably remembering Q3's QVM: https://fabiensanglard.net/quake3/qvm.php 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-menu.htm https://www.gamers.org/dEngine/quake/spec/quake-spec34/qc-me... Modern QC compiler: https://www.triptohell.info/moodles/fteqcc/README.html https://www.triptohell.info/moodles/fteqcc/README.html
- galangalalgol 4y ago
  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.
  - galangalalgol 4y ago
    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.

hackeroldz 4y ago

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

thealienthing 4y ago
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.
- hackeroldz 4y ago
  Thanks!

jasonjmcghee 4y ago

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.

jasonjmcghee 4y ago
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 https://www.youtube.com/watch?v=_z7Z7PrTD_M
m4nu3l 4y ago
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.
- jasonjmcghee 4y ago
  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.
  - m4nu3l 4y ago
    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 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.

thealienthing 4y ago

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

citizenkeen 4y ago
Coming from C#, I couldn't handle the untyped nature of GDScript, and quickly took up its static typing.
- m4nu3l 4y ago
  It supports optional types. It's not perfect but I use them consistently and it helps.
elcritch 4y ago
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 https://github.com/pragmagic/godot-nim There’s also an interesting project to do hot reloading using dlls: https://github.com/geekrelief/gdnim https://github.com/geekrelief/gdnim

jhgb 4y ago

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