Custom Game Engines: A Small Study
gist.github.com
gist.github.com
“Make games, not engines” is fine advice in general but you can make an engine for your specific game without making that engine look like Unity. You don’t need a sophisticated custom level editor, you can just use something off the shelf like Tiled. You don’t need an extension language (like C# or Lua), you can just do the whole engine + game in one project, with one language.
You might also have a valuable mental toolkit that is squandered when using an existing engine. I can’t count all the times I’ve said, “I know how to implement that, but not in Unity.” My mental model of how objects are drawn to the screen consists entirely of buffers and shader program invocations. There are also plenty of games that just don’t benefit from some of the core features of engines, like physics, and need to roll their own anyway.
Some games have fairly custom needs and aren’t a good match for existing engines (like No Man’s Sky or Minecraft) and some games (especially 2D games) have very simple needs and an engine doesn’t provide as much of an edge over something like a framework (e.g. MonoGame) or platform abstraction library (e.g. SDL).
Or in short, “custom engine” does not automatically mean “half-baked alternative to Unity”. Just how it’s totally fine to make your next web app backend without using a high-level framework, and it’s totally fine to make your next frontend without React. If anything, it’s easier than ever to make a frontend without React, just like it’s easier than ever to make a game without Unity.
Note that the original meaning behind "Make games, not engines" was exactly that (IIRC when it was originally written in a blog post that somehow became popular, Unity was still a MacOS-only engine and other engines were prohibitively expensive to indies), not that you should avoid making engines.
Basically it was about focusing on making the game and have your engine implement just the features your game needs, not the feature some theoretical game might need in the future. It was an advice meant warn against scope creep.
Also it was directed towards people who actually wanted to make games with their engines and it wasn't directed towards people who just wanted to focus on the tech side (even though the advice was still to have some sort of demo game to drive things).
Somehow over the years people started using the phrase as if it meant "stick with making games, do not bother making engines".
It’s another example of how a useful piece of advice gets distilled into a saying, and then the saying turns into a lazy way to make it feel like you’re contributing to the discussion.
Bigger teams using an off the shelf engine will likely end up modifying large portions of the underlying engine code-base in order to implement what makes their games different from other games in the market.
Isn't this the number one reason why people reinvent the wheel? We all understand things differently. The people who make the libraries and frameworks have their own design and developers are supposed to use their code in very specific ways. Deviating from this path causes a lot of pain and difficulty. Sometimes it feels like it's easier to just write new tools based on what I already know compared to learning a completely new set of ideas just to work with existing stuff which may or may not be adequate for my needs.
To break it down a little more: come up with a game you want to make. Start making it. You'll figure out how to make an engine as you start making your game.
To break it down even more: I wanted to impress an old girlfriend by making a clone of Galaga, cause she loved it as a kid. I decided to make Galaga in HTML5. I wanted to start by rendering the ship to the screen, so I went down that path until I could do it. How do I draw something to the screen on the web? Use Canvas - figure out how to reliably render a canvas element on the page and fill it a color. How do I draw an image? Draw sprites on the canvas - get a sprite of the ship then figure out how to draw it. How do I move the ship? Create a backing representation of the state of the game, then render the world based off that. I now have a simple game engine and an emerging game.
The generic, one-size-fits-some advice is: Go and make three games, and by the time you’re done with the third game, you’ll have a clear idea of what you want from an engine.
Basically, game dev is a hobby for me so I'm in no rush to actually publish a game. I'm interested in learning nearly every aspect of how games are made.
I've already been playing around with Unity and Game Maker Studio a bit. I'm continuing to learn Unity but rather than spending tons of time learning how to use a game engine's libraries I would prefer to learn how these things are built and make one myself.
So code more! Could be hacking on games, could be doing other programming. But once that software design muscle is big enough making an engine will seem more obvious than ever.
I wrote a little advice comment on simple game engines recently: https://www.reddit.com/r/gamedev/comments/fr986w/game_engine...
Repeat this over 20 years, rewrite from scratch every few years, switch to unity, unreal, then back to another rewrite!
- Either figure out how to transpile the language you're using to the one for each target platform, or find a runtime for it that will run there.
- Write unifying input-handling code across platforms; treating all analog sticks (PC, Playstation, Xbox, Switch, maybe touch screen sticks) the same, treating touch on iOS and Android (and mouse input?) the same, etc.
- Manually hook it up to each platform's SDK that you might want to target; each game console, iOS and Android, the web, etc. Graphics, resource loading, network access, audio.
This can be a massive undertaking, which is why most indie games that don't use a major engine just stay on PC.
Whereas in Unity I can take an existing project, with little to no knowledge of Android development, with zero code changes, and plug in a device and click "build for Android" and have it running flawlessly on-device in 5 minutes. Same for an embedded Web version. Presumably the same for iOS and Xbox and Playstation and Nintendo Switch, though I haven't tried those personally. But that's an enormous differentiator if you have any interest at all in making your game cross-platform down the road. Even Godot, while it supports mobile, doesn't support consoles out of the box.
Edit: Oh, and I forgot to even mention VR support. And cross-VR-platform support.
That's assuming the game is appropriate for a given platform. A mouse-based game with a lot of very small click targets (such as SimCity 2000) would not be playable on a touchscreen. The game would have to be dramatically re-designed to the point where it's a different game entirely. At that point, the advantage of having a "build for Android" button is greatly diminished.
If you're only targeting PCs (and I think most Indies are) then a framework like SDL gets you most of the way there to having your game run on Mac/Windows/Linux. It also does so without any of the financial cost of a proprietary engine and keeps things very simple so you can focus on building exactly what your game needs.
Not at all. Handling different input styles (mouse vs touch), while not trivial, is a tiny fraction of the other work listed above that goes into targeting multiple platforms. Unity/Unreal let you focus on just that tiny part that actually matters to your game.
> If you're only targeting PCs (and I think most Indies are)
This is also not remotely true. The current generation of consoles, in particular, have been huge for indies. The majority of the games released on them have been from indies. And if you're taking gamepad input, you don't really even have the input-mode speed bump when it comes to supporting multiple platforms at once. Probably the only concern you'd have to deal with is level-of-detail, but you'd have to do that for PC anyway, and the engines give you tools that assist with it.
A bit of this is also just the fact that with Unity you don’t have to personally deal with the Android NDK, which is the software used as punishment in the fourth circle of hell, if I remember Inferno correctly.
I think this is more of an indictment of the Android NDK than anything else.
Of course, I don't think it would be worth writing your own game engine to work around that one bug, but at some point, one wonders how many oddities it takes to justify a rewrite. People still play the game despite this one bug that's existed (I hear) since launch, so I guess it was a good cost/benefit decision to use Unity. But for a game studio that prides themselves on polish, that particular bug makes me die a little inside every time it happens.
The joke from the java days was "Write once, crash anywhere!", although I suppose "Write once, freeze anywhere!" was more common unless you ran out of memory.
Back in the day, I guess the advice just meant to focus on getting a game out and not worry about "making a reusable engine" (ie even if you write all the code from scratch, don't over engineer, don't worry about "possible future games", just focus on what the game needs right now). While that original meaning has shifted, I think the general advice still stands and you shouldn't make your own engine if your goal is to make a game, unless you have a specific need, but even in this case, I think making your own engine is only a good idea if you have made games before and have some experience. If its your first game, even if you have a specific need, its a terrible idea.
I say that as someone who has tinkered with making various engines, but I always went into it knowing I wouldn't finish any games, since I enjoy tinkering with low level "system" code and also found it a great learning experience. However, if I ever want to make an actual game, I'd use one of the popular engines, for sure!
You either have to use Unity/Unreal/Whatever or develop in house something that comes close to it in features.
Using a renderer + gui library + physics library doesn't get you very far, in fashionable time. And in game industry, if you aren't delivering very fast, you can already close the business before you start. It's a too competitive field to have the luxury to consume more time than the fastest teams out there.
I did a full featured 3d Tower Defense game for a job interview in 3 days using Unity and asset store 3d models. It would have take me months to do that without it. Maybe more if I had to write the renderer.
With time, as technology peaks; more one-person engines will appear because you don't have to chase the next big thing all the time.
I'm building a MMO from scratch since 20 years back, the most recent MMO that uses my server is free-to-play this weekend:
https://store.steampowered.com/app/486310/Meadow/
The source for the backend is here:
https://github.com/tinspin/fuse
You can call it a one-man MMO backend.
I'm going to release a MVP for the C++ 3D MMO client in about a month hopefully, here is a tech demo for it:
Yall, it's $2. Support the man.
@dang, I really don't think HN was intended to work like that. I watched a few minutes ago as someone went through my comments and over 30 seconds it went -2, -2, -2, which even makes me wonder if people have multiple accounts that they abuse for that.
Has anyone else experienced that?
Sorry for the meta, I just don't get that behavior. Kind of ugly.
edit: so yeah, same thing on this comment. Bam, -2. I dunno what spiteful game someone is playing, but it's silly.
There's something very cool about being the creator and master of your own world.
That said, I made a subreddit for the topic: https://www.reddit.com/r/mmodev/ it's kinda empty now but hopefully people will contribute eventually.
I also use HTTP for real-time movement, you can do that if you strip all non-mandatory headers and use "Transfer-Encoding: Chunked" for the "Pull" socket. I use two sockets per client: "Push" (Client <-> Server) and "Pull" (Client <- Server).
HTTP uses TCP and that will inevitably lead you to the old TCP vs. UDP threads. My take on it is that TCP works fine for real-time action games today if you use event based protocols instead of tick based!
If you're looking for an exemplary server architecture for MMOs, look no further than UO. That game came out in 1997 and supported worlds with thousands of players and millions of persistent objects. Players could build their own houses within the game world, decorate (and later design) them to an incredible degree [1], and have other players visit (welcome or not). Players could run their own shops within their homes and sell their own hand-crafted, signed goods (weapons, armour, clothing, furniture) in addition to any found treasure they wanted to offer.
What made UO so impressive, technically, was how they accomplished all of this on such modest hardware as was available in 1995 [2]. This second link is to the GDC postmortem of the game. If you're interested, I recommend you check it out. It may not answer all your technical questions but it's extremely interesting nonetheless. The story of how they had to shard the game is part of the talk.
I'm pretty sure they did not use any off-the-shelf databases as the performance would have been terrible at the time. Everything would have been custom. The custom networking protocol is extremely reserved (not chatty), since it was designed for dial-up modems. Even when you run the game on modern hardware with broadband, the game uses on the order of a few megabytes per day of traffic.
[1] https://duckduckgo.com/?q=uo+house+decoration&t=osx&iax=imag...
The paper you link to doesn't use "shard" as a noun, and in fact it doesn't describe a system that has "shards" in the sense that UO and just about everyone else since then has understood that term, i.e. independent partitions of a dataset:
> The reader is referred to [SBK] for a detailed description of the architecture of the SHARD system. Briefly, the main ideas are as follows. The network consists of a collection of nodes, each of which has a copy of the complete database.
(emphasis mine)
Additionally, according to Google Scholar, that paper was only ever cited 21 times. I checked the 16 of those citations for which full-text is available, and not a single one of them used the word "shard" as anything other than a passing reference to the name of the system itself.
Scaling it beyond that (you're very lucky!) then involves sharding, and you can build a master/slave system that splits shards and moved them around as needed.
Source: working on my own MMO which is a realtime location based tower defense game.
https://blog.winricklabs.com/(02-17-2020)---efficient-data-s...
Here's the first video uploaded by Notch when he first embarked on a new "Cave game": https://www.youtube.com/watch?v=UMpv5kZ9-rE (the original video is blocked in the US for some reason)
An interesting side-effect of this technical decision was that the game was heavily moddable. Java byte code is relatively easy to decompile, and class files easily modularize the various components of the game. So installing a mod amounted to un-zipping the minecraft.jar file and replacing .class files with modded ones. In fact, this is still how modding works in the Java version of the game.
The java backend is doomed from the onset. Then why is the bedrock edition not better? It’s a simple game that a small team of competent engineers should have done in less than two years. Unless they actually make a modding API for the bedrock edition, the bedrock edition will be little more than a footnote. The java edition will remain the most relevant set of releases until mods are officially supported in bedrock.
If Managed Direct X and XNA had an uphill battle against WinDev, where they even suggested to move from XNA into DirectXTK, as if the target audience would be the same, there isn't much Java love to expect from the games division.
Minecraft modding is neglected in all official capacities, it's a usability trainwreck, and the self-installed dictator of the preeminent mod loader is very easy to not like.
I've played a lot of modded Minecraft, and I can tell you for sure that you suffer through the myriad technical problems because there's just nothing out there like it, and not because it's a good experience.
Modloaders like Forge are platforms for mod installation because they overwrite the class files, and instead modders would add class files that don’t conflict instead (these days it might patch in code via Reflection, so things might be slightly different, but the fundamental process is the same). Furthermore I believe Mojang has started releasing debug symbols for Minecraft so the decompilation is no longer 100%. community driven as it used to be.
Fundamentally though, Forge is really doing the same thing. My point is that without the ability to easily decompile and patch in code, Minecraft modding would not be nearly as easy to do and platforms like Forge wouldn’t exist
I used to be a MC Modder back in the Beta, and at peak my mod had order 50000+ users, so I have some idea what I’m talking about. Admittedly I didn’t use a Mod loader at this time though.
TaleWorlds is another studio that wrote its own engine for Mount & Blade (reused later for M&B Warband and its expansions), and more recently developed a new engine from scratch for the recently-released (and 8 years awaited) Mount & Blade 2: Bannerlord. The older M&B games were definitely niche, but Bannerlord's definitely notable going by the numbers (it's currently in the Top 10 games by concurrent players per steamcharts.com, though that seems to be tapering off now that the novelty's wearing off a bit; it also broke Steam's payment processing within minutes after launch). Early Access, but still an interesting example.
The opposite seems way more common: a sequel that tries to be different but noticeably uses the same tech under the hood.
One way to look at things, is who in recent years won the (imo) biggest indie game award, the Seumas McNally Grand Prize:
- A Short Hike: Unity
- Return of the Obra Dinn: Unity
- Night in the Woods: Unity
- Quadrilateral Cowboy: id Tech 4
- Her Story: Unity
- Outer Wilds: Unity
- Papers, Please: custom using OpenFL/Haxe
- Cart Life: Adventure Game Studio
I admittedly started looking because I knew Obra Din was Unity, so there's some bias in category selection. That brings us to 2013. That 5/8 Unity, and 7/8 using an engine. The remaining 1/8 (Papers, Please) was developed by Lukas Pope, who later made Return of the Obra Dinn in Unity. This is a list chosen by game developers, but I would think that would skew the list towards impressive custom things.
I do agree with the spirit of the post: You don't have to use an engine. Nothing about a game engine is magical. There's lots of success stories on both sides.
Interestingly, from the Wikipedia page it seems that Unity was a result of "our game didn't do well but we made awesome tools". They now have 2000+ employees according to Wikipedia.
The employee numbers on some of these companies is misleading. Nintendo does not just make video games, but the employee count covers everyone. CD Projekt employee count includes GOG and is somehow mostly the developer side, but GOG still has 172 employees (but not a single employee over 50, and only 2 in all of CD Projekt :/, also for anyone else wondering while I'm looking at the stats, GOG is a bit under and the rest of CD Projekt a bit over 25% women). It looks like Valve does both development and Steam with 360ish employees.
Also publishers often do quite a bit of QA and such for games they publish (even if it often doesn't seem like it :/), so comparing publishers with studios that have outside publishers is also not getting the full picture.
Also worth noting the open source RenPy that a number of visual novels use.
I had to create my own game engine because it had to be 100% data driven, and none of the existing ones really fitted my need.
The cool thing about a data driven engine is that there is no building and restarting phase. You just edit everything inside the running game.
You can check it out at https://rpgplayground.com .
I'll definitely have a look at your project for some ideas.
Love how clean and simple you keep both your project and website.
I’d love to see jo-engine (Sega Saturn) evolve into something like this.
Always wanted to build something like the RPG Maker for the web myself, but never found the time to do it. Your product looks wonderful and I'm a bit jealous.
If you can't take a read-only copy of the engine and implement a game on top of that then you don't have an engine. Marketing will still want you to name the 'engine' though!
Back in the earlier days of Unreal there was an industry joke that Unreal was great if you were making a single player third person space marine game on Xbox or PC. Unreal has come a very long way since then and is a truly wonderful achievement but it took a huge amount of time, resources and skill to get it to where it is now.
I guess id Tech 1 -- which they licensed to many developers -- was not an engine then? I don't think that's a useful definition.
> Back in the earlier days of Unreal there was an industry joke that Unreal was great if you were making a single player third person space marine game on Xbox or PC.
Did Unreal really fall that far after the glory days of Unreal, Unreal Tournament '99, Deus Ex, Clive Barker's Undying..? Wow. The Xbox generation of games really ruined so many things.
Heh! In the process of implementing custom movement similar to F-Zero, I'd have to say it's still heavily optimized towards character based games.
In one of the videos he says that the big engines are trying to be everything for everybody, and there's value in developing a custom engine for your game's specific needs.
There’s a tendency these days for people to think of “game engine” in terms of the big, general-purpose engines like Unity, Unreal, and Godot. However, by analogy, a car still has an engine even if that engine was purpose-built for the specific car and is never reused in other cars.
It would be really weird to have to come up with a different name for the game engine for The Witness — what would you even call that, if not an “engine”? So, “engine” is going to refer to custom, never-reused engines in games until we get a better word for it.
I also think it's fine to think in terms of the game you're making between "game stuff" and "engine stuff" where the "engine stuff" is essentially things that could reasonably be repurposed.
In the example of The Witness I'd not call it anything as it doesn't exist separately to it as far as I'm aware. I'd still understand someone who referred to it as the game engine though.
The main point IMO is that making an engine implies more than just making the tech needed to power a game.
Then I think we have a very fundamental disagreement here. Your definition for “engine” is definitely not mine.
If we can’t talk about the engine for The Witness we are at a loss, because there isn’t a different word that we could reasonably use, besides “engine”.
For example some of the framework for The Witness was ported to Jai for the sokoban game Thekla is working on.
Of course not all engines were and are like that, some engines were standalone products by themselves, but i think the engines that grew out of games were not just "proper" engines but actually the majority of them.
Some companies made it a priority to build a reusable engine some didn't. Some went on to license it and some didn't. Some tried to make their engine reusable and didn't really succeed.
When you make "an engine" very specifically for a certain game you are making a choice to make it less reusable because that's a waste of time to ship your game. This was how things were at one stage. You'd take the codebase, grab out as much as possible and that'd be the start to the next engine. Reuse came later as mid-sized studios dominated and is seen en masse in really big studios. As indies restored the smaller end of studio size it makes more sense to either use a commercial engine or make your tech more specific.
I think you are mixing two separate things: the reusability of an engine isn't really relevant nor what defines the engine. The engine is really the tech that supports the gameplay, nothing more or less. It doesn't have to be a framework or library or shared among projects or anything else. It can be any of those, but these are separate - and similarly a framework, library or any shared code doesn't mean that it is an engine.
But it could also be in house. I don’t have a feel for how many engineers it takes to make a game engine.
For comparisons you have PICO-8 which is an intentionally super limited but fully integrated game engine made by one person.
Then you have Unity which is a very featureful engine, ported to every commercial platform with a vast toolset and side offerings which arguably has lost sight of a bunch of the game engine part of things because they have the capability to spin so many plates and a business incentive to drive revenue by getting people to sign up to extra services.
And now with Valve pushing VR strongly, I imagine we're going to see the same thing. You want to play Half-Life Alyx with the all new Source engine built for VR? You gotta buy our headsets and use Steam VR home for the best experience!
For Valve, having the Source engine in-house always gives them that extra bargaining chip when they want to push something new.
GoldSrc actually - the HL1 engine. Which was built off a heavily modified Quake engine.
> Back when it first came out, everyone I know _hated_ Steam
That was 16 years ago and 90 million users ago. Yes it was shaky and had issues back then (I was a very early account signup), but again a long time ago.
> You want to play Half-Life Alyx with the all new Source engine built for VR? You gotta buy our headsets and use Steam VR home for the best experience!
No. You don't need their hardware. I'm using HP WMR without issue and have completed HL: Alyx. Yes, Valve's controllers are top notch, but you don't have to use them. And SteamVR is just part of Steam, and if you want to play any Valve game, you have to use Steam.
Speaking of HP. HP and Valve have been apparently working on some new things together, so I would imagine there are going to be more/better VR options down the line.
One thing I really like is the level editor tools, with Hammer for source 2 they've re-implemented BSP geometry tools with geometry tools that use static meshes.
A good/modern geometry level editor workflow is sorely lacking on the other available engines.
I'm really curious how they will expand it for VR level editing with the Alyx release. One thing I think you'd need is a way to quickly view the environment in VR while editing. This seems really important if you want to carefully craft some specific visuals for VR, or certain interactions. Can for example the player stand next to a hole in a wall and reach through it to access something.
You only make the changes necessary to update it for new hardware. For example, you throw away the old BSP rendering code, as elegant as it is, because it’s designed to get good performance on a Pentium 90 and modern computers just aren’t like that. It’s the ship of Theseus.
But at the end of the day Source 1 is also just a modified GoldSrc engien which is just a modified Quake engine. Doesn't really mean much when there have been extensive modifications over time.
I worked on an engine that, despite multiple huge overhauls and tech improvements motivated by our games, people suggested it was "the same buggy engine" as the first game we released since we didn't change the name for our in house toolset.
This of course meant progress was rather slow-going early on, having no prior experience with things like 3D rendering or the related math, spatial indexes/collision detection, the list goes on... I figured by creating everything as needed I would at least be getting a better understanding of what's going on and how everything comes together, plus owning all of the code doesn't hurt.
Last weekend I successfully participated in a 24hr irc art contest by submitting a small game using some of these components, and I'm happy to say it's a whole lot easier for me to slap something simple together today with this pile of parts than it was a couple years ago.
I made a Show HN about the 24hr contest submission since it's all GPL and thought some HNers might enjoy poking at it, but it didn't seem to get any notice. This was the post if interested https://news.ycombinator.com/item?id=22940287
I disagree with that. Sometimes you need, sometimes you don't.
>I may be wrong but i don't think Unity allows you that kind of control.
It allows you to use your own level stuff, like your own custom renderer, or your own physics engines. Some studios releasing AAA games do that, because they have the resources.
That said, it might be interesting to look at companies that changed from using custom engines to stuff like Unity/Unreal at some point, or perhaps the other way around. I remember Rare originally building most of their game engines inhouse at one point, but their Xbox 360/Xbox One era games seem to have changed that.
It's also interesting to note that there are also quite a few custom game engines being made for various fan game development scenes too, as well as off the shelf ones specifically made for games based on that series.
Or that the same 'build games not engines' and 'unless everything is custom it's not worth it' debates exist there too.
Either way, some of the notable ones there include:
- Hello Engine, which was basically a hybrid of various 2D Mario titles in a way that made it very easy to use as a level editor. Has roughly the same reputation as Unity does on Steam because of that, with at least one game basically marketing itself as a parody of it as a result. - Gatete Engine, with a fairly similar featureset, but a more modern coding style - Super Mario Bros X, a level editor created by the guy behind Terraria, which has since ended up decompiled and remade in a different programming language by fans, with various forks made based on that.
There are also obviously a ton of individuals and small groups building their own engines for individual games in that community too.
Finally, the whole 'make games not engines' thing doesn't have to refer to the entire engine. No, it can be equally easy to get distracted by the possibility of adding extra features to an existing one too.
When I worked for Free Radical Design we had two big AAA games in development both using the FRD in-house custom game engine. I'd say the engineer split was something like 30:30:30 between engine and the two games, with another split between engine programming and tool programming (though there was some cross over there, for example one of the guys on the game team I was on worked on the game editor). The engine was really impressive - it was cross platform and ran on *Nix, Windows, XBox 360 and PS3. The engine guys did an amazing job on it.
Ogre3D is mentioned, but it's not as easy to use as it was, the doc seems poor, there are 2 versions of the engine (although it's a normal thing nowadays), so it seems the engine is dying.
-Whatever Avalanche Studio's are using for their games like Just Cause, Renegade Ops, and Mad Max. They graphics seems not only look good, but very performant on medium to low end PCs.
"Just Cause 2 was announced in January 2008. Powered by the Apex Engine 2.0"
The small studios (or one-man armies) are the ones using custom stuff because they have to do it all anyways, no biggie having to do a little leg work to import stuff.
When you're a bigger studio, having to coordinate and support multiple teams with different workflows, the engine and the tools it provides play a much bigger role. The studios with such scale either build something that works for them, or use some existing one provided by others.
If you say so. The vast majority of programmers would have no clue where to start if you put them up to the task.
A game engine is much more than a renderer, which is the only easier part in 2D versus 3D.
I have a toy game in play around in my free time and started with SDL like so many. You can create windows and draw bitmaps really easily. But sooner rather than later you discover limits (bugs, performance limitations, less than ideal APIs) and see that just writing OpenGL code yourself is actually easier and more flexible. Many people go down that road.
edit: Concerning your edit about "more than a renderer": Yeah that other stuff is annoying and many still use SDL, SFML or whatever for that. See Factorio and many many others who do the rendering themselves and offload the other crap. I do that myself too.
And bring physics, input, asset loading, networking, systems, scripting, etc.
And again the point I was trying to make was about graphics. Most if not all do not roll out their own code for input management, window creation, Networking and so on. But 2D graphics is relatively easy to DIY.
I've never seen a 2D game engine that doesn't give you at least graphics, physics, and input.
So while not at engine level, it already provides higher abstractions than those libraries, and a content pipeline.
You can make simple games out if just hose libraries, but anything complex will tend to require a ton of support code (characters, animation, maps/levels, camera control, collision detection, event triggers and such for example) and other libraries, at which point you’re basically writing a small custom engine on top of those libraries.
Godot has a 2D renderer and physics option, Defold is 2D by default, Game Maker Studio, Cocos2d, Corona, Construct, Phaser.io, Buildbox, Gamesalad, Stencyl, Clickteam Fusion
Unity is very capable of 2d games too and provides a lot of game structure and so do many other engines (I want to mention Heaps.io because it’s awesome).
Along with their own idiosyncrasies and assumptions. Which is something you may decide you do not want to deal with. E.g. hand-coding the little physics you need may be easier than learning the physics engine's API and adjusting your own architecture to mesh with it.
Roblox is the only really big engine company I can think of that actually develops their own physics tech (because they started off doing it).
So both Unreal and Unity now have their own physics tech.
A lot of engines are still using PhysX (albeit stuck on version 3.x). Upgrading a physics engine is often a pain point, either because it is so tightly integrated in the code base or because game assets have been tuned for the current physics implementation and even a small accuracy or behavior change will require assets to be re-tuned.
Unity has an ECS physics module they made in collaboration with Havok called Unity Physics which is in development.
You’re right that it seems like Unreal and Unity are ditching PhysX for something else (Unreal for the new Chaos engine, Unity for their new DOTS engine in collaboration with Havok). I’m just surprised that PhysX‘s performance problems had something to do with the move.
NVIDIA's incompetence is what kicked both of them off, basically. Both engines will continue to support PhysX 3.6 for existing customers.
You are missing asset management (loading, streaming, caching...), audio (big enough to split into libraries and actual audio engines), input (of different kinds), networking (big enough to split too), AI, scripting, physics...
Calling SDL/SFML for "other stuff" is, again, a tiny part and it is in no way offloading "the other crap" (as you call it).
I assume you are biased because you have only coded toy examples. When you start anything remotely complex, you have to do way more things than just "drawing bitmaps".
As for Factorio, it is actually a very complex and fast simulation. Downplaying engine devs as "rendering and other crap" is derogatory to say the least.
However, you can absolutely make 2D games that need lots of kinds of assets. RPGs happen to be one of them, in fact: The incidental details of adding inventory, NPCs, abilities, dialogue, etc. does add up. Every little message and description, every item's properties. You can ship a game by hardcoding much of it, but that's not going to scale with any substantial team. You need real data management, build processes, etc. Where assets interact with each other you get incidental complexity of the Dwarf Fortress bug kind, so where you can, you add static checks. The engine is built in tandem with the asset pipeline, in effect.
So - whether it's 2D or 3D, what actually matters is the assets. That's why even in the early 80's you had vector games with 3D effects in them; they just took approaches that simplified the assets and the resulting scenes.
This reeks of moving the goalposts.
A 2D sprite-based game might be able to get away with a much simpler animation system and still look great. E.g. sprite flip-books and really basic translation will get very far for a lot of game styles. Even if you want rotations, you probably don't even need to learn about quaternions since 2d rotations are so much simpler and you might not need to do interpolation/blending.
A lot of other parts can be more complicated as well. E.g. testing navigability is difficult in 3D since it's not always clear what you are able to jump on to/fall off of/squeeze through. Relatively common bugs in 3D games are falling out the bottom of the map, escaping out the side, or getting stuck, but they almost never happen in 2D games.
Controlling the camera requires a lot more thought in a 3D game. In a 2D game, a fixed camera or a camera that rigidly follows a character is often sufficient. In 3D, the field of view is awkwardly shaped in world-space, and obstructions are more likely and you may need a way to deal with them (e.g. manual camera controls, detecting obstructions and making them transparent, or moving the camera to avoid them).
I guess a lot of this comes down to being able to design a 2d game that requires a very simple engine while even seemingly basic 3d games seem to need tons of features to be palatable.
Quaternions are not hard, they are just a tool to deal with 3D rotations. On the other hand, 2D rotations have other set of challenges. For instance, sprites that are naively rotated look very bad.
Other rendering shenanigans happen in 2D, too: arbitrary scaling, for instance, is trivial in 3D games, while a nightmare in 2D. There is no general algorithm to do so properly, and some people suggest NNs to have a good-looking solution, similar to NVIDIA's DLSS.
Camera is not easy in 2D either. There are tons of ways to make cameras for different kinds of games, with different tweaks. There are entire articles written on this out there. Obstructions also happen in 2D for some kinds of perspective and different games provide different solutions.
Not everything 2D is an 80's platformer. For sure, you can make trivial games in 2D easily, but that does not mean they will be good, polished games. Same way making trivial 3D games is easy yet not good enough.
A few years ago I made a mostly crappy 2D arcade game with a custom engine ("Fractus" on Steam). It basically started as a way to learn graphics tech and try out some visualization ideas. Slowly it turned into a real project. For a long time the journey of creating an engine was the main thing. Unfortunately, I think this shows in the final game quality... still working on that. I remember reading a post about having a "forever project". It's that piece of software that you keep going back to hack on because it feels good. I find a graphics engine to be a good choice for this.
If you have an idea/design/plan for a game, you probably shouldn't make your own engine without a compelling reason. But what if you don't really have an idea, yet still want to get into the programming side of games? Try working on a toy engine!
I find this super impressive, because (A) Coilworks was tiny, and (B) Cloudbuilt is a fully 3D, polygonal game.
While the simple graphics likely help, Super Cloudbuilt performs well, with great frame pacing and minimal input latency—not something I can say about a lot of more mainstream games on traditional engines. And Super Cloudbuilt is a lot of fun!
---
Of course, EV Nova was released for Windows and still runs fine. I'll start a new campaign every few years. Not sure if you can still purchase it legally tho - the company has gone under[2].
Also - if you enjoy EV, I highly recommend checking out Subspace! It's not the same, exactly, but it scratches a lot of the same itches for me.
Turns out people don't play engines, they play games. Just finishing making a game is hard enough and most don't make it that far. If you have to finish your engine before you start the remaining 90% of game development, well, keep your day job.
is it 100% true though ? I remember a lot of hours spent on Garry's Mod with my friend group as a teen, and that's borderline closer to a game engine than to a game
Making a game engine first and then making a game second is a fools errand, even if your goal is to make the game engine. However, you can make the engine in parallel with the game. Making a purpose-built engine in parallel with a game can be very reasonable.
Having made a number of games with and without off-the-shelf engines, whether or not a custom engine makes sense depends heavily on the specifics of your team and the game you are making.
Essentially another way to say KISS.