[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.