Building a game from scratch: my own engine, or Unity, Unreal, Godot?

So, I want to build a game from the ground up. Before writing a single line of code, there’s a big question to answer: do I build my own engine, or use one that already exists?

I’ve been reading, watching and asking a lot of questions (AI included), so here’s everything I’ve learned so far. If you’ve been down this road, I’d love to hear what you’d do in the comments.

What is a game engine, anyway?

A game engine is all the plumbing that sits underneath a game. When you play something, a lot is happening every frame:

• The game loop: read input, update the world, draw the frame, repeat 60+ times a second.
• Rendering: talking to the graphics card to draw sprites, models, lighting and effects.
• Input: keyboard, mouse, controllers, maybe touch.
• Audio: music, sound effects, 3D positional sound.
• Physics and collision: stopping you walking through walls, making things fall and bounce.
• Assets: loading textures, models, sounds, levels and fonts, and packing them for release.
• Scenes and entities: organising everything in the world (lots of engines use an entity component system).
• UI: menus, health bars, inventories, settings screens.
• Tools: a level editor, debugging overlays, profilers.
• Platform support: building for Windows, Linux, Mac, consoles or the web.
• Saving, networking, localisation: depending on the game.

A prebuilt engine gives you all of that on day one. Building your own means writing every piece yourself, or stitching together libraries that do some of it.

Option 1: build your own engine

Pros

• You learn an enormous amount. Graphics, memory, maths, performance: you understand what’s happening, not just which button to press.
• Total control. Nothing you don’t need, and nothing working in a way you don’t understand.
• No licence terms or fees. You decide everything.
• Small and fast. A custom engine built for one game can be very lean.
• Bragging rights. Let’s be honest, “I built my own engine” sounds cool.

Cons

• It takes a long time. Most of the work isn’t the game, it’s the plumbing and tools. Lots of solo projects never get past the engine stage.
• Tools are the hidden mountain. Rendering a cube is a weekend. A level editor, asset pipeline and debugging tools are months.
• Everything is your problem. Every crash, every platform quirk, every audio driver issue.
• Fewer tutorials and less help. With Unity or Godot, someone has already hit your bug. With your own engine, it’s just you.
• Shipping is harder. Exporting to other platforms, especially consoles, is a big job without an engine that already supports them.

Option 2: use a prebuilt engine

Pros

• You start making the game immediately. Movement, physics and lighting work out of the box.
• Editors and tools included. Level design, animation, particles, profiling.
• Huge communities. Tutorials, forums, videos and asset stores.
• Cross-platform builds often with one click (consoles usually need extra approval and tools).
• Proven. Thousands of shipped games have already found the rough edges.

Cons

• Learning the engine’s way of doing things. You learn the tool, not always the fundamentals underneath.
• Licence terms and business decisions you don’t control. Engines have changed their pricing and terms before, so it’s worth reading the current terms properly.
• Bloat. A tiny 2D game can carry a lot of engine it never uses.
• Fighting the engine. If your idea doesn’t fit how the engine wants to work, it can be painful.

The engines worth knowing about

Licence terms and prices change, so always check the official website before you commit.

If I build my own: which language?

You also have to choose how to talk to the graphics card: OpenGL (older but easier to learn), Vulkan (powerful but very verbose), DirectX 12 (Windows and Xbox), Metal (Apple) or WebGPU (the web, and growing). Libraries like SDL3, bgfx and sokol can hide some of those differences for you.

The middle ground

There’s a route between “write everything” and “use Unreal”: use a framework. MonoGame, raylib and SDL handle the low-level jobs (opening a window, drawing, input, sound) and leave the game architecture to you. You still learn how engines work, but you’re not writing a graphics driver wrapper before you’ve made your first character move.

Where vibe coding fits in

This whole site was vibe coded, so it’s a fair question: does AI change the answer?

• AI is great at boilerplate: setting up a game loop, loading files, writing shaders, explaining maths.
• Popular engines have more examples out there, so AI tends to give better answers for Unity, Godot or MonoGame than for a brand new custom engine.
• A custom engine grows fast, and the more code there is, the more you need to understand it yourself. AI can help you build it, but you still have to own it.
• AI makes learning low-level stuff much less scary. Things that used to need a textbook now come with a patient tutor.

So, what am I going to do?

Honestly, I haven’t decided yet, and that’s partly why I’m writing this. My C# background points towards MonoGame or Godot, but the idea of building at least part of the engine myself is very tempting, both for the challenge and for the dev diary posts it would create.

Over to you:

• Would you build your own engine, use an existing one, or go somewhere in between?
• Which engine or language would you pick, and why?
• Have you shipped something yourself? What do you wish you’d known at the start?

Drop a comment below and help me decide. I’ll write up the decision (and the reasons) in a future dev diary post.

Gibbo