11 ms·

My first game with Carimbo, my homemade engine

298 points by mococa 2y ago

chainwax 2y ago
because code is like pasta In more ways than one
- mococa 2y ago
  You got it!
ashleyn 2y ago
Conventional wisdom dictates; make a game or make an engine. If you're making a serious effort at actually delivering a game, then you may want to use an existing engine. However it's also a nice challenge to write an engine of your own. And perhaps some true legends can actually do both - just look at Animal Well.
- mococa 2y ago
  I totally agree, or if I were in a game jam, but in my case it’s just for fun. I used to be a gamedev and don’t intend to go back.
  - Profan 2y ago
    Heck, I'm a gamedev right now and I completely understand the not going back bit
- chongli 2y ago
  The author made this game for his son. I think this qualifies more as a hobby/side project than a serious effort at delivering a marketable game. In the hobby case I think the conventional wisdom no longer applies. That puts this sort of project in line with folks building hot rods or restoring classic cars right down to the last bolt. Rebuilding a car's engine is a similar exercise which rarely makes commercial sense but can be an absolute joy for the hobbyist mechanic!
- sunrunner 2y ago
  It's always worth remembering that when people suggest not writing an engine the sentiment is usually "Don't try to write a Unity/Unreal/Godot equivalent". This is very reasonable advice. Those tools are software behemoths, by design, because they have to account for all possible use cases and give people a way of opting in to any possible combination of provided features, along with providing various abstractions (scene hierarchy, gameplay scripting, graphics API abstraction, materials, VFX, animation state trees, etc., the list is seemingly endless) as they need to support making essentially any kind of game. And not only are they software behemoths, they also represent a huge amount of mindshare in the form of documentation, support, community, customer-provided content, (marketplace assets) and so on. If you're making a game and you know what your requirements are up front, it's possible you just don't need most of what the engine provides. If you don't need to support multiple graphics APIs, you can get away with just using the specific API yourself (and then you don't need a different shading language). If you don't need complex VFX you might not need a VFX graph. If your rendering code is closer to your gameplay code you don't need a separate gameplay scripting system, you could actually write your gameplay code in the same language and build them together. Don't need rigid body simulation? Great! Throw that away. Don't need RVTs? Goodbye. And so on. That doesn't mean throwing away some engine-like structure, you'll almost certainly still end up with some representation of a scene, but if your requirements are minimal you can get away without most of what's in the above tools. And there's always the middle ground (that seems to get forgotten). Open source rendering libraries such as Ogre integrated into your own program, such that your game stops being a completely isolated component that sits on top of the engine and is regular code integrated with rendering (and so on), while being a more cohesive whole. Of course, if you need the features in Unity or Unreal and you don't have five years to burn then maybe you should just use them after all.
- yazzku 2y ago
  Here is what I dictate: this is fucking stupid and I'm tired of seeing this nonsense parroted. Working on your own engine gives you a level of understanding that cannot otherwise be obtained. It's like writing your own OS. This is very much a worthwhile endeavour. People should be encouraged to write their own crap, even if they don't end up using it on the job or whatever (whoever the fuck said this was the only metric for deciding what to work on?) because of the level of insight it provides. Generic engines like UE5 and Unity break down both in terms of functionality and performance the moment you do something they are not intended to do. They are also an overkill for a project of the scale shared here. From an engineering perspective, it's absolutely ridiculous to use an engine for this project. So please stop parroting this nonsense. Use your goddamn brain to form opinions. There isn't an off-the-shelf engine for that.
braden-lk 2y ago
Congrats! Game engines seem like such a gratifying pursuit that flexes every aspect of one’s skills. I just started reading Game Engine Archicture; if I can ever make the time I really want to take a crack at an engine.
- mococa 2y ago
  This book is really good; I’ve already gotten a lot of ideas from it.
- dakom 2y ago
  Love that book, great resource for lookup up all kinds of programming topics, whether game related or not
- shepherdjerred 2y ago
  Game programming patterns is also an excellent book. I referenced both of these when writing my engine.
- hoten 2y ago
  It's really a bottomless pit of interesting technical projects. Careful, if your game engine has users other than yourself, it is also a bottomless pit of feature requests and bug reports. Source: me
litenboll 2y ago
Very cool to see someone actually making a game in their hobby engine! Regarding the asset prefetching, you mention that they are loaded lazily. Maybe I'm misunderstanding but to me prefetching and lazy loading are the opposite (i.e. you would prefetch during a loading screen in order to avoid loading things on demand since it could affect the game loop). Could you elaborate?
- mococa 2y ago
  The prefetching works like this: a list of assets is provided, and in each main loop iteration, the engine opens and loads a single one into memory (an unordered map of shared pointers). It would be more effective in a longer game, where as the player moves, the assets are already being prepared for use. There’s also a mechanism to collect and remove unused assets from memory.
  - mococa 2y ago
    What I really wanted was to load the textures in a separate thread, but 10 years ago, when I tried it, I didn’t get good results. Maybe now things are different.
emanuele-em 2y ago
Very cool! Great blog too (add RSS!). You officially have new reader.
- mococa 2y ago
  Ah, a fellow RSS reader! Thank you!
samiv 2y ago
To anyone thinking about writing a game engine. I've been cranking on a 2D engine for over 4 years and have put thousands of hours of work into it. My summary: If you want to write a game, just write a game. Don't start with your own engine since this will suck all your time and you'll end up spending 90% on engine and very little getting the game game done. Especially so in the beginning when you have no features and doing anything in the game requires engine work. If you choose to create your own engine it's a compelling and fantastic domain where problems come in all shapes and sizes and you can and get to work with physics, maths, linear algebra, audio, rendering, graphics APIs, system level programming, most likely native programming AND scripting, game content, technical art etc. But finally the real work is not the engine but the tooling and the editor around the engine. If (when) you rely on free assets from (for example opengameart) you can expect no consistency. Not just the art style but just the technical part too, like your models are all inconsistent in shapes and sizes and axis, 2D content such as textures are by default without any meta data etc. So you really need to create a ton of tooling so that you can have sensible workflows and you can extract and consume the usable and interesting parts of any content package easily. This inevitably leads to the concept of "editor" which easily comes with a ton of work by itself that has nothing to do with game or game engine per se. For example the concept of "Project", windows, resource management, basic editing functionality for creating content, undo/redo/ etc. A lot of this is not really related to the game or the engine in anyway but you really sort of "must have it" if you want to create something that is actually usable. The feature creep is real! But once you get the over a lot of the boiler plate and you can actually use your own editor to stuff content into your own engine and have it running it's really a nice feeling even if nobody else cares! On the technical side my advice is really to be able to do first principles type of thinking. It's of utmost importance to be able to break things apart into self contained features and pieces that the game can then combine to create bigger constructs. If you can have your materials scroll textures vertically, when you combine that with shapes that are layered and place textures onto those shapes that scroll at various multiples of your "characters" speed then you've just created "parallax scrolling" essentially. ----- https://github.com/ensisoft/detonator https://github.com/ensisoft/detonator
- fidotron 2y ago
  I think the trap people fall into is to have things be overly specific in the name of optimization they never get to achieving anyway. For instance, I find you can get massive mileage by declaring “(almost) everything is instanced”, then you batch it, forget it, move on. There are similar shortcuts to be made with physics and so on. The close to ideal engine, in terms of approaches to problems, was LittleBigPlanet. That was a small team that were really good, but crucially they had the right way to frame the problems so as to constrain the emergent complexity of the result.
PretzelPirate 2y ago
If I run all the way to the right side of the screen past the enemy and shoot in any direction, the bullets immediately hit the enemy.
- mococa 2y ago
  Yes, the collision mechanism is incomplete, which is why I’m using the bullet position > 1200. Since you passed that threshold, any bullet will hit. My next step is to work on collision and physics; maybe I’ll use something like Box2D.
  - dakom 2y ago
    FYI, I recently posted about a 2d game I made, here: https://news.ycombinator.com/item?id=41761517 https://news.ycombinator.com/item?id=41761517 Putting aside the politics and all, focusing on the tech- one thing I came across when trying to do my own collision detection was the idea of using the GPU and occlusion queries for pixel-perfect results. I didn't come up with the technique, but it's super cool, and since you're not taxing the GPU with tons of 3d triangles, it's perhaps a bit more free to do stuff like that.
    - mococa 2y ago
      Using the GPU is always interesting, although in my case I want to maintain compatibility with browsers through WebAssembly. Nowadays, it’s very rare for a user to download and run a binary.
      - hedvig23 2y ago
        Ignorant question, but I assume that means there is no "browser-facing" or accessibility to the GPU for a web based application in this way (WebAssembled or even otherwise)?
        __m 2y ago
        There is WebGPU, but support isn’t widespread yet. Compared to WebGL it does allow you to create compute “shaders”
onikolas7 2y ago
For anyone looking to write their own engine, I wrote a tutorial! You just need the tutorial and a couple of years :) https://nik-os.com/agl/00_intro.html https://nik-os.com/agl/00_intro.html
- wilberton 2y ago
  Very cool - nice tutorial! I've released a few games with my home made engine (most recently https://poki.com/en/g/blaze-drifter https://poki.com/en/g/blaze-drifter) My best advice is only write enough engine to support the game you want to make. Also don't try and write an editor, but add debug/editor tools directly in the game. With each game you make, you can add one or two new features to the engine, and slowly build up the feature set to be able to make larger games.
  - onikolas7 2y ago
    Totally agree! I am now writing a very simple hack'n slash game to identify missing features. I won't be writing an editor any time soon. Do you have any examples of good debugging features?
    - wilberton 2y ago
      I started with a simple on screen 'watch variable', so I can visually inspect values over time. I added simple click drag edit support so I can then edit a value too. Over time I've added a (very simple) console, a simple immediate mode debug UI, graphing for the watch variables, and a little track editor (with the debug UI). Again the key is to build only what you need and only when you need it. It sounds quite a lot when I write it down, but it's all super simple and only supports the barest features that I actually need.
- deleted 2y ago
  [deleted]
- metalliqaz 2y ago
  "anyone can draw" I wish
slmjkdbtl 2y ago
I think most "I want to make an engine so I can make games faster" people are cursed to make engines forever, this is rare.
- shepherdjerred 2y ago
  The only thing more impressive than writing a game engine is actually using it
- 01HNNWZ0MV43FF 2y ago
  That is truly a curse. I just want to make an engine so I can say I did everything from scratch
  - sunrunner 2y ago
    I hope by 'everything' that includes the text editor and compiler you'll used in the development process ;)
    - slmjkdbtl 2y ago
      That's literally what I fall into, making an engine then falls deeper into making programming language and editors, it's an endless hole.
    - 01HNNWZ0MV43FF 2y ago
      Buddy if I retire early I will ;)
- Cthulhu_ 2y ago
  At least that's a goal, a lot of people say "I want to make a game" but get stuck in the making an engine part. Which is also valid, don't get me wrong - if you enjoy it, by all means! However it's not building a game, it's building a game engine. Anyone that wants to build an engine (or a CMS, or whatever) with the goal of making a game should try making one or more games with one or more existing engines first, if only to get a better idea of features and shortcomings. And if they really want to make games, or just the engine.
darepublic 2y ago
I also have kids and have toyed with the notion of making games with/for them. Thank you for the inspiration!
Buttons840 2y ago
I think the best advice for making your own game is: do what you're most excited to do. Do you spend time thinking about making your own game engine? Then start making it. Be willing to change course later if it's too hard, your time will not be wasted. I got into gamedev by messing around with making my own engine, mostly focusing on low level graphics APIs, and that knowledge transferred well when I switched to a professional game engine. I knew about shaders and such and knew I was somewhat prepared to alter the engine I was using if needed. Or, the other way, if you start making a game in an engine and you hate it, your efforts are not wasted. The truth is like 10 or 20 thousand lines of game logic can make a lot of games, and that's really not much code to port to your own game engine compared to the rest of the engine. All the art and other assets can be ported too. Plus, if you know a professional game engine you can use it for tooling or get some good architecture ideas to use in your own engine. So, just get moving with whatever excites you most and be willing to change course.
- stroupwaffle 2y ago
  Another way to think of this is not making a “game engine” but just “making a game”. Get rid of all the generic stuff and use some common patterns that fit the game exactly. No need to over-abstract!
  - MattRix 2y ago
    That’s not what the person you replied to is saying though… They’re saying just use an existing engine, and if you really need to, you can always write your own engine later if you really need it.
    - stroupwaffle 2y ago
      Yeah I’m just saying in general. I probably shouldn’t have replied to anyone in particular—just jumping in the conversation. =)
    - zelphirkalt 2y ago
      I read it to mean the other way around: If writing the engine interests you, do it, you can switch to another existing game engine later, and your experience is not lost.
kkukshtel 2y ago
I think maybe opposed to some of the other opinions here, making your own engine is much easier than you think and has a lot of potential upside. On a walk today I was thinking about something specific that I think is under-discussed. Yes people bikeshed etc. but when you create your own engine you are _fiercely_ aware of _everything_ it can and can't do. As part of this, it's very easy to feel fully in command of your own toolset, and as such able to exhibit mastery over that toolset. Granted, the scope of possibility when you start out building your own tool is narrow, but in some ways that acts as an easier onboarding to expertise instead of getting dumped into something as powerful as Unity/Unreal/Godot with little orientation and lots of edges you don't know about. In using some super-general you have to carve out your own path through its features, which is cognitive load (and time!) you don't need to worry about when you create your own. For similar reasons I'm _also_ making my own engine. It's 2D-only engine that uses lots of modern C# features to make for rapid programming of 2D games. For the game I'm making with it to start, I'm using literally every feature of the engine, which is something I don't think I'd ever be able to say for something more general purpose. For anyone interested: https://github.com/zinc-framework https://github.com/zinc-framework
- adamrezich 2y ago
  After trying to evangelize this exact mindset to people in the wake of the recent Godot drama, I've given up (or not, judging by my posts here…). Most people aren't willing to even investigate how easy it is to make “a game engine”, because the term “game engine” has been mythologized (due to Unity, Godot, etc.) into being this thing that's for all practical purposes impossible for the average programmer to build. “As a solo developer, either you work on building an engine, or you work on building a game, but if you're going to do the former, then you'll never complete the latter,” they say (in this very comments section, even). Well, sure… if by “game engine” you mean “general-purpose super-generic game engine,” and not “the smallest set of things absolutely necessary to transmute the idea I have in my head into playable form on this supercomputer I'm sitting in front of.” I don't really get it—I started programming games by learning Game Maker in the early 00s. By the time I was ready to move onto something more like “real game development” (C#/XNA), I was more than eager to structure things more according to how I wanted for whatever given project I was working on, rather than trying to cram my ideas into a somebody-else's-engine-shaped hole. But the freely-downloadable general-purpose game engines available these days, with their innumerable layers of wholly-unnecessary overly-generalized one-size-fits-all abstractions have gotten most people who use them to never even consider even imagining doing things in any way other than the way they're now used to doing them, using their tool of choice. They're more than happy to settle with thinking about game design purely in terms of whatever high-level primitives are exposed by their preferred engine, rather than even consider even imagining what it would be like to have complete control over how their game logic is organized and executed. Why simply define structs and make arrays of struct instances and iterate over them, when you could make a byzantine web of Nodes/GameObjects in the engine-provided scene graph? I guess that's how indie “game developers” these days have been trained to think. And it's crazy because compared to only a couple short decades ago, there's more information and resources available out there on the Web for free, that anyone can read and use to make building something “from scratch” (where “from scratch” means “using open-source libraries to do the parts you don't want to learn more about for the time being, such as rendering”) easier than it ever has been before! You can use something like SDL or Raylib to “sketch out” a gameplay prototype in shockingly few lines of code, then refactor everything so that all library calls are wrapped in function calls more suited to your use case, and then, later, if you want, you can replace those library calls with your own code! It's not difficult to do at all, but I think there's just some level of comfort people take in having a GUI editor for their “game engine” that they can open a blank project in and start clicking around to make things happen on the screen, compared to staring at a blank source code file and figuring out where to go from there. The ever-decreasing baseline level of curiosity and hacker-thinking in younger programmers continues to both baffle and depress me.
zoogeny 2y ago
I've been really interested in things like raylib [1] and other minimal C libraries for lower-level game-engine-like capabilities. There is a widening middle ground available for developers between writing your own engine completely from scratch and using a full-featured engine like Godot, Unity, or Unreal. There was always stuff like SDL but these new minimal libraries hit a sweet spot for a lot of cases. 1. https://www.raylib.com/ https://www.raylib.com/
- scruple 2y ago
  I'm currently using raylib and Odin to build a 2D platformer for my twins. I built out a PoC with a couple of levels. Now I'm working my way through a level editor. It has completely reinvigorated my passion for programming.
- wilberton 2y ago
  Yup, raylib is great. Sokol is another solid choice for the low level bits - that's what my engine is built with and it's excellent (at least for indie level games).
bcrosby95 2y ago
Am I the only one who thinks the word "engine" is overused? I've always assumed that "make a game, or make an engine" meant: if you decide to not use an engine when making your game, don't abstract it and also make an engine. In other words, don't overengineer your game and build a generic engine when you don't need to. Have I interpreted this wrong all these years? Or did the phrase morph because everyone thinks everything is too hard to program yourself these days?
- adamrezich 2y ago
  “Game engine” is supposed to simply mean, the parts of the game code that aren't the main game logic—the stuff that handles asset loading, entity management, input detection, rendering, sound playback—that sort of thing. It could be used to refer to Unreal Engine… or it could just mean the simple, minimal homemade tech stack that you built your game upon. Or anything in-between. But you hit the nail on the head—it's definitely one of those terms that has been warped and downright mythologized in recent years, with the rise of free-to-download general-purpose GUI-editor “game engines”, and their ensuing popularity.
- sunrunner 2y ago
  > if you decide to not use an engine when making your game, don't abstract it and also make an engine. Exactly this. Do the minimal thing correct for your situation (your own rendering if desired/required or integrating a third party solution, free or otherwise) and don't spend a year on stable rigid body simulations in a completely general-purpose and reusable tool (that is only reusable for you because it's almost a guarantee it won't be general purpose enough or documented well enough for anyone else) if you don't need the objects to behave with some level of physical realism. Smaller personal and hobbyist projects have the freedom to make a lot more choices around 'how' they get to their end goal, and I think they should use that opportunity. If you're genuinely intending to make the next indie hit, the actual tech is not likely to be the most difficult thing for success, whether you use Unity or your own tools. > because everyone thinks everything is too hard to program yourself these days? Without getting too cynical, it seems like there's a culture of ignorance in some places where large long-lived software projects created by other people over time are treated as black boxes, impossible to understand, and not for the likes of mere mortals to even attempt to comprehend.
agentultra 2y ago
Good for you, friend. Honestly more people should try it before they knock it. Programming a game from scratch is not rocket science. It takes some work to get to finished game but sometimes the journey is what people care about and want to master. No need to always be optimizing for the end result. I make stuff with wood. I don’t use power tools. I use hand tools. Because I like doing it that way. Hope your kid has fun playing the game!
eternityforest 2y ago
Actually making a game in a homemade engine? I'm impressed!
dusted 2y ago
For smaller games, there's some charm in not making a game engine, and not using one either, but just writing the game, sure this falls apart easily, if you find yourself needing something you're not able/willing to make from scratch, but a lot of very entertaining stuff can be made by just programming the game rather than trying to create an elegant api for your engine, or trying to learn and wrangle an exisiting engine into submission.
pmontra 2y ago
Kind of meta question: local engine = EngineFactory.new() I expect that a new instance of a factory class is a factory, not an engine. To get an engine, just create a new instance of an engine class. Examples of what I expect: local engine = Engine.new() or a more convoluted local factory = EngineFactory.new() local engine = factory:build_engine()
- mococa 2y ago
  Good catch. I will fix this, thank you!
tony-allan 2y ago
On a separate note the authors setup https://nullonerror.org/2024/03/20/my-2024-setup/ https://nullonerror.org/2024/03/20/my-2024-setup/

298 points by mococa 2y ago

chainwax 2y ago

because code is like pasta In more ways than one

mococa 2y ago
You got it!

ashleyn 2y ago

Conventional wisdom dictates; make a game or make an engine. If you're making a serious effort at actually delivering a game, then you may want to use an existing engine. However it's also a nice challenge to write an engine of your own. And perhaps some true legends can actually do both - just look at Animal Well.

mococa 2y ago
I totally agree, or if I were in a game jam, but in my case it’s just for fun. I used to be a gamedev and don’t intend to go back.
- Profan 2y ago
  Heck, I'm a gamedev right now and I completely understand the not going back bit
chongli 2y ago
The author made this game for his son. I think this qualifies more as a hobby/side project than a serious effort at delivering a marketable game. In the hobby case I think the conventional wisdom no longer applies. That puts this sort of project in line with folks building hot rods or restoring classic cars right down to the last bolt. Rebuilding a car's engine is a similar exercise which rarely makes commercial sense but can be an absolute joy for the hobbyist mechanic!
sunrunner 2y ago
It's always worth remembering that when people suggest not writing an engine the sentiment is usually "Don't try to write a Unity/Unreal/Godot equivalent". This is very reasonable advice. Those tools are software behemoths, by design, because they have to account for all possible use cases and give people a way of opting in to any possible combination of provided features, along with providing various abstractions (scene hierarchy, gameplay scripting, graphics API abstraction, materials, VFX, animation state trees, etc., the list is seemingly endless) as they need to support making essentially any kind of game. And not only are they software behemoths, they also represent a huge amount of mindshare in the form of documentation, support, community, customer-provided content, (marketplace assets) and so on. If you're making a game and you know what your requirements are up front, it's possible you just don't need most of what the engine provides. If you don't need to support multiple graphics APIs, you can get away with just using the specific API yourself (and then you don't need a different shading language). If you don't need complex VFX you might not need a VFX graph. If your rendering code is closer to your gameplay code you don't need a separate gameplay scripting system, you could actually write your gameplay code in the same language and build them together. Don't need rigid body simulation? Great! Throw that away. Don't need RVTs? Goodbye. And so on. That doesn't mean throwing away some engine-like structure, you'll almost certainly still end up with some representation of a scene, but if your requirements are minimal you can get away without most of what's in the above tools. And there's always the middle ground (that seems to get forgotten). Open source rendering libraries such as Ogre integrated into your own program, such that your game stops being a completely isolated component that sits on top of the engine and is regular code integrated with rendering (and so on), while being a more cohesive whole. Of course, if you need the features in Unity or Unreal and you don't have five years to burn then maybe you should just use them after all.
yazzku 2y ago
Here is what I dictate: this is fucking stupid and I'm tired of seeing this nonsense parroted. Working on your own engine gives you a level of understanding that cannot otherwise be obtained. It's like writing your own OS. This is very much a worthwhile endeavour. People should be encouraged to write their own crap, even if they don't end up using it on the job or whatever (whoever the fuck said this was the only metric for deciding what to work on?) because of the level of insight it provides. Generic engines like UE5 and Unity break down both in terms of functionality and performance the moment you do something they are not intended to do. They are also an overkill for a project of the scale shared here. From an engineering perspective, it's absolutely ridiculous to use an engine for this project. So please stop parroting this nonsense. Use your goddamn brain to form opinions. There isn't an off-the-shelf engine for that.

braden-lk 2y ago

Congrats! Game engines seem like such a gratifying pursuit that flexes every aspect of one’s skills. I just started reading Game Engine Archicture; if I can ever make the time I really want to take a crack at an engine.

mococa 2y ago
This book is really good; I’ve already gotten a lot of ideas from it.
dakom 2y ago
Love that book, great resource for lookup up all kinds of programming topics, whether game related or not
shepherdjerred 2y ago
Game programming patterns is also an excellent book. I referenced both of these when writing my engine.
hoten 2y ago
It's really a bottomless pit of interesting technical projects. Careful, if your game engine has users other than yourself, it is also a bottomless pit of feature requests and bug reports. Source: me

litenboll 2y ago

Very cool to see someone actually making a game in their hobby engine! Regarding the asset prefetching, you mention that they are loaded lazily. Maybe I'm misunderstanding but to me prefetching and lazy loading are the opposite (i.e. you would prefetch during a loading screen in order to avoid loading things on demand since it could affect the game loop). Could you elaborate?

mococa 2y ago
The prefetching works like this: a list of assets is provided, and in each main loop iteration, the engine opens and loads a single one into memory (an unordered map of shared pointers). It would be more effective in a longer game, where as the player moves, the assets are already being prepared for use. There’s also a mechanism to collect and remove unused assets from memory.
- mococa 2y ago
  What I really wanted was to load the textures in a separate thread, but 10 years ago, when I tried it, I didn’t get good results. Maybe now things are different.

emanuele-em 2y ago

Very cool! Great blog too (add RSS!). You officially have new reader.

mococa 2y ago
Ah, a fellow RSS reader! Thank you!

samiv 2y ago

To anyone thinking about writing a game engine. I've been cranking on a 2D engine for over 4 years and have put thousands of hours of work into it. My summary: If you want to write a game, just write a game. Don't start with your own engine since this will suck all your time and you'll end up spending 90% on engine and very little getting the game game done. Especially so in the beginning when you have no features and doing anything in the game requires engine work. If you choose to create your own engine it's a compelling and fantastic domain where problems come in all shapes and sizes and you can and get to work with physics, maths, linear algebra, audio, rendering, graphics APIs, system level programming, most likely native programming AND scripting, game content, technical art etc. But finally the real work is not the engine but the tooling and the editor around the engine. If (when) you rely on free assets from (for example opengameart) you can expect no consistency. Not just the art style but just the technical part too, like your models are all inconsistent in shapes and sizes and axis, 2D content such as textures are by default without any meta data etc. So you really need to create a ton of tooling so that you can have sensible workflows and you can extract and consume the usable and interesting parts of any content package easily. This inevitably leads to the concept of "editor" which easily comes with a ton of work by itself that has nothing to do with game or game engine per se. For example the concept of "Project", windows, resource management, basic editing functionality for creating content, undo/redo/ etc. A lot of this is not really related to the game or the engine in anyway but you really sort of "must have it" if you want to create something that is actually usable. The feature creep is real! But once you get the over a lot of the boiler plate and you can actually use your own editor to stuff content into your own engine and have it running it's really a nice feeling even if nobody else cares! On the technical side my advice is really to be able to do first principles type of thinking. It's of utmost importance to be able to break things apart into self contained features and pieces that the game can then combine to create bigger constructs. If you can have your materials scroll textures vertically, when you combine that with shapes that are layered and place textures onto those shapes that scroll at various multiples of your "characters" speed then you've just created "parallax scrolling" essentially. ----- https://github.com/ensisoft/detonator https://github.com/ensisoft/detonator

fidotron 2y ago
I think the trap people fall into is to have things be overly specific in the name of optimization they never get to achieving anyway. For instance, I find you can get massive mileage by declaring “(almost) everything is instanced”, then you batch it, forget it, move on. There are similar shortcuts to be made with physics and so on. The close to ideal engine, in terms of approaches to problems, was LittleBigPlanet. That was a small team that were really good, but crucially they had the right way to frame the problems so as to constrain the emergent complexity of the result.

PretzelPirate 2y ago

If I run all the way to the right side of the screen past the enemy and shoot in any direction, the bullets immediately hit the enemy.

mococa 2y ago
Yes, the collision mechanism is incomplete, which is why I’m using the bullet position > 1200. Since you passed that threshold, any bullet will hit. My next step is to work on collision and physics; maybe I’ll use something like Box2D.
- dakom 2y ago
  FYI, I recently posted about a 2d game I made, here: https://news.ycombinator.com/item?id=41761517 https://news.ycombinator.com/item?id=41761517 Putting aside the politics and all, focusing on the tech- one thing I came across when trying to do my own collision detection was the idea of using the GPU and occlusion queries for pixel-perfect results. I didn't come up with the technique, but it's super cool, and since you're not taxing the GPU with tons of 3d triangles, it's perhaps a bit more free to do stuff like that.
  - mococa 2y ago
    Using the GPU is always interesting, although in my case I want to maintain compatibility with browsers through WebAssembly. Nowadays, it’s very rare for a user to download and run a binary.
    - hedvig23 2y ago
      Ignorant question, but I assume that means there is no "browser-facing" or accessibility to the GPU for a web based application in this way (WebAssembled or even otherwise)?
      - __m 2y ago
        There is WebGPU, but support isn’t widespread yet. Compared to WebGL it does allow you to create compute “shaders”

onikolas7 2y ago

For anyone looking to write their own engine, I wrote a tutorial! You just need the tutorial and a couple of years :) https://nik-os.com/agl/00_intro.html https://nik-os.com/agl/00_intro.html

wilberton 2y ago
Very cool - nice tutorial! I've released a few games with my home made engine (most recently https://poki.com/en/g/blaze-drifter https://poki.com/en/g/blaze-drifter) My best advice is only write enough engine to support the game you want to make. Also don't try and write an editor, but add debug/editor tools directly in the game. With each game you make, you can add one or two new features to the engine, and slowly build up the feature set to be able to make larger games.
- onikolas7 2y ago
  Totally agree! I am now writing a very simple hack'n slash game to identify missing features. I won't be writing an editor any time soon. Do you have any examples of good debugging features?
  - wilberton 2y ago
    I started with a simple on screen 'watch variable', so I can visually inspect values over time. I added simple click drag edit support so I can then edit a value too. Over time I've added a (very simple) console, a simple immediate mode debug UI, graphing for the watch variables, and a little track editor (with the debug UI). Again the key is to build only what you need and only when you need it. It sounds quite a lot when I write it down, but it's all super simple and only supports the barest features that I actually need.
deleted 2y ago
[deleted]
metalliqaz 2y ago
"anyone can draw" I wish

slmjkdbtl 2y ago

I think most "I want to make an engine so I can make games faster" people are cursed to make engines forever, this is rare.

shepherdjerred 2y ago
The only thing more impressive than writing a game engine is actually using it
01HNNWZ0MV43FF 2y ago
That is truly a curse. I just want to make an engine so I can say I did everything from scratch
- sunrunner 2y ago
  I hope by 'everything' that includes the text editor and compiler you'll used in the development process ;)
  - slmjkdbtl 2y ago
    That's literally what I fall into, making an engine then falls deeper into making programming language and editors, it's an endless hole.
  - 01HNNWZ0MV43FF 2y ago
    Buddy if I retire early I will ;)
Cthulhu_ 2y ago
At least that's a goal, a lot of people say "I want to make a game" but get stuck in the making an engine part. Which is also valid, don't get me wrong - if you enjoy it, by all means! However it's not building a game, it's building a game engine. Anyone that wants to build an engine (or a CMS, or whatever) with the goal of making a game should try making one or more games with one or more existing engines first, if only to get a better idea of features and shortcomings. And if they really want to make games, or just the engine.

darepublic 2y ago

I also have kids and have toyed with the notion of making games with/for them. Thank you for the inspiration!

Buttons840 2y ago

I think the best advice for making your own game is: do what you're most excited to do. Do you spend time thinking about making your own game engine? Then start making it. Be willing to change course later if it's too hard, your time will not be wasted. I got into gamedev by messing around with making my own engine, mostly focusing on low level graphics APIs, and that knowledge transferred well when I switched to a professional game engine. I knew about shaders and such and knew I was somewhat prepared to alter the engine I was using if needed. Or, the other way, if you start making a game in an engine and you hate it, your efforts are not wasted. The truth is like 10 or 20 thousand lines of game logic can make a lot of games, and that's really not much code to port to your own game engine compared to the rest of the engine. All the art and other assets can be ported too. Plus, if you know a professional game engine you can use it for tooling or get some good architecture ideas to use in your own engine. So, just get moving with whatever excites you most and be willing to change course.

stroupwaffle 2y ago
Another way to think of this is not making a “game engine” but just “making a game”. Get rid of all the generic stuff and use some common patterns that fit the game exactly. No need to over-abstract!
- MattRix 2y ago
  That’s not what the person you replied to is saying though… They’re saying just use an existing engine, and if you really need to, you can always write your own engine later if you really need it.
  - stroupwaffle 2y ago
    Yeah I’m just saying in general. I probably shouldn’t have replied to anyone in particular—just jumping in the conversation. =)
  - zelphirkalt 2y ago
    I read it to mean the other way around: If writing the engine interests you, do it, you can switch to another existing game engine later, and your experience is not lost.

kkukshtel 2y ago

I think maybe opposed to some of the other opinions here, making your own engine is much easier than you think and has a lot of potential upside. On a walk today I was thinking about something specific that I think is under-discussed. Yes people bikeshed etc. but when you create your own engine you are _fiercely_ aware of _everything_ it can and can't do. As part of this, it's very easy to feel fully in command of your own toolset, and as such able to exhibit mastery over that toolset. Granted, the scope of possibility when you start out building your own tool is narrow, but in some ways that acts as an easier onboarding to expertise instead of getting dumped into something as powerful as Unity/Unreal/Godot with little orientation and lots of edges you don't know about. In using some super-general you have to carve out your own path through its features, which is cognitive load (and time!) you don't need to worry about when you create your own. For similar reasons I'm _also_ making my own engine. It's 2D-only engine that uses lots of modern C# features to make for rapid programming of 2D games. For the game I'm making with it to start, I'm using literally every feature of the engine, which is something I don't think I'd ever be able to say for something more general purpose. For anyone interested: https://github.com/zinc-framework https://github.com/zinc-framework

adamrezich 2y ago
After trying to evangelize this exact mindset to people in the wake of the recent Godot drama, I've given up (or not, judging by my posts here…). Most people aren't willing to even investigate how easy it is to make “a game engine”, because the term “game engine” has been mythologized (due to Unity, Godot, etc.) into being this thing that's for all practical purposes impossible for the average programmer to build. “As a solo developer, either you work on building an engine, or you work on building a game, but if you're going to do the former, then you'll never complete the latter,” they say (in this very comments section, even). Well, sure… if by “game engine” you mean “general-purpose super-generic game engine,” and not “the smallest set of things absolutely necessary to transmute the idea I have in my head into playable form on this supercomputer I'm sitting in front of.” I don't really get it—I started programming games by learning Game Maker in the early 00s. By the time I was ready to move onto something more like “real game development” (C#/XNA), I was more than eager to structure things more according to how I wanted for whatever given project I was working on, rather than trying to cram my ideas into a somebody-else's-engine-shaped hole. But the freely-downloadable general-purpose game engines available these days, with their innumerable layers of wholly-unnecessary overly-generalized one-size-fits-all abstractions have gotten most people who use them to never even consider even imagining doing things in any way other than the way they're now used to doing them, using their tool of choice. They're more than happy to settle with thinking about game design purely in terms of whatever high-level primitives are exposed by their preferred engine, rather than even consider even imagining what it would be like to have complete control over how their game logic is organized and executed. Why simply define structs and make arrays of struct instances and iterate over them, when you could make a byzantine web of Nodes/GameObjects in the engine-provided scene graph? I guess that's how indie “game developers” these days have been trained to think. And it's crazy because compared to only a couple short decades ago, there's more information and resources available out there on the Web for free, that anyone can read and use to make building something “from scratch” (where “from scratch” means “using open-source libraries to do the parts you don't want to learn more about for the time being, such as rendering”) easier than it ever has been before! You can use something like SDL or Raylib to “sketch out” a gameplay prototype in shockingly few lines of code, then refactor everything so that all library calls are wrapped in function calls more suited to your use case, and then, later, if you want, you can replace those library calls with your own code! It's not difficult to do at all, but I think there's just some level of comfort people take in having a GUI editor for their “game engine” that they can open a blank project in and start clicking around to make things happen on the screen, compared to staring at a blank source code file and figuring out where to go from there. The ever-decreasing baseline level of curiosity and hacker-thinking in younger programmers continues to both baffle and depress me.

zoogeny 2y ago

I've been really interested in things like raylib [1] and other minimal C libraries for lower-level game-engine-like capabilities. There is a widening middle ground available for developers between writing your own engine completely from scratch and using a full-featured engine like Godot, Unity, or Unreal. There was always stuff like SDL but these new minimal libraries hit a sweet spot for a lot of cases. 1. https://www.raylib.com/ https://www.raylib.com/

scruple 2y ago
I'm currently using raylib and Odin to build a 2D platformer for my twins. I built out a PoC with a couple of levels. Now I'm working my way through a level editor. It has completely reinvigorated my passion for programming.
wilberton 2y ago
Yup, raylib is great. Sokol is another solid choice for the low level bits - that's what my engine is built with and it's excellent (at least for indie level games).

bcrosby95 2y ago

Am I the only one who thinks the word "engine" is overused? I've always assumed that "make a game, or make an engine" meant: if you decide to not use an engine when making your game, don't abstract it and also make an engine. In other words, don't overengineer your game and build a generic engine when you don't need to. Have I interpreted this wrong all these years? Or did the phrase morph because everyone thinks everything is too hard to program yourself these days?

adamrezich 2y ago
“Game engine” is supposed to simply mean, the parts of the game code that aren't the main game logic—the stuff that handles asset loading, entity management, input detection, rendering, sound playback—that sort of thing. It could be used to refer to Unreal Engine… or it could just mean the simple, minimal homemade tech stack that you built your game upon. Or anything in-between. But you hit the nail on the head—it's definitely one of those terms that has been warped and downright mythologized in recent years, with the rise of free-to-download general-purpose GUI-editor “game engines”, and their ensuing popularity.
sunrunner 2y ago
> if you decide to not use an engine when making your game, don't abstract it and also make an engine. Exactly this. Do the minimal thing correct for your situation (your own rendering if desired/required or integrating a third party solution, free or otherwise) and don't spend a year on stable rigid body simulations in a completely general-purpose and reusable tool (that is only reusable for you because it's almost a guarantee it won't be general purpose enough or documented well enough for anyone else) if you don't need the objects to behave with some level of physical realism. Smaller personal and hobbyist projects have the freedom to make a lot more choices around 'how' they get to their end goal, and I think they should use that opportunity. If you're genuinely intending to make the next indie hit, the actual tech is not likely to be the most difficult thing for success, whether you use Unity or your own tools. > because everyone thinks everything is too hard to program yourself these days? Without getting too cynical, it seems like there's a culture of ignorance in some places where large long-lived software projects created by other people over time are treated as black boxes, impossible to understand, and not for the likes of mere mortals to even attempt to comprehend.

agentultra 2y ago

Good for you, friend. Honestly more people should try it before they knock it. Programming a game from scratch is not rocket science. It takes some work to get to finished game but sometimes the journey is what people care about and want to master. No need to always be optimizing for the end result. I make stuff with wood. I don’t use power tools. I use hand tools. Because I like doing it that way. Hope your kid has fun playing the game!

eternityforest 2y ago

Actually making a game in a homemade engine? I'm impressed!

dusted 2y ago

For smaller games, there's some charm in not making a game engine, and not using one either, but just writing the game, sure this falls apart easily, if you find yourself needing something you're not able/willing to make from scratch, but a lot of very entertaining stuff can be made by just programming the game rather than trying to create an elegant api for your engine, or trying to learn and wrangle an exisiting engine into submission.

pmontra 2y ago

Kind of meta question: local engine = EngineFactory.new() I expect that a new instance of a factory class is a factory, not an engine. To get an engine, just create a new instance of an engine class. Examples of what I expect: local engine = Engine.new() or a more convoluted local factory = EngineFactory.new() local engine = factory:build_engine()

mococa 2y ago
Good catch. I will fix this, thank you!

tony-allan 2y ago

On a separate note the authors setup https://nullonerror.org/2024/03/20/my-2024-setup/ https://nullonerror.org/2024/03/20/my-2024-setup/