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.<p>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.<p>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.<p>So, just get moving with whatever excites you most and be willing to change course.
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.<p>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.<p>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.<p>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.<p>For anyone interested:
<a href="https://github.com/zinc-framework">https://github.com/zinc-framework</a>
Am I the only one who thinks the word "engine" is overused?<p>I've always assumed that "make a game, or make an engine" meant: if you decide to <i>not</i> use an engine when making your game, don't abstract it and <i>also</i> make an engine.<p>In other words, don't overengineer your game and build a generic engine when you don't need to.<p>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?
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.
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.<p>1. <a href="https://www.raylib.com/" rel="nofollow">https://www.raylib.com/</a>
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.
Very cool to see someone actually making a game in their hobby engine!<p>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?
To anyone thinking about writing a game engine.<p>I've been cranking on a 2D engine for over 4 years and have put thousands of hours of work into it.<p>My summary:<p>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.<p>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.<p>But finally the real work is not the engine but the tooling and the editor around the engine.<p>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.<p>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.<p>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!<p>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 <i>game</i> can then combine to create bigger constructs.<p>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.<p>-----<p><a href="https://github.com/ensisoft/detonator">https://github.com/ensisoft/detonator</a>
Kind of meta question:<p><pre><code> local engine = EngineFactory.new()
</code></pre>
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.<p>Examples of what I expect:<p><pre><code> local engine = Engine.new()
</code></pre>
or a more convoluted<p><pre><code> local factory = EngineFactory.new()
local engine = factory:build_engine()</code></pre>
On a separate note the authors setup
<a href="https://nullonerror.org/2024/03/20/my-2024-setup/" rel="nofollow">https://nullonerror.org/2024/03/20/my-2024-setup/</a>
Good for you, friend.<p>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.<p>I make stuff with wood. I don’t use power tools. I use hand tools. Because I like doing it that way.<p>Hope your kid has fun playing the game!
For anyone looking to write their own engine, I wrote a tutorial! You just need the tutorial and a couple of years :)<p><a href="https://nik-os.com/agl/00_intro.html" rel="nofollow">https://nik-os.com/agl/00_intro.html</a>
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.