Why Don't You Make Your OWN Game Engine?

I've been asking around, trying to find out why people avoid game engine development. There are a lot of misconceptions and concerns that can be easily addressed. So why don't you give it a go?

Content
0:00 Introduction
1:30 Getting Into The Right Mindset
2:53 Time It Takes To Develop
4:12 Technical Knowhow Needed
5:43 Comparisons Against Pre-established Engines

[Cydeamon]

The right mindset to develop your own engine is that you're not developing an ENGINE, you're developing a GAME. Your codebase grows every time you code, you have full control over it, you make the data available the way you like (for me this is the number 1 reason), you can fix something in the moment instead of waiting for someone else to do it. You can develop your own tools, such as a level editor, etc., of course, and that will benefit you, but it's not necessary from the start. You don't have to try to create a set of tools for everything. It's a gradual process until you realize what exactly do you need from the tools.

BTW if no one will try to develop an engine, who will maintain existing ones?

[lummwastaken]

There's a guy in the corner of my room brandishing a lead pipe at me 24/7 and whenever I try to make a game engine he starts raising it, so I've decided it's not really worth the effort.

[bcdev]

Time and Understanding. If you don't have much time to make a game, then you want to end up with an already made Game Engine. If time does not matter, then you can start, how you want.

As time in that Game Development progresses, you need to understand a lot of things. Graphics Rendering with OpenGL and GLFW is straightforward. Follow a few tutorials, code along (do not Copy-Paste because you won't understand them) and you'll get the basics. In case that you progress with 3D for example, then you need to understand more than just graphics. If you want something related to FPS Parkour Game, then you need to handle a lot of things, such as physics and much more. Levels can be a piece of cake, but the understanding of the concepts that you want to make can be hard with custom Engines. Unreal and Unity provide physics, which makes things easier. I don't know much about Physics, but I know that it is hard to understand.

I ended up choosing to go with a custom Game Engine in Java (because I like cross-platform and Linux) anyway because time does not matter and I want my own game to be playable on any platform. And yes, I could have chosen C or C++, but since I don't own a MacBook, I guess that I have to go with Linux and Windows CXX Compilers.

[RobLang]

Time. If you're making a game engine then you're hobby is making a game engine. If you want to make a game then use an existing engine. Choose the level of abstraction you want to work at and do that.

Your argument would also work lower level. What's stopping you making your own language and compiler? Why use C/C++ when you can design your own language and compiler to assembler?

It's not that hard. You understand C and memory control but C has pointers. You can make a.memory safe version. You understand enough about memory management, it's no different in Assembler. So why not? You can always jump back to higher level languages. So why not? Time.

[GingerNingerish]

At the moment for me, time is a factor, but I just have projects I already want to make in motion plus I like switching between design, programing, music and art at differnt stages to learn. Building an engine for me will be when I want to move in to a more technical realm and a deep understanding of things and probably something I'll explore when I have more overall experince and some more time.

[lcppproductions]

I feel like something that is easy to miss about using general purpose engines is that you don't need to use every tool that it gives you. One of the benefits of using an existing engine like Unity is that you can be more selective about what you want to focus on because of the core features that work out of box. You don't need to use Unity's physics system if you want to learn more about how to implement physics from scratch. You can make custom camera scripts instead of using Cinemachine. If you're more interested in how rendering works, there are ways to write shaders without using shader graph (although idk about bypassing the render pipelines). I made scripts for navigation/pathfinding using A* once in lieu of Unity's navigation. There are even ways to write custom editor tools if you're into that.

Taken to the extreme, you could just take the game object/transform system, entity-component system, all of the convenient editor tools (hierarchy, inspector, scene/game view, etc.), and maybe the renderer, and write custom scripts for everything else. Handling all the editor tooling and file i/o for scenes from scratch, even if you're using something like ImGUI, is a pain (speaking from experience), so I can see why not everyone would want to invest that time.

Making a game engine, you can choose which features you want to add by scoping games accordingly, but you can likewise choose to be selective and exclude features that you wish to use from an existing engine if your game requires something different. In essence, you're building out your own "subengine" within the more general purpose engine that is tailored to the games that you want to make.

[elpresidente]

Making a game "engine" isn't that bad if you're focusing on making the engine under the game at hand instead of remaking Unity or Godot. For lots of games, it's surprisingly easy. You'll be surprised by how much of a game engine you don't actually use.

(I use Godot mostly though lol)

[_somerandomguyontheinternet__]

I have had a game engine concept/idea (how it stores data, how to make games in it etc.) for almost 2 years where my engine would be written in Zig (a relatively new and fast programming language). The thing is: every time I decide to start working on it, I can't really find the best entry point to make my engine (renderer, game object system, modular engine structure etc.), so I've always been stuck on the beginning.

After I watched your video, I realized I should start small (probably write the engine in Kotlin, use OpenGL instead of Vulkan) and then transfer my knowledge to the Zig codebase. This way I don't need to think about memory management and optimization and all the other stuff that distracts me, but I can focus on the actual engine a lot more.

Thanks for your great video. It brought me a step closer to creating my game engine. :)

[KablammoManYT]

The main thing that is stopping me is the lack of knowledge of making desktop apps with GUIs. I know how to make web apps using HTML/CSS/JS/NodeJS/p5.js and command line apps with Python, but thats it.

[alexanderzaugg]

The main pros I see for making your own engine are: 1. You own it and never have to pay an engine if your game takes off. 2. You have features that are tailored to developing your games. And 3. You learn more about how things are working at a lower level which will lead to better optimizations down the road.

Personally, at a hobbyist level. I have a hard time seeing the time investment being worth it for these things when you can get the same three pros using Godot. It's open source which means you can add your own features to the engine and it will never cost you anything. I feel like you'd be better off with the pre-built Godot feature set, and then modifying the engine as needed rather than building your own engine.

[RobertFletcherOBE]

Unity and Unreal add layers of abstraction which make them general purpose, that abstraction comes with its own cost in complexity. If your writing a simple game you can get far more done with less work with something like RayLib. I switched to RayLib recently and small 2D games are so much simpler to structure and understand.

[roberttalada]

If you’re just making a simple game, it can be worth the time to make your own engine because you’re developing a codebase that is YOURS that you can reuse on ANY project. That’s very valuable to you and those that hire you. (Just make sure you protect rights to code you bring with you and don’t let those people try to take ownership of said code.

[apresthus]

Im making a 3D "engine" from scratch for my simulation game. I put engine in quotation marks because its really more like the thinnest possible layer of tooling that I can write to make the game. I find it a ton of fun, and it is so insanely rewarding once you reach big milestones. The time misconception is a big one. Some people seem to think that if you make your own engine for a game that your game will take 10 years to finish. I mean I'm making a 3D engine from scratch (and that includes all the math so that I can understand and learn it better), and I anticipate that within 6 months from now I can pretty much block out my entire game and create all the core systems and scaffolding needed to make it. And because I have written every single internal API and line of code, I can work much faster in it than if I have to use a 3rd party engine and have to constantly refer to docs.

[BlackJar]

When I first started trying to make my own games I started making my own engine, partly because I didn't realize other options were available -- I made two drafts of an unoptimized 3D rendering engine that would be terrible for actual games. The I backed up and just made couple arcade style games, and a simple 2D engine almost by accident. Having said that, now I just want to get my games made, with most requiring 3D for the concept. At this point, I'd rather just save time by using Unity and Godot, especially for the for complex 3D ideas that actually do require a lot of things that would take a lot of time to develop and a lot of optimization to be practical.

[SnakeEngine]

I was clueless for a long time what good architecture is. But one day, I just saw an abstract view of an organism and lego blocks and it just clicked. The simple guidlene was just to make "reusable blocks of logic" and structuring it as an abstract organism: "organs talking to each other". By taking this simple guideline seriously, it made my code like 100x times better than the mess I was producing back then. Turns out, it can be sometimes pretty hard to get simple, but in no moment I am lost in the woods since I have a clear guide on what needs to be accomplished to make the code-architecture better.

I can only recommend to seriously apply this guideline to any feature or class you create. Ask questions like "Is this class or approach really reusable, or is it bound to conditions?", "Are those conditions really necessary/irreduceable and cannot be reduced?" Working on these questions can be hard, but also interesting and insightful (you will be surprised how much fluff can be reduced and thrown away you previously thought was necessary), and the process will ultimately lead you to a better architecture that can truly scale. Hope this advice can help someone else, too! ;)

[nathansimons]

The same reason I leverage any pre-existing it's just faster. If I had to write everything from scratch, I'd never get anything done. It's called standing on the shoulders of giants. If we threw re-use out the window, we'd all still be coding in machine code binary (no, not even assembly - that's reuse).

Yeah, sometimes pre-existing codebases suck. It's only when they impede my progress enough that I think "I could do better" do I consider something else. And there's enough options out there, I always look for some other codebase. Necessity is the mother of invention, and I've just not found it necessary to write my own.

[Roxor]

Here's one possibility to consider: retro system programming. Try making a DOS game and testing your builds in DOSBox. The software environment will be almost nonexistent, so you'll be calling the BIOS to set video modes and directly writing pixels to VRAM for graphics, bit-banging the PC Speaker for simple sound effects, and querying the keyboard controller for input. Would double as an opportunity to learn a bit of x86 assembly programming as well.

And you know what they say about limitations breeding creativity? Plenty of limitations in the computing environment of the dawn of PC gaming to play into. You could do an entire game in text-mode, using coloured characters and their backgrounds as pseudo-graphics, like Apogee and Epic started out with (Kroz and ZZT respectively). You could try and make something out of CGA's limited palettes of red/green/yellow and magenta/cyan/white with a user-selectable background colour (Apogee made at least three such games). If that's too much of an artistic challenge, then take a shot at EGA's 16-colour mode (way too many games to count). For sound, the PC Speaker is one step above the most basic possible sound output device, with its monophonic square wave output, yet countless games made good use of it (with a few abusing its enable-disable register to control it in the simplest possible way for noisy sample playback). Fancy some music? Well, there's the widely-supported OPL2 FM synthesis chip found on the Adlib card to play with. It pairs well with PC Speaker sound effects. Just try playing Doom with Adlib for the music and PC Speaker for the sound effects, or Cosmo's Cosmic Adventure (another Apogee title).

Oh, and if you decide you want to sell your DOS game, making it available for modern audiences is easy: just ship a pre-configured DOSBox installation, like many games on Steam and GOG already do.

[DKaldes]

Weirdly enough, I never really made a real game, but I have created a game engine. It's a simple one that runs in the Windows cmd, I developed it using C# without any external libraries. It can't do much, but it can display colored images and move them around

[lightspeedlife]

I've had a few concepts, mostly simulation & rpg mechanics, and some rendering, which I've wanted to play with for some time, but it probably take a lot longer for me to implement them in my own engine, rather than to use similar features of an existing engine, or implement them as addons, and time, right now, is my biggest constraint. I don't really have a lot of free time. I also have not done a whole lot of graphical work already, which would be an additional new paradigm to learn, on top of all of the engine stuff. Lastly, I think that I may not be so interested in making games, as I am in making tools, hence my interest in engine design, which has caused me to consider that I might want to start smaller, and just make an editor (of code, maps, graphics, etc.) for now, that could produce the resources used by another engine (possibly mine) in the future. If I develop tools that I like using, maybe I will be more likely to stick with whatever projects I work on in the future, since I won't be so consistently put off by slow, draconian vim and emacs.

[finesseandstyle]

Entirely depends on your goals. If your goal is learning about game dev and getting better at programming sure go for it. If your goal is creating a game within the fastest time possible, no.
I've been programming for like 10 years and I consider myself to be pretty competent at it. I just can't picture myself benefitting from reinventing the wheel.

Even if it's 1 year to create a full fledged engine comparable to Unreal or Godot, that 1 year with the same effort is enough to fully understand what it takes to create a game from scratch in those engines, even if you don't master it, and come up with lots of relatively complex prototypes or even finished work by then.
With that 1 year of making an engine you develop a couple very small scale games at best, realistically speaking?
Unless you genuinely enjoy coding and have a huge passion or you want to work on as an Game Engine Developer there is not much reason for it. I don't particularly enjoy coding for its own sake, I do it because it's a means to an end, either for a working product I have in mind or for money.

And even if you failed at either making a game with your own custom engine or with an existing one, at least with something like Unreal or Godot, you get out with marketable tools for future jobs.

Sure you get benefits like full ownership and control but from my perspective that is totally meaningless and prefer dealing with an engine's problems that might not even be that bad.

I can't think of many successful examples of games that were custom written within a reasonable time by solo devs or by very small teams: Stardew Valley (4 years), Starsector (13+ years) and Dwarf Fortress (16 years). Stardew Valley is the only outlier and the creator ConcernedApe himself said it's not worth going the custom engine route unless it's strictly necessary.