Hacker News Reader

Comment by siavosh | Hacker News Reader

As a developer who's not in the game industry I am constantly surprised how often I read that an indie effort has decided to build their own game engine. Are Unity/Unreal/etc really that limiting or is it a psychological trap engineers keep falling into?

View on HN

I haven't done gamedev in a long time, but there's an old saying the community: you either make a game engine or you make a game --- not both.

That's news to me... Also news to some of the biggest hits ever, like Minecraft.

I feel like Minecraft should be the exception to nearly every single rule in game dev (except when it itself is the rule).

That said, there's a difference between making an engine for a game like Minecraft vs. the kind of engine needed for Limit Theory.

At the end of the day, it's the same stories and questions about core competency present in almost every business. If you want to build a shelf, and you have to start by making the tools that will cut the tree that will become the shelf... it's going to be a while until you see a shelf, and in the process you'll probably be producing more useful tools than shelves.

Unity is popular for the same reasons AWS is popular: It allows you to focus your time on what you excel at, instead of spending it reinventing various wheels. Some businesses (and games) can succeed despite reinventing those wheels, not necessarily because of it.

And in some extremely rare cases, "what you excel at" is both building the engine and making an excellent game out of it (Present company included; I'd recognize your name anywhere). Stardew Valley and The Witness are the only two examples I can give off-hand of significant, outstanding, indie games that were released with a custom engine. And I would maintain that in both cases, it wasn't necessary to create the engine. In SDV's case it's even questionable if it actually helped at all.

Every other example I could come up predates the days of high quality engines being readily available to sub-$100k budget games.

Edit: I'll add Psychonauts to that list; once again, a decision of questionable gain that the author AIUI regretted.

I’ll preface this by saying I have tons of respect and admiration for what Notch did, however I think it fair to say that Minecraft came about from Notch making a game engine not a game. The game was already made and was called infiniminer. He was definately an engines guy and successes mostly because Minecraft let he users build the game experiance themselves.

Take a browse through /r/gamedev or github and see how many people start game engines only for their efforts to vanish into the aether or never actually be used for a game.

Minecraft, or anything anyone has even heard of, is very much an exception to the norm.

NIH Syndrome. Also, I imagine that a lot of game development is fairly menial drudgery from a software development standpoint, so the temptation to make it more intellectually stimulating probably becomes pretty high.

I've been researching a design recently and have faced the temptation freshly, so perhaps it'd be useful to share.

Having investigated every 2D and 3D engine for the web (it's a nice UI, not a game), it seems none of the existing options scratch my itch: SVG and its huge complex object graph grind to a halt burning CPU after your first few thousand nodes, while game engines that can often cope with huge entity counts just continually burn CPU and apparently have no concept of 'idle'.

So the itch is there: just a little <canvas>, a few wrapper objects, and I'm sure I'll be done in no time. Just gotta reimplement D3's TopoJSON renderer, that's all.

Of course it's a lie, but at this stage I'm old enough to realize that :) I think the only way many people (just like me) in IT learn this is the hard way: be getting burnt too many times.

> temptation to make it more intellectually stimulating probably becomes pretty high.

This is not OK when you have made promises to people who expect a product. This guy took advantage of those people, and it's incredibly sad. I don't know how they kept on doing this for 6 years without reassessing if their approach was really the correct approach. I can't fathom that in 6 years, not one person raised their hand and asked "why the hell are we writing a game engine?".

Caveat emptor. Due diligence. Blame/fault isn't helpful here, and it's shared regardless.

It's only 180k. That's one years developer salary.

I have seen projects in industry that deliver a button of a different color for more.

I haven’t looked closely at game engines. Is it possible to write the game at the level of abstraction you want, then write a translation layer into various game engines? Or do these game engines tend to creep into all of your code, preventing you from decoupling your game from the engine? If this were possible then you could prototype the game using a game engine to get a “MVP” and if you aren’t satisfied, swap out portions of the engine with custom code.

> Is it possible to write the game at the level of abstraction you want, then write a translation layer into various game engines?

At that point, aren’t you almost writing your own engine anyway? You’d need to design the abstractions, interface with the game engine, and consider how those two things impact performance. That’s a big chunk of what a game engine is supposed to do for you.

All of these engines (Unreal, Unity, etc.) are written as monolithic "frameworks" that want to own the top loop and have you override certain bits to customize behavior. Also, the nature of games requires that various components (graphics, physics, ai, networking, etc.) are tightly coupled together. So, no, you're in a world of pain if you want to use Unreal and not do things "the Unreal way".

---

Honestly though, I see nothing here that couldn't be done in any modern engine out of the box though. They can all stream assets in and out of the level asynchronously (for "infinite extent" levels), build meshes/textures programmatically, support fully dynamic lights, etc. If you have some requirement for procedural generation that isn't supported out of the box (e.g. baking lightmaps at runtime), surely it'd be easier to just write that part yourself and inject it into the existing pipeline.

Game engine code and data types creep into all your code. I once heard an indie game developer describe this as "smushing playdough against a mold" (where your game-specific not engine-specific code is the playdough and the mold is the engine API).

I write small games some times and I used Godot and Unity for 2d and 3D small projects. I find both of them very annoying to work with in the way intended. Luckily both are customizable enough to follow my own workflow (which is 95% code; I basically detest the graphical tooling; they really get in my way); I can understand why people, for whatever reason, roll their own, however, because I have no time as it is, I wouldn't attempt that now. If I would do full time game dev for a game of my own I probably would though.

Building and tweaking tech is a trap for engineers even with Unity and Unreal. Game design is a lot less easy to pin down and most engineers are conditioned that time spent not tapping away is wasted. Building your own engine, particularly for an over ambitious game idea is a recipe for prevarication.

There’s nothing wrong with building your own engine but it and the intended game are going to need to be constrained.

I can’t say, but keep in mind that there are plenty of examples of indie games that used a custom engine and went on to be highly successful. It could be that those games would have been just as successful with an off-the-shelf engine, but perhaps there is something to be said for the DIY approach.

Watch out for survivor bias on this, though. How many games never made it to release because they bit off more than they could chew building the engine? How many of those could have been successful if they had used a commercial engine?

We only hear about the successes in either camp. To get an accurate picture, we'd need to look at all the attempts.

Not a game dev but can Unity/Unreal/etc do procedurally generated everything? I thought they were more designed for manual map/environment building.

Can't comment on Unity but Unreal4 definitely allows this, although you may have patch the engine source or implement your own base classes etc. I would imagine Unity is not that much different.

See Astroneer for an example of this, the planets surfaces (which are deformable by the way) are procedurally generated, even if they are deployed from a kind of template specifying the parameters.

UE4 has a ProceduralMeshComponent for this sort of thing, not to mention procedural foliage component etc.

yes, but you probably wont have the benefit of the map editor

Unity gets shit on a lot because of how easy it is to churn something out with it (of dubious quality), but if you understand how it works at a fundamental level and also actually know how to code, you can pretty much do anything with it. It would be difficult do something of this scale procedurally, but you can definitely do procedural generation in Unity. You would just have to be smart about how you load resources at runtime to avoid hangups.

> but if you understand how it works at a fundamental level

This circles back to another key reason I think a lot of people choose to build their own engine, many people don't want to spend time learning the ins and outs of somebody elses creation. When you build your own engine, you know the entire api in and out from the start and as it evolves, you know what it can and can't do, and you know where to go if it's missing a feature or has a bug.

I'm more surprised that they continued this (clearly wrong) approach for 6 years, leaving all of those people waiting, eagerly. This was irresponsible. The lesson here is, don't bite off more than you can chew, especially if you don't know what it is you are eating.

Reply on news.ycombinator.com