Saturday, June 6, 2015

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

5 comments:

  1. Unfortunately, writing your own engine is doomed, especially if you are doing it for commercial purposes and not for education or pure fun.
    These day, there are relatively cheap engines - Unity, Unreal engine 4, Crytek
    I often think, that investing more time writing my own engine is not the very cleaver thing to do, if I want to publish a commercial game. Instead, investing time in game design, level design, 3d asset modeling and texture is more wise, because these things are what actually make a game, and are portable to other game engines if desired. For me, using a ready to use engine like Unity3D or UDK have one big advantage - I can publish to every platform you can think of, including consoles. I have no time and resources to port my Windows only game to support Linux, Android, XBOX, PS3-4 etc. After some years of work, you start to love your baby to the point, that you loose objective valuation when comparing to other tech. Users do not suffer from this and will hate every bug, glitch or lack of features all over the internet.

    ReplyDelete
  2. Doomed sounds a bit too dramatic to me, but yes, one has to realize the difference between making an engine and a game. If you make an awesome engine, you still don't have a game. You can skip all that effort by picking an existing engine, and just focus on your game.

    But as said, generic packages have rules, constraints, limits and boundaries. Adapt and deal with it, write extensions if possible. But if you're planning something that is really outside of the box - or just relative simple so it doesn't require a very advanced engine, it may pay off to make your own.

    In this case I've come so far with Tower22 and E22 (at least with its older version) that I'll just proceed. Rewriting a fresh clean version of Engine22 takes relative little (ahum) time, as much of the trial & error, research and design has been done before. It still costs a ton of sweat, but in the end I have full control over it, and it's in Delphi, a rarity when it comes to game engines.

    ReplyDelete
  3. I can see why you are not going to ditch your engine in favor of other - you have completed some of the hardest task in real-time rendering in my opinion - global illumination. Your visuals are great and somehow unique. On the other hand - I can almost always guess, what engine a game was built with, only by looking a gameplay video. Unity picking system for example highlights objects silhouettes and interacting with physics objects is kinda annoying etc. Uniqueness can make you more often win than fail. when it comes to art and games in particular.

    ReplyDelete
  4. My thoughts exactly (and the only true valid reason to keep on trying making your own engine really). Now probably its not really a technical engine issue, and more that I'm becoming an old nagger, but in general I just don't enjoy most games. Yes, they look good - in many cases better than I can ever achieve. But it's the same drill every time. Developers play on safe with success formula's and a shiny graphics sauce.

    Now I won't say with a big mouth that I'll do a better job, but at least it will be "different" indeed ;)

    ReplyDelete
  5. BTW, I don't know if you are aware, but there are already a huge amount of indie horror games in progress and some of them are also released. Almost all of them use ready to use engines and look kinda nice. What I'm trying to say is that the competition in the field is increasing with quality getting better. Users start to get pickier and start to compare. It's not the year of 2009, where the greatest indie horror game was Amnesia or Penumbra. This fact need to be taken into account these days. People are spewing a lot of games made easily with cheap engines in small amounts of time and funding.

    ReplyDelete