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.
- 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.
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.
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.
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.
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.
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!
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.
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.
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.
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!
“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.