8 ms·

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

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.

badsectoracula 7y ago
> “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".
- klodolph 7y ago
  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.
  - chongli 7y ago
    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.
midnightclubbed 7y ago
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.
- mycall 7y ago
  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).
  - jcelerier 7y ago
    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
    - mycall 7y ago
      Perhaps too high expectation if bad reviews?
matheusmoreira 7y ago
> 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.
phaus 7y ago
Got any recommendations on how someone that can code a little but isn't a professional might go about learning to make an engine?
- hoorayimhelping 7y ago
  Sure: Make games, not engines. 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. https://github.com/hoorayimhelping/Galaga5 https://github.com/hoorayimhelping/Galaga5
- klodolph 7y ago
  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.
  - mekanicalsyncop 7y ago
    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.
_bxg1 7y ago
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.
- chongli 7y ago
  have it running flawlessly on-device in 5 minutes 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.
  - _bxg1 7y ago
dkersten 7y ago
> “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!
DeathArrow 7y ago
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.

badsectoracula 7y ago

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

klodolph 7y ago
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.
- chongli 7y ago
  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.

midnightclubbed 7y ago

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.

mycall 7y ago
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).
- jcelerier 7y ago
  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
  - mycall 7y ago
    Perhaps too high expectation if bad reviews?

matheusmoreira 7y ago

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

phaus 7y ago

Got any recommendations on how someone that can code a little but isn't a professional might go about learning to make an engine?

hoorayimhelping 7y ago
Sure: Make games, not engines. 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. https://github.com/hoorayimhelping/Galaga5 https://github.com/hoorayimhelping/Galaga5
klodolph 7y ago
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.
- mekanicalsyncop 7y ago
  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.

_bxg1 7y ago

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.

chongli 7y ago
have it running flawlessly on-device in 5 minutes 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.
- _bxg1 7y ago

dkersten 7y ago

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

DeathArrow 7y ago

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.