Hacker News Reader

Comment by avx56 | Hacker News Reader

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.

View on HN

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.

Is there a set of libraries you'd recommend in this vein?

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.

I imagine he is thinking of things like SDL, SFML, Macroquad and so on.

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

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.

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.

It's said that if you start writing a game and a game engine you'll only release one of them.

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.

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.

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…

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.

imagine doing OOP in 2023

Reply on news.ycombinator.com