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.
This gets at something I’ve thought about a lot as a software dev.
Making a game engine is a very concrete task, in that you can map out the steps and many of them are well-defined.
On the other hand “make a good game” kinda isn’t. Which I think is a big reason why coders gravitate towards the “start making an engine” route and then fall down it :)
The developers I admire and look up to a lot are the artists that fell into programming. I think they’re the best when it comes to being a successful lone / indie dev for games. Everyone notices art, but you don’t notice programming unless it goes wrong or you know the tech behind what you’re looking at.
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!
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.
I know this will get downvoted. I fully agree that if you want to make a game-engine then make one. It's fun! On the other hand, if you want to make a game, use an existing engine.
Analogies: I want to write a novel so I'll first build a typewriter. I want to film a movie so I'll first build a camera and digital editing software. I want to cook food so I'll first build a stove, pots, pans, and knives.
In all those other examples it hopefully clear, you just buy the tools you need and then make the thing the tools allow you to make. At this point, the same is true in games.
If you like making a game engine than make one. Just like if you like making knives or cameras then make them. But, making a knife is not cooking, making a camera is not making a movie, and making a game-engine is not making a game.
I also want to add, making a game-engine is easy compared to making a game. Why? Because all the things to you need are well known. You need a 2d renderer (UI), a 3d renderer (assuming you need 3d), image loaders, model loaders, sound players, music players, keyboard input, joypad input, entity systems. Etc. You build them and it seems like you're making progress and if your goal is to make a game-engine, then you are making progress. But, if your goal is to make game, you're mostly likely fooling yourself that you're making progress. Again, back to the analogies, if you're making a knife, you aren't making progress on cooking, your making progress on making a knife. If your making a camera, you aren't making progress on making a movie, you're making progress on making a camera.
What makes making a game harder than a game-engine is the list things to do for a game is unknown.
> 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.
I intuitively want to agree, but on the other hand I've also seen many, many hobby/indie/etc projects deadlock when they switched engines. Or even engine versions (Unreal 4 -> 5).
Probably because most of their logic is locked in "no code" systems, such as Unreal's blueprint or as Unity component data.
A well- and hand-written game is easily portable, see the original Doom, where separation between core logic and side effects, such as drawing in a screen, is clear. Actually, this is a good architectural model for all types of software.
Granted, but I don't think there are many people / teams who are capable of writing their own engine and then fail to port a few thousand lines of game logic. So I stand by my advice that if you decide later to write your own engine, porting the logic will not be the difficult part.
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.
> but when you create your own engine you are _fiercely_ aware of _everything_ it can and can't do
The problem is that if you start gamedev by making engines, then you aren't aware of what you need to do.
To give an example, if you make font rendering and looks blurry/pixelated, what now? Oh, and a simple 2D game takes 8 seconds to load, wonder why?
Meanwhile, if you have ever made a Unity game, chances are you already know the keywords "SDF" and "Texture compression", because you tore down an already big engine for optimizing your game and accidentally learned about what features a game needs.
What now is you have a fantastic opportunity to learn some topics in depth. Using Unity is also no guarantee that you'll come across those terms. And even if you do, if the Unity solution is to check the correct boxes you're exactly better off from a knowledge point of view.
I'm not advocating for not using Unity, but I am advocating for learning, increasing the depth of your understanding, and just a general approach of curiosity and problem solving.
"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."
Yeah the really compelling thing to me is the knowledge building. For example what I do with my own project is that I take a look at some demo or example, let's say in Gamemaker or GDevelop and I ask myself a few questions:
a) how is the sausage made?
b) can I make the sausage and what are my ingredients?
c) if I can't make the sausage yet, what do I need in order to make the sausage?
For me this has been really the best way to build rather "deep" knowledge in this domain, as in knowing how something works under the hood (or how I think it works or at least how my version of it works) vs. knowing how to use it in Gamemaker / GDevelop.
Ps. your github could use some screenshots I think
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.
People like designing and making games, so they design and make games… Making the engine (or underlying framework, whatever) is just not necessary for that goal.
There are relatively few game designs (especially with indie scope!) where a custom engine is truly necessary.
For the tinker/hacker types, there are plenty of things to do at a “lower level” within the engine itself (note: I don’t necessarily mean modifying the source code). There are all kinds of different ways to structure things within the confines of the engine, and lots of other ways of building frameworks and GUI tools within the engine too.
I pretty wholeheartedly disagree with this entire sentiment. For some people making a game engine isn't a monumental task, but implying that it's easy seems like an out-of-touch sentiment. There are many people who love making games but who aren't software devs that are enabled to make whatever they dream up via by the plug and play nature of game engines.
Have you ever tried to “make your own game engine” such that you can opine on this from a place of experience?
General-purpose game engines like Unity and Godot are “plug-and-play” for only a small percentage of your game's development cycle—at some point, unless you're making an extremely trivial game, you're going to end up “fighting the engine” to make it do the thing you want it to do at some point or another—typically much more than once. If you weren't relying on someone else's underlying game engine substrate to build your game upon, then you would never encounter something like this. It would be entirely upon you to restructure your own underlying game engine substrate that you've built in order to build your game upon. You would know what each part of the machinery is doing, because you built it—you wouldn't have to guess and check and dive deep into documentation and forum threads and Discord channels just to try to figure out the optimal way to beat the engine into submission to do the thing you're trying to make it do.
Have you seen the Raylib examples[0], such as the “2D platformer camera” example [1] (playable from the examples webpage)? It's really not a lot of code at all to get a basic playable game going—then from there, you just make more structs, store struct instances in arrays, and loop through the arrays to do 99% of the things you want a “game engine” to do that aren't covered by Raylib library functions.
If you made a 2D platformer by starting from that example instead of using something like Unity or Godot, and do as I said above and wrap all Raylib library function calls in your own functions, then, in the absolute worst case, tomorrow you wake up and find out that Raylib has, for some reason, gone all “Our Machinery”[2] and deleted its public source repositories and informed you that you're legally obligated to delete all Raylib code on your machine. Not a problem—just switch to SDL or SFML or bgfx (for just the graphics) or something similar, spend a couple hours replacing the library function calls in your code, and you're good to go! You maintain complete ownership over the vast bulk of your game's code, because you wrote it yourself, except for a few library calls which can be easily replaced with something else. This is a much better situation to be in, compared to e.g. the Unity fiasco of last year!
> There are many people who love making games but who aren't software devs
This idea still baffles me—why do people try to make video games while abstaining from learning anything at all about software development? Like there's nothing wrong with using higher-level tools as a means of learning the very basics of the craft—that's how I started out, too. But wanting to learn a high-level tool and then stopping there and learning nothing more is like wanting to be an artist but never learning any art fundamentals and using an AI generator instead.[3] Video game development as a whole is extremely difficult, and a craft that should either be taken remotely seriously (especially if you wish to self-describe as a “game developer”!!), or taken extremely casually. If you want to take it extremely casually, then by all means continue to refrain from engaging with even baseline software development knowledge and principles. But if you want to take it seriously, because, for example, you wish to sell the software you've made to other people so they can run it on their computers, then really, making a “game engine” is the least of your concerns as a game developer. Actually figuring out the game's design is much more difficult and time-consuming!
[3] Surely we all agree that someone whose idea of “creating art” is “learning how to best write a prompt for an AI art generator”, self-describing as an “artist”, weakens the term and is offensive to those who put untold amounts of time and effort into truly learning their craft—why should game development be any different?
At night I don't want to slog away implementing Foo and extending Bar
Unity is already a lot of programming to do any simple game mechanic, and you still have animation, modeling, art, lighting, shaders, sound...
I can't wait for AI to get to a point where I can tell it to "get look and feel from X game, mechanics from Y MOBA, multiplayer server" and get code good enough for an MVP
Games are for playing, code is an unfortunate side effect
You seem to be very intent on insisting that anyone can make a game engine (which I mostly agree with). But, it’s not easy, even when you use a pre-existing framework like Raylib. I’ve used frameworks like Monogame, I’ve used bare metal C++ and OpenGL, I’ve used the HTML canvas and JavaScript, I’ve built physics engines and used physics engines like Box2D or Havok. What I’m trying to say is I’ve done a lot of game engine-y stuff at various levels of the stack.
I’ve _also_ used Godot, Unity and Unreal. There’s a tremendous difference. I just started learning Godot a week ago and I already have the core game loop practically done in a new RPG. Sure I could’ve done the same thing using C++ and OpenGL (or Raylib or something), but I would be missing out on a lot of useful things that _just work_. Godot’s BBCode text labels are amazing and give my dialogue boxes a whole bunch of character out of the box. The tilemap editor allows me to just build my levels without having to build an editor first. The lighting system can add a ton of visual polish with very little effort on my part.
I’ve also dabbled in VR games with Unreal. And I’ve tried making some simple 3D games in Unity. Is this all possible without those engines? Yea. Would I have been able to experiment with the kinds of tech I got to play with if I made it all myself from scratch? I doubt it (not because I couldn’t do it, I just don’t have the time).
Another thing to consider is porting your game to different platforms! There’s a whole lot of variability in what kind of support you’ll get for that with something you made yourself or a framework like Raylib.
Anyways, from someone who has experienced both sides of the coin, you’ll end up fighting with the engine either way ;) There’s nothing wrong with using a general purpose engine.
Would you not say that learning how one could possibly make a game without using someone else's engine that does everything for you made you a better game developer, even if you end up choosing to use one?
That’s completely besides the point. I agree that working on an engine can be very fulfilling and round you out as a developer. But it’s not easy and I wouldn’t recommend that somebody who just wants to make a game go down that path. I’m pretty sure some of my favorite games like Hollow Knight would have never been made if they decided to just build the engine as well.
What is it specifically about Hollow Knight that makes you think it never would've been made without using someone else's engine? I didn't get too far into it myself but in terms of gameplay systems it seemed like a very standard 2D metroidvania platformer, except with a fantastic visual style.
Compare and contrast Salt & Sanctuary, which was uses FNA (which is a library, not an engine).
The idea that people who use game engines are at all equivalent to AI art prompters is ridiculous. What you’re doing is being like a painter who says “real painters mix their own pigments”. It’s unnecessary gatekeeping.
Absolutely agree! It's totally doable, but it does require some desire/ability to dig under the hood little.
I think a lot of people conflate the game engine with a game editor, and don't realise how simple an engine can be if it only contains the features needed for one game.
I've shipped several games with my home made engine, and it was the best technical decision I ever made! No more relying on someone else to fix bugs!
The editor is part of it but I think the complete lack of where to even begin structuring one's game code in absence of some kind of formalized scene graph is a huge part of it as well. Scene graph editors make seeing “what exists in the game world right now” very visually apparent and easy to understand: “well, there's this root Node, and within that there's these different Nodes, and some of them have child Nodes which represent…” and so on and so forth. I recently replied to someone on X [0] who was starting from the Raylib 2D platformer example and asked, earnestly, “so I have this constant array of five rectangles representing platforms… how do I go from this to ‘defining my game's world’”?
It's just data. In its most basic form, a game world can be represented as just arrays of instances of structs, and then you loop over those arrays and call a function on each element to simulate the “entity” that struct instance represents, and then again to render it onto the screen. Sure, you eventually might want to do something more complex than that if the need arises, but most people would be surprised at just how far you can go doing only the simplest possible thing.
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.
Literally that what I'm pursuing rn, I want to make my first (real) 3d game, I'm very aware of the loophole that most self-made engine game developers falls into but I genuinely found no 3d engine that suits my criteria:
* Be resources efficient (memory and cpu usage)
* Has primary 3D support
* stable
* Supports old devices (ideally embedded systems too)
* And of course be FOSS
I'm focusing on mobile, as you know mobile devices are very sensible to heating so the 1st option is a must, Godot isn't resource efficient, it heats very easily when I play one of the sample games. Regarding the second option, whilst Godot still supports gles2(which is the most widely supported api yet across old devices) it's further being pushed as second-citizent over Vulkan and looking through github no other engine checks my boxes...
If someone could direct me to an engine that checks all the boxes above I would happily try it out.
It's definitely possible to do it - for me the key is to write the game and the engine together, and only implement the bare features you need. For the first game at least, the engine and the game are essentially the same thing. Also, forget about wiring an editor, just add debug functionality to the game.
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.
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.
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.
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).
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.
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?
> 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.
“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.
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.
I often hear the advice to "make games, not game engines", and it's refreshing to hear it from someone who is actually working on an engine themselves, because usually when I hear this advice it's from devs who use Unity/Godot/Unreal, and the implication I get is that if you're not using one of those engines, you're wasting your time and won't ever make a game.
But I'd say there's a middle ground between using an existing engine and making your own general-purpose engine from scratch. I've been making a 2D RTS using C++/SDL, and it's taken me longer to write it this way than if I had used an existing engine, but in only a few months I've reached the point where I have a prototype and have had multiple playtests and am iterating the prototype based on feedback from those playtests.
So, while the advice "make games, not game engines" is still definitely true, it doesn't mean that if you code "from scratch" that your game will necessarily be a long 4-year engine project (unless you want it to be!). The trick is to keep the code specific to the game you're working on and to avoid the urge to abstract everything / make everything general-purpose.
I want to make sure you understand that games as art genre and old resource limited and low level programs are far away from each other now. And moving in different directions at light speed. Unless one builds something that should be donated to a museum on release one does not need more of C++/SDL.
I say that as someone who keeps working as mostly C++ contributor into internal game engines for various projects.
I would want people to look forward and make works of art that expand what we thought was possible more instead of 'learning low level programming'.
Yep this is of course one possible way too. Make a game from scratch but don't make an engine.
I personally I'm not capable of executing this strategy because my mind is always thinking in terms of abstractions and how to make things so re-usable in another context/project when the time comes. For better or worse this means that for me any "game from scratch" project will immediately turn into "engine + game from scratch" project :)
For me, a great middle ground is building an engine similar to fantasy consoles (PICO-8, TIC-80, etc.)
This type of project is small enough to plan all the elements before you start (which helps to stick to the design and therefore to avoid feature creep). Yet, it is still complex enough to provide entertainment and challenge.
This approach also has the advantage – at least it is an advantage in the case of side projects – that you can see the results of your work quite quickly.
I'm working on such a project myself, and it is a great experience. Although to tell the truth, it is more of a "game creation kit" than an engine.
This is exactly why I ended up going for Godot with my own hobby game. I have made a lot of progress on a custom game engine in the past without actually having a game to make in mind. It always gets to the point where you have to start making decisions about the tooling, and that becomes your main focus.
No disrespect or put downs of anyone trying to do their own thing, but Godot is a really great engine and is open source. It's kind of miracle that we live in a world where there is a viable open source engine for commercial grade 2d games and the whole thing is MIT licensed.
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.
"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."
Yes I agree, writing a specific functionality in the engine does allow for more optimal performance but the tradeoff is that it's more brittle and more complicated to write and maintain.
My personal approach has been to do the first principles and avoid writing use-case specific features in the engine as much as possible but provide more fundamental functionality that the game then combines to create the desired effect.
That being said I've still had to do some concessions and move stuff like simple constant velocity game object integration to the engine side simply because the perf difference between native code doing that vs Lua code are just too massive.
A question then, I have run some game servers in my time that had quite advanced console options and scripts to run, in Lua, which I then saw as maybe the most common language in this area. But I wondered where and why Lua which is its own full language was kept to a certain part of the game and running instance, and where the other runtime and the games main language differed. How is that division of responsibility separated or chosen I guess?
There's no single answer to this, it all depends on the game, the engine and the team(s) executing the engine and game.
Some typical ways to divide this though is
Some org has "engine" team and "game" team. Engine team implements features in the engine itself and game team implements game specific features using the embedded scripting language.
Engine features are game agnostic and game features are specific to games and are scripted / built-on top of the engine features.
But sometimes things get muddled as general purpose engines are used in games that require specific features in the engine itself. Typically the decision is then made by a) what kind of feature and how does it fit in the architecture of the engine b) what are the performance requirements c) who is willing to do the work and maintain it
I want to write a slot machine “game” for a custom slot machine I’ve built using a piece of MDF, a 32” LCD, and a Linux single board computer.
I haven’t found much information on how to write a game in this style with existing engines. Any advice or resources you would point a noob too? I am a software engineer but not a game programmer.
It doesn’t have to be so good as a real slot machine (regulations and such) but I do want to follow the rules as best I can. I may not use a real hardware RNG.
Maybe re-assess if a game engine is needed for your use case? A slot machine doesn't really need a whole ass game engine, you could do it with pretty much any graphics library.
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.
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)?
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?
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.
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.
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.
Very cool - nice tutorial!
I've released a few games with my home made engine (most recently 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.
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.
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.
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!
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.
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.
This gets at something I’ve thought about a lot as a software dev.
Making a game engine is a very concrete task, in that you can map out the steps and many of them are well-defined.
On the other hand “make a good game” kinda isn’t. Which I think is a big reason why coders gravitate towards the “start making an engine” route and then fall down it :)
The developers I admire and look up to a lot are the artists that fell into programming. I think they’re the best when it comes to being a successful lone / indie dev for games. Everyone notices art, but you don’t notice programming unless it goes wrong or you know the tech behind what you’re looking at.
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!
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.
Yeah I’m just saying in general. I probably shouldn’t have replied to anyone in particular—just jumping in the conversation. =)
I know this will get downvoted. I fully agree that if you want to make a game-engine then make one. It's fun! On the other hand, if you want to make a game, use an existing engine.
Analogies: I want to write a novel so I'll first build a typewriter. I want to film a movie so I'll first build a camera and digital editing software. I want to cook food so I'll first build a stove, pots, pans, and knives.
In all those other examples it hopefully clear, you just buy the tools you need and then make the thing the tools allow you to make. At this point, the same is true in games.
If you like making a game engine than make one. Just like if you like making knives or cameras then make them. But, making a knife is not cooking, making a camera is not making a movie, and making a game-engine is not making a game.
I also want to add, making a game-engine is easy compared to making a game. Why? Because all the things to you need are well known. You need a 2d renderer (UI), a 3d renderer (assuming you need 3d), image loaders, model loaders, sound players, music players, keyboard input, joypad input, entity systems. Etc. You build them and it seems like you're making progress and if your goal is to make a game-engine, then you are making progress. But, if your goal is to make game, you're mostly likely fooling yourself that you're making progress. Again, back to the analogies, if you're making a knife, you aren't making progress on cooking, your making progress on making a knife. If your making a camera, you aren't making progress on making a movie, you're making progress on making a camera.
What makes making a game harder than a game-engine is the list things to do for a game is unknown.
> 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.
I intuitively want to agree, but on the other hand I've also seen many, many hobby/indie/etc projects deadlock when they switched engines. Or even engine versions (Unreal 4 -> 5).
Probably because most of their logic is locked in "no code" systems, such as Unreal's blueprint or as Unity component data.
A well- and hand-written game is easily portable, see the original Doom, where separation between core logic and side effects, such as drawing in a screen, is clear. Actually, this is a good architectural model for all types of software.
Granted, but I don't think there are many people / teams who are capable of writing their own engine and then fail to port a few thousand lines of game logic. So I stand by my advice that if you decide later to write your own engine, porting the logic will not be the difficult part.
I find that this is the best advice for life, not just making your own games. Do what you're most excited to do :)
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
> but when you create your own engine you are _fiercely_ aware of _everything_ it can and can't do
The problem is that if you start gamedev by making engines, then you aren't aware of what you need to do.
To give an example, if you make font rendering and looks blurry/pixelated, what now? Oh, and a simple 2D game takes 8 seconds to load, wonder why?
Meanwhile, if you have ever made a Unity game, chances are you already know the keywords "SDF" and "Texture compression", because you tore down an already big engine for optimizing your game and accidentally learned about what features a game needs.
> What now? > wonder why?
What now is you have a fantastic opportunity to learn some topics in depth. Using Unity is also no guarantee that you'll come across those terms. And even if you do, if the Unity solution is to check the correct boxes you're exactly better off from a knowledge point of view.
I'm not advocating for not using Unity, but I am advocating for learning, increasing the depth of your understanding, and just a general approach of curiosity and problem solving.
This was my experience.
I dove into writing a niche game engine and stumbled over every hurdle that modern game engines solve.
Been learning Godot lately and going back to writing an engine I'm confident I could trivally solve a lot of those hurdles.
Additionally, if im trying to make a basic editor I can now see what is tenfold easier graphically (animations) and what I don't mind programming in.
"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."
Yeah the really compelling thing to me is the knowledge building. For example what I do with my own project is that I take a look at some demo or example, let's say in Gamemaker or GDevelop and I ask myself a few questions:
For me this has been really the best way to build rather "deep" knowledge in this domain, as in knowing how something works under the hood (or how I think it works or at least how my version of it works) vs. knowing how to use it in Gamemaker / GDevelop.Ps. your github could use some screenshots I think
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.
People like designing and making games, so they design and make games… Making the engine (or underlying framework, whatever) is just not necessary for that goal.
There are relatively few game designs (especially with indie scope!) where a custom engine is truly necessary.
For the tinker/hacker types, there are plenty of things to do at a “lower level” within the engine itself (note: I don’t necessarily mean modifying the source code). There are all kinds of different ways to structure things within the confines of the engine, and lots of other ways of building frameworks and GUI tools within the engine too.
I pretty wholeheartedly disagree with this entire sentiment. For some people making a game engine isn't a monumental task, but implying that it's easy seems like an out-of-touch sentiment. There are many people who love making games but who aren't software devs that are enabled to make whatever they dream up via by the plug and play nature of game engines.
I'm not a game dev, but I had a lot of fun making an ECS system by following ideas in an article I found (and which I have now annoyingly lost).
It's a very educational exercise that any dev would benefit from, game dev or not.
Have you ever tried to “make your own game engine” such that you can opine on this from a place of experience?
General-purpose game engines like Unity and Godot are “plug-and-play” for only a small percentage of your game's development cycle—at some point, unless you're making an extremely trivial game, you're going to end up “fighting the engine” to make it do the thing you want it to do at some point or another—typically much more than once. If you weren't relying on someone else's underlying game engine substrate to build your game upon, then you would never encounter something like this. It would be entirely upon you to restructure your own underlying game engine substrate that you've built in order to build your game upon. You would know what each part of the machinery is doing, because you built it—you wouldn't have to guess and check and dive deep into documentation and forum threads and Discord channels just to try to figure out the optimal way to beat the engine into submission to do the thing you're trying to make it do.
Have you seen the Raylib examples[0], such as the “2D platformer camera” example [1] (playable from the examples webpage)? It's really not a lot of code at all to get a basic playable game going—then from there, you just make more structs, store struct instances in arrays, and loop through the arrays to do 99% of the things you want a “game engine” to do that aren't covered by Raylib library functions.
If you made a 2D platformer by starting from that example instead of using something like Unity or Godot, and do as I said above and wrap all Raylib library function calls in your own functions, then, in the absolute worst case, tomorrow you wake up and find out that Raylib has, for some reason, gone all “Our Machinery”[2] and deleted its public source repositories and informed you that you're legally obligated to delete all Raylib code on your machine. Not a problem—just switch to SDL or SFML or bgfx (for just the graphics) or something similar, spend a couple hours replacing the library function calls in your code, and you're good to go! You maintain complete ownership over the vast bulk of your game's code, because you wrote it yourself, except for a few library calls which can be easily replaced with something else. This is a much better situation to be in, compared to e.g. the Unity fiasco of last year!
> There are many people who love making games but who aren't software devs
This idea still baffles me—why do people try to make video games while abstaining from learning anything at all about software development? Like there's nothing wrong with using higher-level tools as a means of learning the very basics of the craft—that's how I started out, too. But wanting to learn a high-level tool and then stopping there and learning nothing more is like wanting to be an artist but never learning any art fundamentals and using an AI generator instead.[3] Video game development as a whole is extremely difficult, and a craft that should either be taken remotely seriously (especially if you wish to self-describe as a “game developer”!!), or taken extremely casually. If you want to take it extremely casually, then by all means continue to refrain from engaging with even baseline software development knowledge and principles. But if you want to take it seriously, because, for example, you wish to sell the software you've made to other people so they can run it on their computers, then really, making a “game engine” is the least of your concerns as a game developer. Actually figuring out the game's design is much more difficult and time-consuming!
[0] https://www.raylib.com/examples.html
[1] https://github.com/raysan5/raylib/blob/master/examples/core/...
[2] https://old.reddit.com/r/gamedev/comments/wd4qoh/our_machine...
[3] Surely we all agree that someone whose idea of “creating art” is “learning how to best write a prompt for an AI art generator”, self-describing as an “artist”, weakens the term and is offensive to those who put untold amounts of time and effort into truly learning their craft—why should game development be any different?
I program daily
At night I don't want to slog away implementing Foo and extending Bar
Unity is already a lot of programming to do any simple game mechanic, and you still have animation, modeling, art, lighting, shaders, sound...
I can't wait for AI to get to a point where I can tell it to "get look and feel from X game, mechanics from Y MOBA, multiplayer server" and get code good enough for an MVP
Games are for playing, code is an unfortunate side effect
You seem to be very intent on insisting that anyone can make a game engine (which I mostly agree with). But, it’s not easy, even when you use a pre-existing framework like Raylib. I’ve used frameworks like Monogame, I’ve used bare metal C++ and OpenGL, I’ve used the HTML canvas and JavaScript, I’ve built physics engines and used physics engines like Box2D or Havok. What I’m trying to say is I’ve done a lot of game engine-y stuff at various levels of the stack.
I’ve _also_ used Godot, Unity and Unreal. There’s a tremendous difference. I just started learning Godot a week ago and I already have the core game loop practically done in a new RPG. Sure I could’ve done the same thing using C++ and OpenGL (or Raylib or something), but I would be missing out on a lot of useful things that _just work_. Godot’s BBCode text labels are amazing and give my dialogue boxes a whole bunch of character out of the box. The tilemap editor allows me to just build my levels without having to build an editor first. The lighting system can add a ton of visual polish with very little effort on my part.
I’ve also dabbled in VR games with Unreal. And I’ve tried making some simple 3D games in Unity. Is this all possible without those engines? Yea. Would I have been able to experiment with the kinds of tech I got to play with if I made it all myself from scratch? I doubt it (not because I couldn’t do it, I just don’t have the time).
Another thing to consider is porting your game to different platforms! There’s a whole lot of variability in what kind of support you’ll get for that with something you made yourself or a framework like Raylib.
Anyways, from someone who has experienced both sides of the coin, you’ll end up fighting with the engine either way ;) There’s nothing wrong with using a general purpose engine.
Would you not say that learning how one could possibly make a game without using someone else's engine that does everything for you made you a better game developer, even if you end up choosing to use one?
That’s completely besides the point. I agree that working on an engine can be very fulfilling and round you out as a developer. But it’s not easy and I wouldn’t recommend that somebody who just wants to make a game go down that path. I’m pretty sure some of my favorite games like Hollow Knight would have never been made if they decided to just build the engine as well.
What is it specifically about Hollow Knight that makes you think it never would've been made without using someone else's engine? I didn't get too far into it myself but in terms of gameplay systems it seemed like a very standard 2D metroidvania platformer, except with a fantastic visual style.
Compare and contrast Salt & Sanctuary, which was uses FNA (which is a library, not an engine).
The idea that people who use game engines are at all equivalent to AI art prompters is ridiculous. What you’re doing is being like a painter who says “real painters mix their own pigments”. It’s unnecessary gatekeeping.
Absolutely agree! It's totally doable, but it does require some desire/ability to dig under the hood little. I think a lot of people conflate the game engine with a game editor, and don't realise how simple an engine can be if it only contains the features needed for one game. I've shipped several games with my home made engine, and it was the best technical decision I ever made! No more relying on someone else to fix bugs!
The editor is part of it but I think the complete lack of where to even begin structuring one's game code in absence of some kind of formalized scene graph is a huge part of it as well. Scene graph editors make seeing “what exists in the game world right now” very visually apparent and easy to understand: “well, there's this root Node, and within that there's these different Nodes, and some of them have child Nodes which represent…” and so on and so forth. I recently replied to someone on X [0] who was starting from the Raylib 2D platformer example and asked, earnestly, “so I have this constant array of five rectangles representing platforms… how do I go from this to ‘defining my game's world’”?
It's just data. In its most basic form, a game world can be represented as just arrays of instances of structs, and then you loop over those arrays and call a function on each element to simulate the “entity” that struct instance represents, and then again to render it onto the screen. Sure, you eventually might want to do something more complex than that if the need arises, but most people would be surprised at just how far you can go doing only the simplest possible thing.
[0] https://x.com/rezich/status/1841889141505851680
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.
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.
Literally that what I'm pursuing rn, I want to make my first (real) 3d game, I'm very aware of the loophole that most self-made engine game developers falls into but I genuinely found no 3d engine that suits my criteria:
* Be resources efficient (memory and cpu usage)
* Has primary 3D support
* stable
* Supports old devices (ideally embedded systems too)
* And of course be FOSS
I'm focusing on mobile, as you know mobile devices are very sensible to heating so the 1st option is a must, Godot isn't resource efficient, it heats very easily when I play one of the sample games. Regarding the second option, whilst Godot still supports gles2(which is the most widely supported api yet across old devices) it's further being pushed as second-citizent over Vulkan and looking through github no other engine checks my boxes...
If someone could direct me to an engine that checks all the boxes above I would happily try it out.
Bevy?
The only thing more impressive than writing a game engine is actually using it
It's definitely possible to do it - for me the key is to write the game and the engine together, and only implement the bare features you need. For the first game at least, the engine and the game are essentially the same thing. Also, forget about wiring an editor, just add debug functionality to the game.
That is truly a curse. I just want to make an engine so I can say I did everything from scratch
I hope by 'everything' that includes the text editor and compiler you'll used in the development process ;)
I think a lot of them want to be like Carmack. :)
Or Commander Keen
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.
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
Game programming patterns is also an excellent book. I referenced both of these when writing my engine.
This book is really good; I’ve already gotten a lot of ideas from it.
Love that book, great resource for lookup up all kinds of programming topics, whether game related or not
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/
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).
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.
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?
> 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.
“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.
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
I often hear the advice to "make games, not game engines", and it's refreshing to hear it from someone who is actually working on an engine themselves, because usually when I hear this advice it's from devs who use Unity/Godot/Unreal, and the implication I get is that if you're not using one of those engines, you're wasting your time and won't ever make a game.
But I'd say there's a middle ground between using an existing engine and making your own general-purpose engine from scratch. I've been making a 2D RTS using C++/SDL, and it's taken me longer to write it this way than if I had used an existing engine, but in only a few months I've reached the point where I have a prototype and have had multiple playtests and am iterating the prototype based on feedback from those playtests.
So, while the advice "make games, not game engines" is still definitely true, it doesn't mean that if you code "from scratch" that your game will necessarily be a long 4-year engine project (unless you want it to be!). The trick is to keep the code specific to the game you're working on and to avoid the urge to abstract everything / make everything general-purpose.
I want to make sure you understand that games as art genre and old resource limited and low level programs are far away from each other now. And moving in different directions at light speed. Unless one builds something that should be donated to a museum on release one does not need more of C++/SDL.
I say that as someone who keeps working as mostly C++ contributor into internal game engines for various projects.
I would want people to look forward and make works of art that expand what we thought was possible more instead of 'learning low level programming'.
Yep this is of course one possible way too. Make a game from scratch but don't make an engine.
I personally I'm not capable of executing this strategy because my mind is always thinking in terms of abstractions and how to make things so re-usable in another context/project when the time comes. For better or worse this means that for me any "game from scratch" project will immediately turn into "engine + game from scratch" project :)
I suspect it also helps if your engine can ingest content made in existing editors, or uses off-the-shelf libraries for e.g. the nitty gritty.
For me, a great middle ground is building an engine similar to fantasy consoles (PICO-8, TIC-80, etc.)
This type of project is small enough to plan all the elements before you start (which helps to stick to the design and therefore to avoid feature creep). Yet, it is still complex enough to provide entertainment and challenge.
This approach also has the advantage – at least it is an advantage in the case of side projects – that you can see the results of your work quite quickly.
I'm working on such a project myself, and it is a great experience. Although to tell the truth, it is more of a "game creation kit" than an engine.
This is exactly why I ended up going for Godot with my own hobby game. I have made a lot of progress on a custom game engine in the past without actually having a game to make in mind. It always gets to the point where you have to start making decisions about the tooling, and that becomes your main focus.
No disrespect or put downs of anyone trying to do their own thing, but Godot is a really great engine and is open source. It's kind of miracle that we live in a world where there is a viable open source engine for commercial grade 2d games and the whole thing is MIT licensed.
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.
"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."
Yes I agree, writing a specific functionality in the engine does allow for more optimal performance but the tradeoff is that it's more brittle and more complicated to write and maintain.
My personal approach has been to do the first principles and avoid writing use-case specific features in the engine as much as possible but provide more fundamental functionality that the game then combines to create the desired effect.
That being said I've still had to do some concessions and move stuff like simple constant velocity game object integration to the engine side simply because the perf difference between native code doing that vs Lua code are just too massive.
A question then, I have run some game servers in my time that had quite advanced console options and scripts to run, in Lua, which I then saw as maybe the most common language in this area. But I wondered where and why Lua which is its own full language was kept to a certain part of the game and running instance, and where the other runtime and the games main language differed. How is that division of responsibility separated or chosen I guess?
There's no single answer to this, it all depends on the game, the engine and the team(s) executing the engine and game.
Some typical ways to divide this though is
Some org has "engine" team and "game" team. Engine team implements features in the engine itself and game team implements game specific features using the embedded scripting language.
Engine features are game agnostic and game features are specific to games and are scripted / built-on top of the engine features.
But sometimes things get muddled as general purpose engines are used in games that require specific features in the engine itself. Typically the decision is then made by a) what kind of feature and how does it fit in the architecture of the engine b) what are the performance requirements c) who is willing to do the work and maintain it
I want to write a slot machine “game” for a custom slot machine I’ve built using a piece of MDF, a 32” LCD, and a Linux single board computer.
I haven’t found much information on how to write a game in this style with existing engines. Any advice or resources you would point a noob too? I am a software engineer but not a game programmer.
It doesn’t have to be so good as a real slot machine (regulations and such) but I do want to follow the rules as best I can. I may not use a real hardware RNG.
Maybe re-assess if a game engine is needed for your use case? A slot machine doesn't really need a whole ass game engine, you could do it with pretty much any graphics library.
Isn’t this what Godot was originally for?
because code is like pasta
In more ways than one
You got it!
Very cool! Great blog too (add RSS!). You officially have new reader.
Ah, a fellow RSS reader! Thank you!
I also have kids and have toyed with the notion of making games with/for them. Thank you for the inspiration!
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.
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.
FYI, I recently posted about a 2d game I made, here: 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.
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.
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)?
Yeah, the game I linked to is in Rust/wasm, running solely in browsers :)
The interesting part of the collision detection code is here: https://github.com/dakom/not-a-game/blob/main/src/collision/...
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?
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.
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.
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!
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
Very cool - nice tutorial! I've released a few games with my home made engine (most recently 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.
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?
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.
"anyone can draw"
I wish
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.
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!
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.
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.
Heck, I'm a gamedev right now and I completely understand the not going back bit