I've been cranking on a 2D engine for over 4 years and have put thousands of hours of work into it.
My summary:
If you want to write a game, just write a game. Don't start with your own engine since this will suck all your time and you'll end up spending 90% on engine and very little getting the game game done. Especially so in the beginning when you have no features and doing anything in the game requires engine work.
If you choose to create your own engine it's a compelling and fantastic domain where problems come in all shapes and sizes and you can and get to work with physics, maths, linear algebra, audio, rendering, graphics APIs, system level programming, most likely native programming AND scripting, game content, technical art etc.
But finally the real work is not the engine but the tooling and the editor around the engine.
If (when) you rely on free assets from (for example opengameart) you can expect no consistency. Not just the art style but just the technical part too, like your models are all inconsistent in shapes and sizes and axis, 2D content such as textures are by default without any meta data etc. So you really need to create a ton of tooling so that you can have sensible workflows and you can extract and consume the usable and interesting parts of any content package easily.
This inevitably leads to the concept of "editor" which easily comes with a ton of work by itself that has nothing to do with game or game engine per se. For example the concept of "Project", windows, resource management, basic editing functionality for creating content, undo/redo/ etc. A lot of this is not really related to the game or the engine in anyway but you really sort of "must have it" if you want to create something that is actually usable.
The feature creep is real! But once you get the over a lot of the boiler plate and you can actually use your own editor to stuff content into your own engine and have it running it's really a nice feeling even if nobody else cares!
On the technical side my advice is really to be able to do first principles type of thinking. It's of utmost importance to be able to break things apart into self contained features and pieces that the game can then combine to create bigger constructs.
If you can have your materials scroll textures vertically, when you combine that with shapes that are layered and place textures onto those shapes that scroll at various multiples of your "characters" speed then you've just created "parallax scrolling" essentially.
I often hear the advice to "make games, not game engines", and it's refreshing to hear it from someone who is actually working on an engine themselves, because usually when I hear this advice it's from devs who use Unity/Godot/Unreal, and the implication I get is that if you're not using one of those engines, you're wasting your time and won't ever make a game.
But I'd say there's a middle ground between using an existing engine and making your own general-purpose engine from scratch. I've been making a 2D RTS using C++/SDL, and it's taken me longer to write it this way than if I had used an existing engine, but in only a few months I've reached the point where I have a prototype and have had multiple playtests and am iterating the prototype based on feedback from those playtests.
So, while the advice "make games, not game engines" is still definitely true, it doesn't mean that if you code "from scratch" that your game will necessarily be a long 4-year engine project (unless you want it to be!). The trick is to keep the code specific to the game you're working on and to avoid the urge to abstract everything / make everything general-purpose.
Yep this is of course one possible way too. Make a game from scratch but don't make an engine.
I personally I'm not capable of executing this strategy because my mind is always thinking in terms of abstractions and how to make things so re-usable in another context/project when the time comes. For better or worse this means that for me any "game from scratch" project will immediately turn into "engine + game from scratch" project :)
I want to make sure you understand that games as art genre and old resource limited and low level programs are far away from each other now. And moving in different directions at light speed. Unless one builds something that should be donated to a museum on release one does not need more of C++/SDL.
I say that as someone who keeps working as mostly C++ contributor into internal game engines for various projects.
I would want people to look forward and make works of art that expand what we thought was possible more instead of 'learning low level programming'.
For me, a great middle ground is building an engine similar to fantasy consoles (PICO-8, TIC-80, etc.)
This type of project is small enough to plan all the elements before you start (which helps to stick to the design and therefore to avoid feature creep). Yet, it is still complex enough to provide entertainment and challenge.
This approach also has the advantage – at least it is an advantage in the case of side projects – that you can see the results of your work quite quickly.
I'm working on such a project myself, and it is a great experience. Although to tell the truth, it is more of a "game creation kit" than an engine.
This is exactly why I ended up going for Godot with my own hobby game. I have made a lot of progress on a custom game engine in the past without actually having a game to make in mind. It always gets to the point where you have to start making decisions about the tooling, and that becomes your main focus.
No disrespect or put downs of anyone trying to do their own thing, but Godot is a really great engine and is open source. It's kind of miracle that we live in a world where there is a viable open source engine for commercial grade 2d games and the whole thing is MIT licensed.
I think the trap people fall into is to have things be overly specific in the name of optimization they never get to achieving anyway.
For instance, I find you can get massive mileage by declaring “(almost) everything is instanced”, then you batch it, forget it, move on. There are similar shortcuts to be made with physics and so on.
The close to ideal engine, in terms of approaches to problems, was LittleBigPlanet. That was a small team that were really good, but crucially they had the right way to frame the problems so as to constrain the emergent complexity of the result.
"I think the trap people fall into is to have things be overly specific in the name of optimization they never get to achieving anyway."
Yes I agree, writing a specific functionality in the engine does allow for more optimal performance but the tradeoff is that it's more brittle and more complicated to write and maintain.
My personal approach has been to do the first principles and avoid writing use-case specific features in the engine as much as possible but provide more fundamental functionality that the game then combines to create the desired effect.
That being said I've still had to do some concessions and move stuff like simple constant velocity game object integration to the engine side simply because the perf difference between native code doing that vs Lua code are just too massive.
A question then, I have run some game servers in my time that had quite advanced console options and scripts to run, in Lua, which I then saw as maybe the most common language in this area. But I wondered where and why Lua which is its own full language was kept to a certain part of the game and running instance, and where the other runtime and the games main language differed. How is that division of responsibility separated or chosen I guess?
There's no single answer to this, it all depends on the game, the engine and the team(s) executing the engine and game.
Some typical ways to divide this though is
Some org has "engine" team and "game" team. Engine team implements features in the engine itself and game team implements game specific features using the embedded scripting language.
Engine features are game agnostic and game features are specific to games and are scripted / built-on top of the engine features.
But sometimes things get muddled as general purpose engines are used in games that require specific features in the engine itself. Typically the decision is then made by a) what kind of feature and how does it fit in the architecture of the engine b) what are the performance requirements c) who is willing to do the work and maintain it
I want to write a slot machine “game” for a custom slot machine I’ve built using a piece of MDF, a 32” LCD, and a Linux single board computer.
I haven’t found much information on how to write a game in this style with existing engines. Any advice or resources you would point a noob too? I am a software engineer but not a game programmer.
It doesn’t have to be so good as a real slot machine (regulations and such) but I do want to follow the rules as best I can. I may not use a real hardware RNG.
Maybe re-assess if a game engine is needed for your use case? A slot machine doesn't really need a whole ass game engine, you could do it with pretty much any graphics library.
I've been cranking on a 2D engine for over 4 years and have put thousands of hours of work into it.
My summary:
If you want to write a game, just write a game. Don't start with your own engine since this will suck all your time and you'll end up spending 90% on engine and very little getting the game game done. Especially so in the beginning when you have no features and doing anything in the game requires engine work.
If you choose to create your own engine it's a compelling and fantastic domain where problems come in all shapes and sizes and you can and get to work with physics, maths, linear algebra, audio, rendering, graphics APIs, system level programming, most likely native programming AND scripting, game content, technical art etc.
But finally the real work is not the engine but the tooling and the editor around the engine.
If (when) you rely on free assets from (for example opengameart) you can expect no consistency. Not just the art style but just the technical part too, like your models are all inconsistent in shapes and sizes and axis, 2D content such as textures are by default without any meta data etc. So you really need to create a ton of tooling so that you can have sensible workflows and you can extract and consume the usable and interesting parts of any content package easily.
This inevitably leads to the concept of "editor" which easily comes with a ton of work by itself that has nothing to do with game or game engine per se. For example the concept of "Project", windows, resource management, basic editing functionality for creating content, undo/redo/ etc. A lot of this is not really related to the game or the engine in anyway but you really sort of "must have it" if you want to create something that is actually usable.
The feature creep is real! But once you get the over a lot of the boiler plate and you can actually use your own editor to stuff content into your own engine and have it running it's really a nice feeling even if nobody else cares!
On the technical side my advice is really to be able to do first principles type of thinking. It's of utmost importance to be able to break things apart into self contained features and pieces that the game can then combine to create bigger constructs.
If you can have your materials scroll textures vertically, when you combine that with shapes that are layered and place textures onto those shapes that scroll at various multiples of your "characters" speed then you've just created "parallax scrolling" essentially.
-----
https://github.com/ensisoft/detonator