[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

[meheleventyone]

When people say to build a game not an engine they mean “don’t copy the patterns of general-purpose game engines and build something specific to your needs”. There’s not game that doesn’t have bits you can point at as “the engine”. Lots of people get stuck “making the engine” to make their game rather than making the specific engine bits they need as they go.

That said this was the status quo before Unity and whilst it shipped games the asset pipelines and editors in engines like Unity and Unreal are much more productive for the non-programming portion of the team. As well as providing a shared framework that makes it easier to hire and train developers. Not to mention easier porting and so on.

I do think the solution to part of this is an open-source scene editor/flexible tool that has some defined interface that any engine can implement like a language server or similar.