Should I write my own game-engine?

People always ask me: “Rick, how the hell do I write a game?”. Well, not really true, as people don't ask me personally, but this question has been asked countless times in the internet fora. Together with “which language should I pick?”, or “Should I write my own game-engine or use an existing one?”. So, let me try to light a few candles in this massive dark cave.

First of all, learn how to program a game. That’s not meant to belittle. It’s a serious advice for those who didn’t write a game (or two) before. I must have tried it dozens of times. And usually with little success, or at least with unfinished results. It’s difficult, consumes hundreds/thousands of hours, and makes you feel lousy when comparing your first 3D cubes or animated sprites with an A+ title from the commercials. Nevertheless, as they say, you will learn as you do. And that’s my point; you can’t start writing a brilliant game or engine without having some experience. The programming skills might be sharpened, yet you will need to make some dumb mistakes and find out what works and what doesn’t work the hard way. I can guarantee, each time I’ll rewrite software –and it certainly doesn’t have to be a game- I’ll do it better, smarter and more efficient. Because you still remember what sucked in your previous attempt.

That said, you have a choice when initiatiating your game. (A): Pick the long route of writing your engine(s!!), then finally make your game with it. Or (B): pick an existing engine and focus on the fun part; realizing your game. If you have plenty of time, no social life, can coop with frustrations, and like to learn every detail, go for A. And otherwise if your top priority is just realizing that game in a somewhat reasonable amount of time, I’ll advice B.

Giving this advice is a bit ironic, trying to make the Tower22 game for ages. People always ask me: “Rick, why not use Unreal or some other engine?”. And that’s a real question. Yeah… why not…? That question has tormented my soul (and ego) more than once.



EngineX versus YourEngine
All right then. First of all, when I started trying to write games, there were no big-ass game engines yet. Maybe some 2D platform “Game Makers”, and of course the option to modify Half life, Doom or Unreal Tournament, but no complete engines. At least not for mortals without money like you and me. Of course, when making a game with, say, Unreal Engine, you'll be modifying their existing Unreal game in essence. But it goes far beyond making a different map with some different textures and sounds these days. Lots of tools, and also the possibility to override, rewrite or add your own (C++) code to alter the game rules.

But in my days, you had to make it all yourself, or at least ensemble a bunch of tools and libraries. Lightwave or Max for making 3D models, Delphi for programming, GLscene components to ease up OpenGL usage, Newton library for physics, et cetera. So my stubborn attempts to make my own engine instead, comes from a “do-it-yourself” history. Giving up and joining the Unreal, Crytek, Source, Unity, Ogre, or whatever SDK, really feels like losing after fifteen rounds in a boxing ring.

But since most games require a team, and thus *teamwork*, that pride doesn’t justify the choice to write your own engine (or not). Besides doing an unlimited pile of work, the biggest problem in my experience is finding artists. Not only does a good artist want a cool project + some compensation; they also prefer to work with a solid toolset. Unreal Engine for example provides a solid toolset, that is used and favored by more and more artists. When making your own crap, this is definitely not the case, unfortunately. Sure, you can make editors and tools too, but yet again it will consume lots of extra time. Time that could have been spend on making an actual game. And unless you focus on really specific tasks, chances are little you’ll make a more awesome toolset than the existing ones. Artists will keep saying “But in UDK you can…” blabla. As programmers, we don’t want to hear that. But you know they have a point.

That’s a fat 1-0. For “Existing Engine” versus “My own Engine”. Ouch. Personal reasons like learning a lot from making an engine from scratch are certainly valid, but again not so interesting for an artist helping you out. If you plan a (smaller) game that you can make yourself or with some friends, you’ll have a bit more freedom (read tolerance from the assets creation people). But I can’t make a game like Tower22 on my own, or with a few friends. The audio-visual quality bar is too high to produce assets myself, and the numbers are too big to do so with a few men. So, we’ll need help, simple as that. But you won’t get much help if they have to use your (unfinished / faulty / unfriendly) tools… if those tools are ready at all…



A generic bland taste
But anyway. It’s not impossible to create proper tools of course. Which is why I said you’ll need some experience writing games, editors, or similar software before initiating your next SuperEngine. It’s only too bad you’ll need to fail a couple of times first before doing it right. But at least you’ll be experienced by then, which is valuable knowledge wherever your programming skills are needed.

If there is one truly good reason to make your own engine, besides for gaining experience or saving money (most engines will charge when selling your game), it would be to give it your personal touch. As professional engines get more and more flexible, doing so in an existing engine is also more possible, yet there are some constraints. Now I’m not a Unreal or Cryengine expert, but obviously these engines are biased towards shooters, first- or third person action games. If you plan a Flight Simulator, Tetris, Formula 1 or Mario alike platform game, they’re probably not the best choices.


As with any generic multi-purpose package, there are boundaries and rules. And these packages have to balance somewhere between keeping it simple stupid, and giving enough options. More options and tweaking generally means harder-to-comprehend. Less options usually means easier-but-limited. This goes for Microsoft Sharepoint office, ERP database programs, website builders, programmable domestic devices, robots, and so on. Game engines are no exception.

Of course that doesn’t matter much if your planned games fall within the engine specialization. But since Tower22 certainly won’t be a shooter and does contain some atypical elements that you won’t often see in most games, I’m quite sure that most existing game-engines will pull me down at some point. It also occurs to me that many games based on a specific engine, keep carrying a certain graphical style, and gameplay vibe. Your sub consciousness just knows you’ve been there before.

All in all, I just don’t like most generic software packages out there. And so, the “do-it-yourself” modus is engaged. It’s a shitload of work, finding artists is (too) hard, I’ll get stomped away often when the big boys show their new breath-taking technologies. But, this games feels mine. It may not look better, but at least it looks different. And it will play different.


A shot from the "old" Engine22 map editor. A new one is in the make. Not the first one, and probably not the last map-editor I'll write in this life either (although I hope so).


Need some help?
Making your own engine certainly isn’t impossible. But you’ll need to have some experience – or make an engine just for gaining that experience on a relative simple game. You’ll need too many free hours, and you’ll need to be realistic about it. And as explained above, you’ll need a good reason. If you *have* to make an engine solely for realizing your game, you will likely get bored and stop halfway. To me, making Engine22 (for Tower22) the past ~7 years almost feels like sadomasochism.

So, if you still feel like making your own engine, then I have some good news for you. But also for those who don’t want to make their own engine (completely), and need something Delphi based, read on. As promised before, Engine22 will be released. That means you can download the Delphi files (as BPL packages currently), and later on also some of the tools and example materials. And as we do, I’ll explain the why’s and how’s in the engine bit by bit. So whether you plan to use E22 or not, this Blog (or a side-Blog, Wiki, maybe Youtube channel) will guide you.

As I’m doing an engine re-write (hence the re-attempt warnings I gave above!), it will take some time before the units and tools are *done*. But at the same time it nicely allows to document my steps. And having learned a terrible lot the past years, the re-write will be better, smoother, faster and tighter than ever before. I wouldn’t say “learn from the master”, but I certainly think I can help you on your way, either with E22 code or by posting articles.


To give it some body and structure, I’ll be making a simple (Delphi) demo program to begin with. “Labyrinth Bowler!”. Or something. It won’t be an awesome game, but it’s a nice simple test-case to guide you through the articles below. Of course, I’ll be using Engine22, but the underlying logic and tactics can be used for your own engine as well.

* Labyrinth Bowler: Sample Game description
* Engine22: Tasks and responsibility
- What should an engine do?
- Modular design
- How to extend it with custom code?

* Basis – Start the engine
- Project setup
- DLL’s, BPL’s, dynamic libraries, static libraries

* Basis - The drawing canvas
- OpenGL, DirectX; graphical API's
- Setting up a Viewer
- The Camera
- A sphere? No, a bowling ball


* Basis - Handling Input
- Keyboard / mouse
- Moving around
- Vector math

* Basis - 3D labyrinth mesh
- 3D modeling
- OBJ file format
- Loading
- Resource manager

* Basis - Bump
- Physics
- Collision detection

* Basis - Photorealistic bowling
- Material / Shader system
- GLSL
- Reflective ball / simple lights

* Basis - Scoreboard
- 2D HUD / GUI
- Fonts

* Basis - Make some noise (Sound)
- FMOD
- Collision reaction