7 ms·

Godot felt frustrating to use every time I've tried it, on both 4.x and 3.x versions. Compared to Unity, it was a massive improvement, the editor was much faste

by avx56 4y ago

Godot felt frustrating to use every time I've tried it, on both 4.x and 3.x versions. Compared to Unity, it was a massive improvement, the editor was much faster without crashing, and it had a reasonable node-graph design. However, I think some of the "elegant" designs pursued in Godot and some up-and-coming Rust game engines often end up feeling very time-consuming to fit your code in their abstraction (whether it be ECS or nodes), and honestly sometimes it's nice to just sit down, write some terrible macro-ridden C++ that subclasses from 15 different classes in a hierarchy that would make Alan Kay cry, and get an object that can be scripted from your level editor seamlessly. It's janky, but nonetheless it works.

logicprog 4y ago
This is why I prefer using libraries to abstract away the complicated parts of doing low level graphics, sound, etc over game engines/frameworks. Engines call me, instead of being called BY me, and that forces me to use their whole environment instead of picking just what I need, as well as forcing me to distort the concepts and abstractions that are most natural for how I think about a problem to fit into the existing way they want things to work. I prefer being able to make my own architectural decisions.
- karpierz 4y ago
  Is there a set of libraries you'd recommend in this vein?
  - logicprog 4y ago
    Unfortunately, not really. I don't actually have a ton of experience with gamedev outside of engines, I just know what the failings of engines are from using them for a few projects over the years. The one library I might've recommended is a Rust one that's now defunct.
  - IshKebab 4y ago
    I imagine he is thinking of things like SDL, SFML, Macroquad and so on.
  - eliasdaler 4y ago
    * glfw, SDL - C, low level, require more work to get started with (maybe coupled with bgfx if you don’t want to write your own renderer). * SFML (C++), Ebitengine (Go), bevy (Rust) - high level, easier to use. * LÖVE2D (Lua), raylib (C) - even higher level. And Dear ImGui is a must for implementing debug UI/level editor/tools. And maybe PICO-8 as an alternative (it’s something in-between of a low-level framework and a game engine)
- avx56 4y ago
  I find this hard because games often end up quite tightly-coupled, so while you don't have the pathfinding code reaching into the rendering, the rendering is usually coupled to the game object model and it's hard to make it reusable outside of a specific engine. That and the fact that AAA studios do not want to open-source anything for some reason.
  - logicprog 4y ago
    That's true. That's why if I ever write another game I'm going to write it basically from scratch myself lol, true NIH-suffering indie gamedev style.
    - astrange 4y ago
      It's said that if you start writing a game and a game engine you'll only release one of them.
  - astrange 4y ago
    Open-sourcing commercial code can be difficult because it might contain or use things from other companies that you don't have permission to release. Of course, it might also just be that you don't want your employees to get any fame, but they do seem to be allowed to talk at GDC.
    - avx56 4y ago
      Yeah, I think it's that and the fact that there isn't (obvious) money in fixing up and maintaining code for a shipped game.
- eliasdaler 4y ago
  Agreed. Making custom editors/tools/content pipelines is also much easier when you have your own engine. Of course, you can write custom plugins for some engines, but I always felt uneasy about this - plugin API always breaks and you need to learn a lot of specifics of the engine to make something non-trivial (which is hard, because those engines are usually gigantic in scope). The downside of making your own engine is that it’s usually gets more fun to develop the engine itself than games with it…
LanceH 4y ago
I get where you're coming from, and there is always a certain hackiness to game code it seems. But I've embraced godot for 2D games and it has been wonderful. I get more code reuse out of the node system than I ever got out of class hierarchies elsewhere. I find myself with the time to set up a lot more test scenarios where I can play two things side by side to find the better feel -- rather than just getting one to work at all. Yes, that's all subjective and might just be me getting better at game development, but I was immediately productive in Godot, and I haven't run into a roadblock for what I happen to be doing. I imagine there may be a game type, or otherwise simple technique that is nearly impossible in godot, but simple elsewhere; that's true of every game engine it seems.
hugs_vs_toph 4y ago
imagine doing OOP in 2023
- deleted 4y ago
  [deleted]

by avx56 4y ago

logicprog 4y ago

This is why I prefer using libraries to abstract away the complicated parts of doing low level graphics, sound, etc over game engines/frameworks. Engines call me, instead of being called BY me, and that forces me to use their whole environment instead of picking just what I need, as well as forcing me to distort the concepts and abstractions that are most natural for how I think about a problem to fit into the existing way they want things to work. I prefer being able to make my own architectural decisions.

karpierz 4y ago
Is there a set of libraries you'd recommend in this vein?
- logicprog 4y ago
  Unfortunately, not really. I don't actually have a ton of experience with gamedev outside of engines, I just know what the failings of engines are from using them for a few projects over the years. The one library I might've recommended is a Rust one that's now defunct.
- IshKebab 4y ago
  I imagine he is thinking of things like SDL, SFML, Macroquad and so on.
- eliasdaler 4y ago
  * glfw, SDL - C, low level, require more work to get started with (maybe coupled with bgfx if you don’t want to write your own renderer). * SFML (C++), Ebitengine (Go), bevy (Rust) - high level, easier to use. * LÖVE2D (Lua), raylib (C) - even higher level. And Dear ImGui is a must for implementing debug UI/level editor/tools. And maybe PICO-8 as an alternative (it’s something in-between of a low-level framework and a game engine)
avx56 4y ago
I find this hard because games often end up quite tightly-coupled, so while you don't have the pathfinding code reaching into the rendering, the rendering is usually coupled to the game object model and it's hard to make it reusable outside of a specific engine. That and the fact that AAA studios do not want to open-source anything for some reason.
- logicprog 4y ago
  That's true. That's why if I ever write another game I'm going to write it basically from scratch myself lol, true NIH-suffering indie gamedev style.
  - astrange 4y ago
    It's said that if you start writing a game and a game engine you'll only release one of them.
- astrange 4y ago
  Open-sourcing commercial code can be difficult because it might contain or use things from other companies that you don't have permission to release. Of course, it might also just be that you don't want your employees to get any fame, but they do seem to be allowed to talk at GDC.
  - avx56 4y ago
    Yeah, I think it's that and the fact that there isn't (obvious) money in fixing up and maintaining code for a shipped game.
eliasdaler 4y ago
Agreed. Making custom editors/tools/content pipelines is also much easier when you have your own engine. Of course, you can write custom plugins for some engines, but I always felt uneasy about this - plugin API always breaks and you need to learn a lot of specifics of the engine to make something non-trivial (which is hard, because those engines are usually gigantic in scope). The downside of making your own engine is that it’s usually gets more fun to develop the engine itself than games with it…

LanceH 4y ago

I get where you're coming from, and there is always a certain hackiness to game code it seems. But I've embraced godot for 2D games and it has been wonderful. I get more code reuse out of the node system than I ever got out of class hierarchies elsewhere. I find myself with the time to set up a lot more test scenarios where I can play two things side by side to find the better feel -- rather than just getting one to work at all. Yes, that's all subjective and might just be me getting better at game development, but I was immediately productive in Godot, and I haven't run into a roadblock for what I happen to be doing. I imagine there may be a game type, or otherwise simple technique that is nearly impossible in godot, but simple elsewhere; that's true of every game engine it seems.

hugs_vs_toph 4y ago

imagine doing OOP in 2023

deleted 4y ago
[deleted]