Hacker News new | ask | show | jobs
by logicprog 1245 days 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.
3 comments

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…

Is there a set of libraries you'd recommend in this vein?
* 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 imagine he is thinking of things like SDL, SFML, Macroquad and so on.
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.