> The same cannot be said for databases, game engines, web servers, cryptographic primitives, etc.
It absolutely can in many cases.
- Many applications don't need much more of a database than files plus perhaps a runtime index. Spawning a database server or even embedding SQLite can be overkill in many cases.
- Most games would be better off with a bespoke game engine IMO, especially those made by small teams. The only real advantage to using an established engine is the familiar asset pipeline for replaceable artists but you pay for that with a huge overhead. Remember that custom engines or at least heavily modified ones maintained by the game developer used to be the norm - "just use Unity^WUnreal" is a relatively recent trend.
- There is no real difference in complexity between a simple web server and FastCGI application.
- Not all uses of cryptographic primitives are a security issues. If you calculate a hash to check against corruption you can implement that yourself (or copy an existing implementation) instead of pulling in a huge library. If your use cases is decrypting existing data offline then again you don't really care about cryptographic security only about getting the correctly decrypted output.
And there are many more cases like these. Learned helplessness when it comes to "hard" subjects helps no one.
Just because some existing solution "solves" your problem doesn't mean its the best or most efficient way to do it.
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.
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 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++!).
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 :)
> 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.
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.
> - Most games would be better off with a bespoke game engine IMO, especially those made by small teams. The only real advantage to using an established engine is the familiar asset pipeline for replaceable artists but you pay for that with a huge overhead. Remember that custom engines or at least heavily modified ones maintained by the game developer used to be the norm - "just use Unity^WUnreal" is a relatively recent trend.
I think we can take Square-Enix as a case study: Final Fantasy XV and Final Fantasy XVI both used their own engines (though XVI used a modification of XIV's engine, from what I hear) and both took a long fucking time to make. Granted, XV had many issues outside of just building a new engine, but it definitely added one more problem onto the pile. My understanding is that Final Fantasy XVI's development cycle was pretty smooth, it still took 7 years from the launch of Final Fantasy XV!
Final Fantasy VII: Remake and Final Fantasy VII: Rebirth both used Unreal Engine 4. While Remake had a long development cycle, Rebirth was done in 3 years and contained a much bigger world!
I do totally get that part of the argument is "reuse the same damn engine and tooling," and I totally agree with that, too. It's just a bit easier overall when you can reach out to a community with your problems instead of learning every problem for yourself.
Most games that use an existing engine get like 60% on metacritic and ship like less than 1000 copies and are a generic flop. “Shipping no matter what” is a lot less valuable in games.
You think the only game you will lose are generic Unity shovelwares when in reality you will also lose good games made by people with good sense in game making but likely not the resources or technical expertise to make their own engines. Think Cities Skylines (Unity, the studio had only a dozen people in total when it released), Dusk (Unity), Undertale (GameMaker), Spelunky (GameMaker)..
Another comparison is game modding which is essentially using the base game as the engine of your modded game. Do you think Team Fortress or Counter Strike or DOTA would have been made if their creators thought they have to build their own game engine?
Lowering the friction to make a game means more games get made. Yes there will be a flood of bad ones, but we get good one too.
The adventure of writing a custom DBMS, game engine, or other complex and advanced software classes can be justified by 1) knowing that no existing solution is adequate but 2) it is possible to write something suitable and 3) it will be useful enough to justify the cost.
For example, to insist on the example of Tigerbeetle, 1) no current popular or specialized DBMS is particularly optimized for ledger use, 2) but suitable techniques are well understood; I'm not sure how often 3) it will be preferred to a more general purpose DBMS.
> - Most games would be better off with a bespoke game engine IMO
You have it backwards.
Most games won't benefit from a bespoke game engine at all. Most games should use an existing engine (not necessarily one of the big names, just one that works) if their goal is to actually deliver a game.
Some games are so unique they won't benefit from an existing engine, and only then the dev team must take the extra step (and eat the delay) of building their own engine.
I mean commercial games of course. Experimental/hobby devs are free to do whatever, since in that case it's the journey and not the destination that matters.
It absolutely can in many cases.
- Many applications don't need much more of a database than files plus perhaps a runtime index. Spawning a database server or even embedding SQLite can be overkill in many cases.
- Most games would be better off with a bespoke game engine IMO, especially those made by small teams. The only real advantage to using an established engine is the familiar asset pipeline for replaceable artists but you pay for that with a huge overhead. Remember that custom engines or at least heavily modified ones maintained by the game developer used to be the norm - "just use Unity^WUnreal" is a relatively recent trend.
- There is no real difference in complexity between a simple web server and FastCGI application.
- Not all uses of cryptographic primitives are a security issues. If you calculate a hash to check against corruption you can implement that yourself (or copy an existing implementation) instead of pulling in a huge library. If your use cases is decrypting existing data offline then again you don't really care about cryptographic security only about getting the correctly decrypted output.
And there are many more cases like these. Learned helplessness when it comes to "hard" subjects helps no one.
Just because some existing solution "solves" your problem doesn't mean its the best or most efficient way to do it.