Hacker News Reader

Comment by 12_throw_away | Hacker News Reader

More than anything else, this sounds like a good lesson in why commercial game engines have taken over most of game dev. There are so many things you have to do to make a game, but they're mostly quite common and have lots of off-the-shelf solutions.

That is, any sufficiently mature indie game project will end up implementing an informally specified, ad hoc, bug-ridden implementation of Unity (... or just use the informally specified, ad hoc and bug-ridden game engine called "Unity")

View on HN

> More than anything else, this sounds like a good lesson in why commercial game engines have taken over most of game dev. There are so many things you have to do to make a game, but they're mostly quite common and have lots of off-the-shelf solutions.

> That is, any sufficiently mature indie game project will end up implementing an informally specified, ad hoc, bug-ridden implementation of Unity (... or just use the informally specified, ad hoc and bug-ridden game engine called "Unity")

But using Bevy isn't writing your own game engine. Bevy is 400k lines of code that does quite a lot. Using Bevy right now is more like taking a game engine and filling in some missing bits. While this is significantly more effort than using Unity, it's an order of magnitude less work than writing your own game engine from scratch.

But it also doesn't have even 10% of Unity features. Bevy docs themselves warn you that you are probably better off with something like Godot, at least while Bevy is still in early development.

Over the past year I've been working at my studio to add enough features to Bevy to ship real apps, and Bevy is at the point where one can reasonably do that, depending on your needs.

For the 4 people on HN not aware of it, this is a riff on Greenspun's tenth rule:

> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

I think this has less to do with Rust and commercial game engines being better and more of a fetish that game programmers seem to have for entity component systems. One does not have to look far to see similar projects repeated in C++ years prior.

ECS is basically the realization that relational databases are a pretty damn good model.

I’m suspicious though that you could probably get away with literally just using like an in-memory duckdb to store your game state and get most of the performance/modeling value while also getting a more powerful/robust query engine — especially for like turn-based games. I’m also not sure that bevy’s encoding of queries into the type system is all that sane — as opposed to something like query building with LINQ, but I think it’s how they get to resolve the system dependency graph for parallelization

> ECS is basically the realization that relational databases are a pretty damn good model.

A pretty darn good model for what though and to what extent? For processing millions of objects, sure. For gameplay logic, using ECS for everything? I don't know about that. What I was implying with my comment is that ergonomics are the most important trait of a good game engine.

I reach for an ECS as a last resort when the performance of a gameplay system demands it, not before. Even before that I will tweak my gameplay code to be less wasteful.

And yet, if making your own game engine makes it intellectually stimulating enough to actually make and ship a game, usually for near free, going 10x slower is still better than going at a speed of zero.

If anything, making your own game engine makes process more frustrating, time consuming and leads to burnout quicker than ever, especially when your initial goal was just to make a game but instead you stuck figuring out your own render pipeline or inventing some other wheel. I have a headache just from thinking that at some point in engine development person would have to spend literal weeks figuring out export to Android with proper signage and all, when, again, all they wanted is to just make a game.

Speaking as someone who has made their own game engine for their indie game: it really depends on the game, and on the developer's personality and goals. I think you're probably right for the majority of cases, since the majority of games people want to make are reasonably well-served by general-purpose game engines.

But part of the thing that attracted me to the game I'm making is that it would be hard to make in a standard cookie-cutter way. The novelty of the systems involved is part of the appeal, both to me and (ideally) to my customers. If/when I get some of those (:

This seems entirely subjective, most importantly hinging on this part here: "all they wanted is to just make a game".

If you just want to make a game, yes, absolutely just go for Unity, for the same reason why if you just want to ship a CRUD app you should just use an established batteries-included web framework. But indie game developers come in all shapes and some of them don't just want to make a game, some of them actually do enjoy owning every part of the stack. People write their own OSes for fun, is it so hard to believe that people (who aren't you) might enjoy the process of building a game engine?

> And yet, if making your own game engine makes it intellectually stimulating enough to actually make and ship a game, usually for near free, going 10x slower is still better than going at a speed of zero.

Generally, I've seen the exact opposite. People who code their own engines tend to get sucked into the engine and forget that they're supposed to be shipping a game. (I say this as someone who has coded their own engine, multiple times, and ended up not shipping a game--though I had a lot of fun working on the engine.)

The problem is that the fun, cool parts about building your own game engine are vastly outnumbered by the boring parts: supporting level and save data loading/storage, content pipelines, supporting multiple input devices and things like someone plugging in an XBox controller while the game is running and switching all the input symbols to the new input device in real time, supporting various display resolutions and supporting people plugging in new displays while the game is running, and writing something that works on PC/mobile/Switch(2)/XBox/Playstation... all solved problems, none of which are particularly intellectually stimulating to solve correctly.

If someone's finances depend on shipping a game that makes money, there's really no question that you should use Unity or Unreal. Maybe Godot but even that's a stretch. There's a small handful of indie custom game engine success stories, including some of my favorites like The Witness and Axiom Verge, but those are exceptions rather than the rule. And Axiom Verge notably had to be deeply reworked to get a Switch release, because it's built on MonoGame.

Indeed there are people who want to make games, and there are people who think they want to make games, but want to make game engines (I'm speaking from experience, having both shipped games and keeping a junk drawer of unreleased game engines).

Shipping a playable game involves so so many things beyond enjoyable programming bits that it's an entirely different challenge.

I think it's telling that there are more Rust game engines than games written in Rust.

This does not apply just to games, but to most any application designed to be used by human beings, particularly complete strangers.

Typically the “itch is scratched” long before the application is done.

I'm in that camp. After shifting from commercial gamedev I've been itching to build something. I kept thinking "I wanna build a game" but couldn't really think what that came is. Then realised "Actually it's because I want to build an engine" haha

This person develops

I disagree with this assessment.

After 30 years participating in Gamedev communities I feel like the "don't build an engine" was always an empty strawman aimed at nobody in reality.

The Venn diagram between the people interested in technical aspects of an engine and in also shipping a game is probably composed of a few hundred individuals, most of them working for studios.

The "kid that wants to make an engine to make an MMO" is gonna do neither. It's just a meme.

I shouldn't really care about it myself, but I do because Unity sucked the air out of every gamedev discussion and now there are almost no spaces to discuss anything advanced (even if it's applicable to Unity/Unreal/Godot).

I would bet that if you want to build a game engine and not the game, the game itself is probably not that compelling. Could still break out, like Minecraft, but if someone has an amazing game idea I would think they would want to ship it as fast as possible.

It is orders of magnitude easier to write an game engine for yourself than it is to create a monster like unity or unreal that needs to appeal to everyone and support every kind of game.

If we are talking 2d, it can be months to hack together a basic engine. 3d can be a bit harder but far from decades.

Thing is, if you designed your engine well and implemented great tooling, it should make it faster to implement the actual content of the game.

So upfront cost to be faster later. At least in theory. Obviously you might end up with subpar tooling that is worse than what a commercial could offers. But if you do something like an RPG with a lot of contend, every bit of extra efficiency in creating that content can help a lot.

Now, obviously from a purely commercial standpoint, not using an established engine makes nearly never sense. Super risky. Hard to hire outside talent. You are only justified when you have very, very specific needs that are hard to implement in a generic engine.

Also for us with an ADHD brain, hard things tend to be easier and easy things very hard, so yes the extra mental stimulation of writing an engine can help.

This is correct. If you want to build a game engine, you better know what kind of game it is by making at least a playable prototype in a conventional engine.

My experience is the opposite. Plenty of intellectual stimulation comes from actually making the game. Designing and refining gameplay mechanics, level design, writing shaders, etc.

What really drags you down in games is iteration speed. It can be fun making your own game engine at first but after awhile you just want the damn thing to work so you can try out new ideas.

Making an actual indie game can take from 6 months (tiny) to 4-5years. If you multiply that by 10x, the upper bound would be 40-50 years. Of course, that's not how it would be but one has to consider whether their goal is to build a game engine OR a game, doing both at the same is almost guaranteed failure (statistically speaking).

Being intellectually stimulating doesn't translate into sales, gameplay might.

Reply on news.ycombinator.com