Unity, Unreal, Godot, Game Maker etc are all so popular these days it’s easy to lose sight of how you can make a game with a “custom engine”.
“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.
> “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.
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".
Yes, the meaning has definitely gotten distorted over the years. There’s also this frustrating tendency for people on forums to reply to questions about engines with advice to not make engines rather than answering the damn question.
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.
This is where moderation and strong guidelines are absolutely key. HN has a guideline specifically against shallow dismissals. Responding to a sincere question with "make games, don't make engines" would warrant moderator intervention on a place like this.
I think one of the hardest-to-replicate advantages of the big engines is ease of cross-platform builds/input/deployment. That was Unity's original killer-app (it's right in the name), and of course Unreal has caught up too. If you write a custom engine and you have any interest in targeting multiple platforms, you have to:
- 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.
I play a Unity game; Hearthstone. The number of engine-related bugs shocks me. My favorite is how the game completely locks up at the start of every match. Sounds stop playing, the UI freezes... it looks like the game has crashed. (I believe it's writing a ton of text to a log file, which is unfortunately part of their public API now because of deck trackers that read those files. Maybe it's also reading assets; I've never profiled it.) What amazes me is how consistent the behavior is across all platforms. It locks up on Windows, and it locks up on my iPad. Write once, run anywhere!
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.
Why would you assume that bug is caused by Unity? If anything, the fact that it doesn't happen in literally every other Unity game should tell you it's specific to Hearthstone. And the fact that Hearthstone has a single codebase across platforms means that if Blizzard ever fixes it, it'll be fixed on all platforms.
> What amazes me is how consistent the behavior is across all platforms. It locks up on Windows, and it locks up on my iPad. Write once, run anywhere!
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.
For sure, but “zero code changes -> flawlessly on-device in 5 minutes” is something that only happens if you have some serious expertise or prior experience with running your Unity apps on mobile devices. At least, in my experience. Even with the new input system (introduced in Unity 2019.1) there are serious considerations you need to make for input, general UX, and the different graphical capabilities (shaders) for mobile devices.
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've admittedly only done this with simple projects. But still, for those simple projects, "flawlessly" and "5 minutes" were not exaggerations. Even if a full-sized project ends up revealing some small gaps in the abstraction, it's still miles better than the alternative.
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.
> At that point, the advantage of having a "build for Android" button is greatly diminished.
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.
My previous job was game developing. You can't beat a full featured game engine for productivity.
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.
> “Make games, not engines” is fine advice in general but you can make an engine for your specific game
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!
Absolutely this.
The more your game design or visuals stray from the 'standard' feature set of an engine the more time you'll spend trying to bend it to your will.
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.
I would hope game engine systems would follow Open-Close principle and not require modifying the actual engine much (eg. not forward compatible with updates without large merges).
The open-closed principle does not matter much when the release is in 1 month, your game is running at 60% of the target FPS and you know that it won't be updated after release because it already got bad reviews
> 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.”
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.
A game engine is really just a set of libraries. And making good libraries that compose well and are at a useful abstraction level takes taste, which comes from experience.
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.
What kind of engine do you want to make and what is your goal by making that engine?
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.
I'd like to eventually learn to make a simple 3d engine suitable for a retro FPS. However, to start with I'd like to learn how to make 2d engines for side scrolling or isometric action games.
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.
You might find it valuable to make some simple games without using an existing engine. For example, a simple action platformer game is nice because the physics can be pretty simple.
Write one game. (Even if it's tiny, unpublished etc)
Then write a different one, but take bits where you can from the last game.
Any bits you reuse (or adapt) are now your engine!
Ideally then go back to game0 and reapply the changed engine/common parts. Port it to another platform, renderer etc
Tada! You have an engine :)
Repeat this over 20 years, rewrite from scratch every few years, switch to unity, unreal, then back to another rewrite!
As someone who writes a lot of server code, I've always been curious about the architecture for MMOs--how do you handle issues of scale (or is it fine to assume everything is running on the same server)? If you do concern yourself with scale, presumably you have to "shard" your universe somehow? Do you shard by in-game geographical regions? If so, how do you handle players moving from one region (shard) to another? What is the best practice for handling game state? A SQL database? A redis server? Or maybe you just keep things in memory and persist asynchronously? Can anyone recommend blog posts or similar on these subjects?
Fun fact: the word "shard" in this context was coined by the dev team of the first major commercial MMO, Ultima Online, as an in-universe explanation for why the game world was split into multiple servers.
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.
I have heard Richard Garriott claim credit for coining "shard," and I'm very skeptical. The first database paper I could find that uses "shard" (as an acronym: System for Highly Available Replicated DAta) is from 1986: https://dl.acm.org/doi/book/10.5555/889956
Those authors may have been first, but I seriously doubt they were a significant influence on the term's popularity. If there's one thing I've learned from reading a lot of CS papers, it's that pretty much any word you pick out of a hat has been used as an acronym by somebody.
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.
For most Indie MMOs you can use a single server. You also store game state in memory and checkpoint it to disk like a DB, instead of having a DB as a bottleneck. This can scale to many hundreds of thousands of concurrent users if you do it right and it's easier than building a distributed system.
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.
All those questions are answered on github in what probably is the smallest (as a feature, not a flaw) MMO system codebase in existence. Short answer is I made my own HTTP server from scratch with distributed database over HTTP and everything runs on top of that. Sharding on separate machines is not interesting because the whole point is to play together, no matter how; you always want to be connected somehow. Larger teams separate the services and it becomes really complex. I want to be able to develop and maintain a massive MMO on my own so I had to improvise.
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.
Persistence often uses much slower methods, one nice feature of my database is that it is distributed async. so I send all database queries to all regions which means I get backup and players can play anywhere without transferring data first.
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!
I know that "rules" say don't complain about downvotes, but man, I'm confused when people have downvoted me for complimenting someone's work and suggesting that you should support them. I stated it was $2 so that people who hadn't bothered checking out the Steam page would be aware of that, bu whatever.
@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.
People will downvote anything here. From facts to personal experience stories to complements, there are just people out there who downvote everything. And they'll get their friends to brigade too, just for the lulz. It's best not to worry about it, internalize it, or complain about it. They're just fake internet points after all.
I noticed an omission on this list was Minecraft. Today, the game of course has thousands of engineers working on the various versions of the game due to its success. But in the beginning (and throughout Alpha/Beta and during the beginning years of its 1.0 development) it was built on a hacked-together Java LIBJDX 2.0-based engine.
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.
Minecraft mods have not worked by manual replacement of classes for a long, long time now. Doing so is highly discouraged, and you use a mod loader like Forge.
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.
Sure, but on a technical level modding works exactly the same way. Modloaders like forge arose from a few issues with the simplified process I listed: for one, 2 mods that overwrite the same .class files conflict with each other and can’t be installed at the same time. Second, when new Minecraft versions come out it can be a pain to update your mod. Not to mention the update procedure mentioned above is pretty cumbersome for the average user.
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.
Right. It’s been years since they promised a modding API. Mods draw the community. A modding API is not a big ask considering the community has made half a dozen mod interfaces from the source code leak. MSsimply don’t want to spend any amount of resources to help development when they can’t justify how it will make them money. MS has been pushing monetization since they purchased Mojang. If you make a modding API then you can’t charge for items that do nothing besides limit creativity, such as player skins (the most basic example of something that everyone has been using as a creative part of the game even without mods).
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.
That was to be expected anyway, Microsoft Games division rather favored rewriting it into C++ than creating a Java compiler for each platform they would like to sell the game on.
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 the Java game certainly doesn't but the whole IP probably has a lot more people working on it than people think. You have the Java version, Bedrock version, AR game and all the ancillary porting involved as well as all the backend services etc. powering Realms and the other bits and pieces. I think thousands of engineers is a massive exaggeration but it's certainly going to be a lot.
Minecraft (the non-Java version) is on everything with a screen. Every game console this generation and last, iOS, Android, Windows Phone, every desktop OS, Apple TV, Gear VR, Fire TV. Simply managing all those different builds has to take lots of developer-hours, not to mention the fact that they're still adding features regularly.
I guess that's because of the design of the interface here. Generally speaking if I support or agree with something I upvote it. I typically only reply if I have something useful to add or I disagree. That also seems to be the general style of commenting here at least in my experience.
On all the various mods and variations, I don't doubt it's thousands. Minecraft took in all this generation's version of quake and half-life modders. In the late 90's early 2000's I remember tracking 20-30 different quake and half-life mods, most having small teams of people working on them. Minecraft is a couple orders of magnitude more popular, so I wouldn't doubt a few thousand. There's enough people making content for it that you can probably find a youtuber playing some new mod or specialty level with complex logic every day if you look.
Regarding A Plague Tale, I used to work at Asobo Studio on the Engine/Tools team. That was during the Toy Story 3 / Disney Pixar Heroes period. The in-house engine is called Zouna and is very good. However, the piece of software that was the most interesting to me is their in house level editor called PAWAP (can't remember what the acronym meant) . It's a 20+ years old C++ codebase dating back to Kalisto (where most of the founders of Asobo used to work), of course modernised over time. I changed code that was written before C++98 was standardised! The Engine team is amazing there and it shows in the games.
One surprising omission here was Paradox, which uses its own in-house engine for (AFAICT) all of its grand strategy games (though this seems to apply only to their own studio(s); Cities: Skylines, for example, is Unity-based, and I believe Surviving Mars derives from whatever engine Haemimont uses for its Tropico games).
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.
Yep, entirely new engine. Warband used a custom bytecode-like programming language that required Python scripts to generate, whereas Bannerlord uses C# and XML. The engine rewrite is a big reason why it took so long to develop, but it was well worth it.
As with all things, there's a balance and a place for technical trade offs to be made. The first entry on the list, Activision/Blizzard, built Hearthstone in Unity. A better case study would look at what games are successful, and then look at what engines they use.
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.
I am disabled and have played a bunch of games (DRM-free only, via GOG or Humble Bundle) and I can confirm that Unity games are extremely common, including on tiny 2d games, visual novels, etc. I wouldn't be surprised if over 5 of 8 games in the past decade (or at least the last 8 years) used Unity.
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.
This is awesome, it reminds me of RPG Maker 2000. Which was a staple of my childhood. I can't describe how fond I am of the memories I have with that tool.
I've stumbled across your page some time ago and forgot to bookmarket it, thank you for sharing it.
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.
Many of these game 'engines' are not engines at all in the Unreal/Unity sense of things. More a collection of libraries and code that are used to implement a game. For many games this is just fine (and sometimes a better fit than a monolithic engine).
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.
> 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!
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.
> 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
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.
I think the other thing to note is that you aren't really making an engine just making the game. You might have some reused bits culled from one game to the next but that's not really "an engine" so to speak.
I disagree on this one, for sure. That definition of “engine” is too narrow.
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'd call something an engine if it were reasonably general and could be repurposed. In the same way I can take the engine out of one car and plumb it into another. I'd also say an engine has to provide a relatively complete set of functionality otherwise you're building a library or framework. SDL as a classic example of that.
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.
> 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”.
I said I’d understand if you talked about the engine of The Witness. I think that is a fairly common colloquial expression. Engine is a fairly fuzzy concept at best. That you think there isn’t a different word like ‘tech’, ‘framework’, ‘libraries’ or the myriad of alternatives is by the by.
For example some of the framework for The Witness was ported to Jai for the sokoban game Thekla is working on.
Hard disagree as that is exactly what pretty much every engine outside those meant to be reused are all about - as an example pretty much all of id's engines licensees got the source code of the game the engine of which they were licensing. Even engines like Unreal Engine and LithTech which had a higher focus on 3rd party licensing were essentially code dumps of the games Epic/Monolith were 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.
It really depends. I've worked in games for fifteen years so have had my fair share of experience with both licensed and proprietary engines.
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've also worked in games for almost ~20 years now (though mainly proprietary engines), but i still do not see where "it depends".
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.
In the medium sized category, Valve is the obvious odd child. They have a small number of employees, but they also famously make Steam. This certainly requires a large amount of engineering effort, but also brings in literal billions in cash. They could almost certainly afford to outsource the creation of a custom game engine, since they have the cash flow and it’s probably not as core an activity as maintaining Steam.
But it could also be in house. I don’t have a feel for how many engineers it takes to make a game engine.
A game engine is really a project that scales really well with the size of the team. There are a monumental number of things you could put into one so they will swallow any number of engineers you throw at them.
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.
Well, before Steam was the behemoth it is today, all they had was the Source engine. Back when it first came out, everyone I know _hated_ Steam, but you had to install it to play Half Life 2 with it's new graphics, physics and facial animations.
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.
Speaking of Valve's source engine, in the recent chat log leaks, the Valve employee says the Source 2 engine is essentially just the Source 1 engine with new physics tacked on.
I don’t know why this would be surprising. They’re not gonna exactly throw everything away and start over, are they? Just like the Source engine is derived from the “GoldSrc” engine, which is the terrible name for the engine that Half Life used, and that engine is derived from the Quake engine.
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.
At the very least they added a Vulkan renderer too.
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.
The renderer and tooling were heavily overhauled, though it's hard to say if that's a "Source 2" thing. Engines are worked on constantly, systems are constantly being modified and features are added. Deciding to add a 2 at the end is mostly a marketing decision, since gamers fall for that hard.
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.
I guess in comparison to how far other storied engines such as UE4 have come, Source 2 does feel like its much less of a step forward.
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 really agree here. I've used Hammer since... well since it was Worldcraft and I used it for Quake levels. Maybe it's a VI vs EMACS type thing, but I latched onto it pretty quickly, and have always found it the easiest editor to use.
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.
I've been dabbling a bit in game development in recent years and have so far taken the approach of just building small composable libraries or headers encompassing units of functionality as needed.
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
Came here to mention Sapiens, an indie written from scratch by this guy named Dave, from NZ. Dave is great and goes through his development process of the custom Lua engine he wrote for his game engine, the AI, as well as design decions. Follow him here: https://www.youtube.com/user/majiDave
I am making a custom c++ 3D game engine using openGL right now and it's a massive undertaking. I have a lot of respect for folks like Jonathan Blow who manages to be an incredible game designer while also being a super programmer.
In my case, i just decided to give it a try because if i ever watch an engine/game maker software tutorial again i will most likely throw up.The amount of trivia knowledge you need to have to make something in those engines is huge and usually non transferible between them.
Also if you want to make sure you will provide the absolute best experience possible for your players, you need to have control of the low level stuff. I may be wrong but i don't think Unity allows you that kind of control. Two examples are Subnautica and Firewatch, while being excelent games in their own way, fail miserably in loading up the game assets in time after player spawn (subnautica mostly) and are filled with visual artifacts and texture problems (both games) while The Witness does not give you even the smallest hickup whatsoever.
>Also if you want to make sure you will provide the absolute best experience possible for your players, you need to have control of the low level stuff.
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.
Nice list! Interesting to see the breakdown of companies and which engines they use/which ones use completely custom ones and which use modified versions of stuff like Unity and Unreal engine.
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.
It seems to be missing Dunia (Far Cry series) in the Ubisoft list. You could say that since it is based on an (early) CryEngine it isn't "custom" but it already contains engines that were forked off 3rd party engines (IW from Quake 3, Creation from NetImmerse, Source 2 from Quake 1, etc).
> It would be really nice to know how many engineers are working on the engine division for each company, I'm sure there would be some big surprises, probably by the low number of engineers working in the engine and tools!
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.
Urho3d seems like it's a new engine, it seems like it's pretty good.
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.
A couple rather remarkable engines not listed:
-Whatever isometric games like AOE2DE are using and the custom engine used in Brigador. Brigador, esp, I read that the developers found that none of existing engines could satisfy their vision, so then spent a few years building their own. Finally it turned out good, the game though made by a very small team, looks spectacular, and runs well even on low end hardware.
-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.
Never heard of Brigador but it looks beautiful. Seems to be a pseudo-3D game. Lots of 2D assets, an isometric perspective, and modern graphics on top (I just saw in a Steam forum post that they light the sprites dynamically)
Also whatever Sumo Digital uses for their games like Sonic Allstars Racing Transformed.It had such lush water effects, but again no problem rendering it smoothly on low end hardware.
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.
I think the biggest reason for the custom code in the small teams is that they make 2D games. A 2D engine barely deserves the name and it's usually more hassle adapt to a 3rd party engine and its limitations than just write it yourself.
Sure there's a place for these engines. They abstract away graphics layers and bring convenience. But if you are a (semi-?) professional game dev, that's not a major hurdle.
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.
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.
Yes. That's a very fair point. Most engines I've seen try to implement a general physics model that can handle every genre of games, and there's a lot to be gained by not using that and building something more focused on what you actually need.
Further to that very few engines are developing their own general purpose physics solver and are using middleware. Bullet, PhysX and Box2D are the most popular.
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).
NVIDIA completely bungled PhysX because they chased accuracy for ML/robotics reasons in the newer releases, and the latest PhysX is slower and deprecated useful games tech like cloth.
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.
What do you mean by slower? Is it the new TGS solver you’re talking about (which is optional and really doesn’t need to be on for games)?
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.
Unity started their physics engine as a test of the job system. When they got the latest PhysX drop, and it was slower, they made it into a full team. Unreal had been annoyed with PhysX for a while, and entertained the idea of writing their own, but never actually did it. When Unity engineers told them about the latest PhysX updates, they launched the Chaos project.
NVIDIA's incompetence is what kicked both of them off, basically. Both engines will continue to support PhysX 3.6 for existing customers.
That depends on the engine. The big guys do. But the pure 2D engines do not.
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.
Those libraries don’t provide any game structure though (well, SDL and glfw at least, I think the other two do give you a small amount of structure), they only provide functions to get input style, open a window and basic rendering primitives. You can build an engine out of them, but I wouldn’t call them engines by themselves any more than you would call DirectX it the windows API a game engine.
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.
Yes! That was more or less my point. But since we're all confused anyways: Do you have an example for a real 2D game engine? with "game structure" as you call it.
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).
Commenting because noone else has mentioned it; I've been enjoying love2d[1] because it paves over all the annoying technical issues I might run into, and exposes it all in a nice lua api[2].
Most of those are libraries/frameworks rather than engines though. A fuzzy distinction I know but most of these are something you might build an engine of top of to avoid some of the cross-platform drudge.
GLFW, SFML, and SDL absolutely aren't game engines, I don't think it's fuzzy at all. They're libraries for graphics, audio, and other useful APIs. Monogame I'm not familiar with, but since I can't tell by skimming the wikipedia article, I'd call it fuzzy.
MonoGame as remake from XNA is much more higher level, as Microsoft made it for Indie games on the original XBox and WP7, and with some lessons taken from the earlier Managed Direct X attempt.
So while not at engine level, it already provides higher abstractions than those libraries, and a content pipeline.
You are still severely underestimating what a modern game engine does. The technical side is only one part of it. Integrated content creation and editing is a huge part of it.
That is the point: the "drawing code" is perhaps 20% of a game engine.
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...
The one who misunderstood is you. When people talk about a "game engine" in 2020, they are not talking about drawing code. They are talking about something much, much bigger.
"Drawing bitmaps" with SDL or OpenGL is a trivial part of developing a 2D engine.
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.
I'm so confused about the heat. The idea that 2D engines are orders of magnitude less complex than 3D engines is ubiquitous and frequently stated by many reputable game devs. Complex game engines will obviously have more complex code. Factorio in particular is certainly pushing the envelope there - with or without a 3rd party rendering engine. A better example would be 2D RPGs.
The distinction is in quantity and types of assets. In 2D you usually have some bitmap and vector assets, collision data, animations, and scene structures to tie it all together. In 3D you have all of those things plus the texture/model/material distinctions, lights, skybox, and all the other details that come in as you add more rendering capabilities.
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.
Because that's not what you were saying: You literally said a 2D engine barely deserved the name, and that it was usually not worth the hassle to use one rather than writing your own.
Animation is also a lot harder in 3D. A decent 3D engine will probably need fully featured skeletal animation: blending and interpolation, translate+scale+rotate, inverse kinematics, etc.
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.
Animations in 2D are not always flip-books and, when they are, the artist's job is harder and requires a lot of man-hours. That is why a game like Age of Empires 2 looks so good even in 2020.
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.
Even for 2D games, if you have a dedicated art team, or a level designer team separate from a programming team, having an engine interface that allows each of these participants to do their own stuff without having to edit code is a massive boost in productivity.
Game engines are super interesting. The variety of different things happening in the program, the audio/visual aspect, the real-time nature of the application. It's exciting to work on. It just feels like there is a software machine chugging forward.
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 was curios about Falcom since they have such consistently good games. I couldn't find a detailed lists but it sounds like most Falcom games (Including recent Ys games) use their own custom engine called the "Yamaneko Engine". Tokyo Xanadu and Cold Steel I and II (not sure about later ones) use Sony's PhyreEngine. They had 62 employees in 2019 according to Wikipedia.
One I didn't see on here—probably because they're not particularly well known—is the custom engine built by Coilworks for their game, Cloudbuilt[1].
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!
Adding to the list of small, single-developer-multi-year 2d games: Starsector[1]. It's a modern descendant of a whole set of top down shooters (I found it looking for a modern Escape Velocity, but it's quite different). The developer is very active and the modding community is huge - lots of total conversions and expansions have been created by the community.
The answer I've found the most often is Endless Sky[1]. It's open source and has the look. I've installed it and messed about before, but never gotten enough into it to feel like it's a worthy successor (for me).
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.
The general rule for small (single-developer or maybe teams of single digits) studios is "make games, not engines".
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.
That’s a reasonable general rule but it’s too easy to remember the short version “make games, not engines” and forget the underlying advice, which is more subtle.
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.
This is a great point and often forgotten at game studios. Without a game driving the engine feature set you will almost certainly end up with an engine design that tries to do 'everything' because your target is Unreal/Unity.
I go into detail in another post (search for make games, not engines) but the original meaning behind the phrase wasn't "do not make engines" (at the time it was originally posted you pretty much had to make your own engine) but "focus on your game's features when making your engine". It was meant as an advice to avoid feature creep in the engines people were making.
> Turns out people don't play engines, they play games
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
can I recommend «Autumn Night 3D Shooter» here? It's a short 3d shooter with custom engine that was made with love. Author boasts about it being 100% software-renderer (in other words, it doesn't use GPU acceleration)
“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.