[moth-fuzz]

I by and large loathe how commonplace big do-it-all game engines have become in indie game development, with unity at the forefront of this movement. Even if everybody and their mom used the same awesome product, I'd still be upset because because of the market stranglehold that eventually creates - Unity in this case is worse because it isn't even an awesome product. It's a mediocre product with an actively hostile business strategy.

I admit this is entirely emotional, but when I learned that Hollow Knight[0] was made in Unity, it broke my heart. A 2D game with a consistent art style (read: write the shaders once and forget it), made up entirely of flat surfaces with only a handful of different methods of movement, no physics to speak of, and only a couple hundred different types of enemies, most with large overlaps in AI save for bosses. Gorgeous game, strong art direction, thoughtful lore and story, but any game developer could probably write the engine for such a game in a couple weeks.

But every indie developer I've talked to about game engine development acts like it's a dark art. That it's just impossible for mere mortals to do such a thing, and if you do, then you'll never ever release a game, or you'll spend literal years on the engine. Again, I predict a couple weeks.

Back to the article, I dislike that 'game development post-unity' just means 'picking out a new engine'. Everybody's jumping ship to Godot or Unreal or whatever else because we all need a game engine. But why? Why is this song and dance necessary? I feel like since the author is a game engine programmer himself, this option should have come up higher on the list along with the non-engine libraries and frameworks.

0. https://www.hollowknight.com/

[_gabe_]

> Again, I predict a couple weeks.

I’ve made similar predictions in the past… these days, I predict that a couple years actually makes a lot more sense. Especially if you’re not familiar with game engines, and especially if you have to figure out: physics, input mapping, window systems, graphics pipelines, audio systems, game logic component systems (basically the game loop), level systems, transitions, platform support (switch, PC, PS5, Xbox, …), level editors, serialization, animation systems, particle systems, and more!

I have a big fat book sitting on my bookshelf called Game Engine Architecture by some of the developers at Naughty Dog. That bad boy is 1,000 pages and just gives a high level overview. It does not teach you how to set up a graphics pipeline, open a window or write a shader. I have other big fat 1,000 page books for those. Those do not teach you the mathematics needed to fully grasp linear algebra. I have yet more big fat 1,000 page books for that. Those books do not teach you C++, I don’t believe any book is sufficient for that big fat language, but I have a few anyways.

It’s cool if you enjoy tinkering on engine stuff, but boy am I glad that the Hollow Knight devs (I believe there were only 2 people) just used an engine. It’s an amazing game, and I could care less how it was made. I’m just glad that it was made.

Edit: I forgot to mention game HUDs, UI systems, font rendering in general, and asset management pipelines to the list of things that come with an engine but you’d have to either code it yourself or just not have it if you don’t want to use an engine. All of these subdomains can have years of effort poured into them (speaking from experience). The rabbit hole never ends haha.

[grumple]

Those big fat books are, from my experience with math books, definitely not written in a way to teach well.

Programming languages can be broken down to their syntax. For experienced programmers, I recommend starting by reviewing a language's reserved keywords then skim over any core lib, for example: https://en.cppreference.com/w/cpp/keyword

There are similar shorter paths for people. However, I'd note that most people who went to school for CS have already taken math classes through at least linear algebra, and because of interest, many also took game development classes. At least, I did. I actually wrote a game myself from scratch in C++ in high school in the days before youtube, when there was very little guidance on the internet. It was bad, but if I could do it as a child, others can certainly do better today.

Rabbit holes never end. Professionally, I learn in sort of random directions, at least learning what I need for my next task. But it's impossible and completely unnecessary to have complete knowledge of anything. YAGNI.

[meheleventyone]

You can definitely stand up the basics of a 2D game engine really quickly… if you’ve done it before. If you haven’t it’s an unexplored problem and is significantly more challenging.

But it doesn’t end there because once you’re done standing up the engine you need to improve and maintain it. Then port it to different platforms, you did remember to abstract things nicely when you stood it up right?

And that’s without mentioning all the extra time you’ll be putting into higher level systems like localisation and UI. And the combo of those two is fearsome!

Plus you have to make a game.

Or you can use Unity or another off-the-shelf engine and ignore most of these issues.

Which isn’t to say you can’t make an engine but if you are running a business you need a compelling reason why that becomes an advantage. I doubt Hollow Knight would have found it’s success as easily if they had to worry about all of that.

[notamy]

> But why? Why is this song and dance necessary? I feel like since the author is a game engine programmer himself, this option should have come up higher on the list along with the non-engine libraries and frameworks.

I’ve done a little bit of this casually; imo it’s because I don’t want to write the engine. I want to be making features for the game, not making a bespoke custom engine and fixing issues with it as well as my game.

[muchwhales]

Just to give some perspective: Without prior graphics programming experience, I was able to write a simplistic 3D engine (VERY simple, but enough for my purposes) in a week or two. I somehow assumed that it was just an impossible thing to do and so I've never tried, until recently. It turned out to be much easier to get something going than I could've imagined.

It's true that Unity and other engines offer tons of features, but most indie developers probably won't need them, and by the time they do need more than the basics they'll have so much experience that they can easily implement what's missing in their own "engine".

We're also seeing some interesting developments in this space with WebGPU, which is what prompted me to finally give it a try in the first place. I've never used OpenGL before and I was still able to get by (more or less), after failing miserably to complete the Vulkan tutorial...

If nothing else, I can only recommend people at least think about whether they really need Unity/Unreal and consider that there are disadvantages as well as advantages when using them.

[joeyjojo]

Also, for even things like physics there are many simple ways to do things. Take Towerfall's arcade physics for example[1]. In under 100 lines you can create the basis for your platformer game. Sure, it's not just pluggable into other pre-existing solutions, ie tile maps, but at least you aren't endlessly hacking all over the place to tweak Unity's physics into submission to get the controls feeling right for your simple 2d game. There is a massive wealth of gamedev knowledge that doesn't seem utilised to its potential because existing engines want sell their pre-canned solutions. I think what the gamedev scene needs are more tools like LDTK[2], with more thought given to how such tools could interop, and a better selection of low level rendering libraries (like Monogame and Raylib) with very robust cross platform support and dead simple build systems (or none at all).

I use a very obscure library called Kha[3] and it has by far and away the best performance for 2d rendering that I have encountered. It is amazing what you can do with just a very basic immediate mode ui library called Zui[4]. I think it is shitty advice to say that you are either building an engine or game. This advice would be applicable if you are building a general purpose game engine, not the highly specific and bespoke engine used for you own game. Your game and your engine are basically the same thing and you take many shortcuts, make many compromises, and build out a rough and minimalistic "editor" used just by your small teams (or yourself) to get the job done.

[1] https://maddymakesgames.com/articles/celeste_and_towerfall_p... [2] https://ldtk.io/ [3] https://github.com/Kode/Kha [4] https://github.com/armory3d/zui

[fulltimeloser]

"But every indie developer I've talked to about game engine development acts like it's a dark art. That it's just impossible for mere mortals to do such a thing, and if you do, then you'll never ever release a game, or you'll spend literal years on the engine. Again, I predict a couple weeks."

It's a can of worms to make a game engine for multiple platforms.

[johnnyanmac]

> Everybody's jumping ship to Godot or Unreal or whatever else because we all need a game engine. But why?

I'm assuming we're talking about 2D games so I won't dwell on the "because they want to make a 3D game". See musings below

1) not everyone has that technical prowess, they may not even want to code to begin with. I may be able to whip something up in a few weeks for a 2D game, but someone new will simply be learning how to code first and then finagle with libraries they can't full piece together. So engines that can heavy lift and let a user do simple scripts (if that) to do their movements is a big demand.

2) engines differentiate from frameworks by offering different suites for other parts of development. Designers would love a level editor and that is annoying to make (even in 2D). Artists may want to tweak the lighting or even do some light procedural generation, so the ability to get feedback of how it looks in-game helps a lot more than guessing in their artist suite. even other programmers may want conveniences for front-end annoying stuff like UI, where the correctness isn't based on the code

3) Familiarity. Just because you CAN work on your own engine doesn't mean you want to. I'm sure the Hollow Knight devs simply followed up on their game jam project in Unity because they knew Unity. You can't spend all your waking hours thinking about how your tools may go to shit in 10 years. You'd never get anything done.

I'm all for encouraging more engines, but I can understand reasons to seek out something rather than prioritize ownership.

-----------

>But every indie developer I've talked to about game engine development acts like it's a dark art. That it's just impossible for mere mortals to do such a thing, and if you do, then you'll never ever release a game, or you'll spend literal years on the engine. Again, I predict a couple weeks.

As someone who's gone down that rabbit hole: it is black magic combined with pixie dust when working on a 3D game. There is just so many edge cases to resolve and techniques to implement to make a 3d scene look good. And now you need to build something that lets non-devs be productive on op of that (or accept that you will have an artist backseat driving you, losing efficiency). You will spend years and end up with a much worse product, likely very buggy (no pun intended). There's just too much to learn before you even start making the game. Make games, not engines (I say as an engine programmer).

For a 2d engine, sure. Hollow Knight probably could have been made in Gamemaker with no technical hiccups. And if you know what you're doing you can utilize a couple of libraries and whip up a decent 2D engine that is all yours. You'll still have issues, but it isn't insurmountable if you're making a simple game that moves around a few hundred sprites on screen.