3 ms·

> files plus perhaps a runtime index. The latter already adds a lot of complexity, especially if the application has to scale up or out. If scaling up, the ind

> files plus perhaps a runtime index. The latter already adds a lot of complexity, especially if the application has to scale up or out. If scaling up, the index will increase in complexity and re-implement some clever algorithms that have already been solved by the other. If scaling out, you'll need some locking mechanism if multiple processes can write. It quickly becomes logical to switch to an established solution then. But the choice becomes more logical then; if one picks a scalable database or whatever without knowing they're going to need it, that's a lot of wasted effort. > - Most games would be better off with a bespoke game engine IMO, especially those made by small teams. I disagree; writing a game engine, even for simpler "indie" graphics, requires specialized knowledge and a dedicated engineer, whereas with off-the-shelf engines, non-programmer / creatives can build a good game without in-depth knowledge. A small team needs to be especially careful with what they choose to spend their time and money on, and solving a solved problem like building a game engine is a huge investment. Even big studios struggle with this, see also the dramatic release of Cyberpunk 20something by long-time own-engine-building veterans CDPR. They're switching to Unreal for Witcher 4.

whoisyc 1y ago
Any mature game engine also comes with mature developer tooling. Think profiling, debugging, assets management, map editing etc. That’s a lot of initial hurdles to overcome before you can even start working on your game ideas. For indie / solo developers who tend to be, you know, driven by one’s creative urges, this is not just a huge time sink but also a good way to ruin your motivation by never moving to the part where you get to actually create the game. When your time and energy is constrained you need to choose your battle and for indie developers this often means forgoing the technical part (unless you really need to) and focus more on the game part. I have seen many people say “there are more games engines written in Rust than games written in Rust” and I wonder if what happened is that the software developers fell for the allure of building their whole stack from scratch and ended up finding out it sucks to actually develop a game for an engine with no tooling and “making an entity inspector that lets you click on an enemy and edit its attributes” isn’t exactly the sexy part of game development.
- the_af 1y ago
  The trap of "building a game engine" vs "making a game" has existed long before Rust. When games were really simple, so simple that "making a game" vs "making an engine" had no real difference (say, building a game for 8 bit home computers) then it wasn't a big deal. The concept of "games engine" didn't really exist back then, or was uncommon at least. But nowadays? A small indie team, or a single dev, are likely to go down the rabbit hole of making their own game engine, forced to solve a lot of problems that are already solved in existing engines, rediscover the wheel, and get frustrated because the step of making the game never actually comes. I think it makes more sense to use a pre-made engine, unless the game really is so different this isn't an option, or the devs really enjoy making engines (which is valid, and you learn a ton of cool things, but is also a hurdle in the way of actually making a game). Every games programmer enthusiast I know has a half-made, abandoned, badly performing engine with which they've made a couple of demos or a barely functional unfinished game... (I'm also guilty of this, but given my age, mine was written in C++!).
strix_varius 1y ago
The author of one of the most popular games of the last decade disagrees with you: https://noelberry.ca/posts/making_games_in_2025/ https://noelberry.ca/posts/making_games_in_2025/
- the_af 1y ago
  In which part is Noel disagreeing? He didn't write his own engine either, he just didn't use one (but didn't write everything from scratch either, note he uses lots of game/graphics frameworks, which in a sense is like using a "meta engine"). He's also making a 2D game, which traditionally is closer to game making of old (think 8 bit home computers). Finally, he's not arguing against engines like Godot or Unreal, he says those are acceptable but he just didn't need them. Much like he doesn't need Windows and finds coding with Linux more comfortable. PS: out of curiosity, which one is the popular game you mentioned? Looking through his portfolio I see lots of interesting games I'd like to play :)
  - strix_varius 1y ago
    > He didn't write his own engine either, he just didn't use one It's hard for me to take in good faith an interpretation of that article that determines Noel "didn't write his own engine," but in case a couple direct quotes would help: "I don't have much to say about assets, because when you're rolling your own engine you just load up what files you want, when you need them, and move on." ... "my City of None engine" Noel literally describes his workflow as "rolling your own engine" and has a name for the engine he wrote. > He's also making a 2D game, which traditionally is closer to game making of old Please read the context of the thread you're replying to, which is arguing against writing your own engine even for games with "simpler 'indie' graphics," specifically called out. > Finally, he's not arguing against engines like Godot or Unreal He's not arguing against anything. He's advocating for writing your own engine. Noel made the indie hit Celeste: https://en.wikipedia.org/wiki/Celeste_(video_game) https://en.wikipedia.org/wiki/Celeste_(video_game)
    - the_af 1y ago
      Ok, ok, it's indeed an engine of sorts. And I am arguing in good faith. I'm not familiar with Celeste and I cannot be sure it's one of the most popular indie games of the last decade (I read that it was a hit, good for Noel because it seems like a cool game), but regardless, it's a very specific kind of game! Mostly of the kind I've argued "writing the game" and "writing the engine" is almost the same thing. Nobody is making the argument you must always use an existing engine; only that it's what makes sense as the default option. > Please read the context of the thread If you've read my other comments, you know I'm aware of the context of the thread. > He's not arguing against anything. He's advocating for writing your own engine. Oh please. Advocating for a thing and arguing against not doing the thing are two sides of the same coin.

whoisyc 1y ago

Any mature game engine also comes with mature developer tooling. Think profiling, debugging, assets management, map editing etc. That’s a lot of initial hurdles to overcome before you can even start working on your game ideas. For indie / solo developers who tend to be, you know, driven by one’s creative urges, this is not just a huge time sink but also a good way to ruin your motivation by never moving to the part where you get to actually create the game. When your time and energy is constrained you need to choose your battle and for indie developers this often means forgoing the technical part (unless you really need to) and focus more on the game part. I have seen many people say “there are more games engines written in Rust than games written in Rust” and I wonder if what happened is that the software developers fell for the allure of building their whole stack from scratch and ended up finding out it sucks to actually develop a game for an engine with no tooling and “making an entity inspector that lets you click on an enemy and edit its attributes” isn’t exactly the sexy part of game development.

the_af 1y ago
The trap of "building a game engine" vs "making a game" has existed long before Rust. When games were really simple, so simple that "making a game" vs "making an engine" had no real difference (say, building a game for 8 bit home computers) then it wasn't a big deal. The concept of "games engine" didn't really exist back then, or was uncommon at least. But nowadays? A small indie team, or a single dev, are likely to go down the rabbit hole of making their own game engine, forced to solve a lot of problems that are already solved in existing engines, rediscover the wheel, and get frustrated because the step of making the game never actually comes. I think it makes more sense to use a pre-made engine, unless the game really is so different this isn't an option, or the devs really enjoy making engines (which is valid, and you learn a ton of cool things, but is also a hurdle in the way of actually making a game). Every games programmer enthusiast I know has a half-made, abandoned, badly performing engine with which they've made a couple of demos or a barely functional unfinished game... (I'm also guilty of this, but given my age, mine was written in C++!).

strix_varius 1y ago

The author of one of the most popular games of the last decade disagrees with you: https://noelberry.ca/posts/making_games_in_2025/ https://noelberry.ca/posts/making_games_in_2025/

the_af 1y ago
In which part is Noel disagreeing? He didn't write his own engine either, he just didn't use one (but didn't write everything from scratch either, note he uses lots of game/graphics frameworks, which in a sense is like using a "meta engine"). He's also making a 2D game, which traditionally is closer to game making of old (think 8 bit home computers). Finally, he's not arguing against engines like Godot or Unreal, he says those are acceptable but he just didn't need them. Much like he doesn't need Windows and finds coding with Linux more comfortable. PS: out of curiosity, which one is the popular game you mentioned? Looking through his portfolio I see lots of interesting games I'd like to play :)
- strix_varius 1y ago
  > He didn't write his own engine either, he just didn't use one It's hard for me to take in good faith an interpretation of that article that determines Noel "didn't write his own engine," but in case a couple direct quotes would help: "I don't have much to say about assets, because when you're rolling your own engine you just load up what files you want, when you need them, and move on." ... "my City of None engine" Noel literally describes his workflow as "rolling your own engine" and has a name for the engine he wrote. > He's also making a 2D game, which traditionally is closer to game making of old Please read the context of the thread you're replying to, which is arguing against writing your own engine even for games with "simpler 'indie' graphics," specifically called out. > Finally, he's not arguing against engines like Godot or Unreal He's not arguing against anything. He's advocating for writing your own engine. Noel made the indie hit Celeste: https://en.wikipedia.org/wiki/Celeste_(video_game) https://en.wikipedia.org/wiki/Celeste_(video_game)
  - the_af 1y ago
    Ok, ok, it's indeed an engine of sorts. And I am arguing in good faith. I'm not familiar with Celeste and I cannot be sure it's one of the most popular indie games of the last decade (I read that it was a hit, good for Noel because it seems like a cool game), but regardless, it's a very specific kind of game! Mostly of the kind I've argued "writing the game" and "writing the engine" is almost the same thing. Nobody is making the argument you must always use an existing engine; only that it's what makes sense as the default option. > Please read the context of the thread If you've read my other comments, you know I'm aware of the context of the thread. > He's not arguing against anything. He's advocating for writing your own engine. Oh please. Advocating for a thing and arguing against not doing the thing are two sides of the same coin.