[Edit] Since so many have people have brought it up: I never advocate to write engines instead of games, but rather that there are virtues in writing a game from scratch (for learning and hobbyist purposes, mostly).  The “smartest” route to get something out quickly, as I suggest many times, is to use a preexisting engine.


Yes, that is an inflammatory headline, but it got your attention, right? Before you get violently philosophical, let me elaborate.

Many people argue that you should almost never write an engine from scratch, but rather just use what is out there already.  I disagree (sort of). For the sake of brevity, let’s distinguish the two routes:

  • Route A: Use an existing engine.
  • Route B: Roll your own engine.

If things like:

  • “safety”
  • “speed of implementation”
  • “quarterly revenues”
  • “personal hygiene”
  • “eight hours of sleep”
  • “feeding your children”
  • “sanity”

are all priorities for you, go with Route A…Nancy.

On the other hand, if you are the type of person that:

  • hates reading instruction manuals
  • likes pushing hardware to its limit / voiding warranties / small fires
  • resorts to violence instead of debugger sessions
  • smells like an alcoholic lumberjack
  • fights honey badgers for scraps of meat

then you should probably go with Route B.

But seriously, why might you want to write your own game engine? Are you stupid? Are these people stupid?

  • Markus “Notch” Persson
  • John “I Hate The Color Spectrum” Carmack ( I kid, I kid…but it’s not like I’m the first person to crack such a joke ;) )
  • Timothy “Not CliffyB” Sweeney
  • Richard “Lord British” Garriott
  • Ken “Kick Ass and Chew Bubblegum” Silverman
  • Eric “Out of This World” Chahi

The answers are: “no” and “no.”  Well, “no” to the latter question, at least.  They (among many others) all wrote their own game engines at some point, and many of them still do (or at least oversee the creation of new engines).  It might seem the polar opposite – some of the smartest people we know in the game industry write their own engines.

First and foremost (and this is just my theory) – people that write their own engines do it because they enjoy it.  Or they are clinically insane, but it’s a thin line, right?

Does this make you somehow inferior if you use a preexisting engine? No; if you fall in that camp, you are probably the more rational of the two.  Some people are able to do amazing things with preexisting engines.

An analogy, if you will: you can customize, upgrade, and otherwise enjoy your car without being an auto mechanic.

Are there more concrete reasons you might want to roll your own engine? I think so.  Here are a few:

  • You may develop an understanding of game engines, computer hardware, and advanced algorithms by only using preexisting engines.  But your understanding will quite likely be dwarfed by anyone who has put serious effort into building their own engine (given equal experience).  If you have built your own engine(s), you will likely be able to better utilize and hack preexisting engines.
  • You have full control over your own engine, and full understanding of its inner workings.  Changing any detail is relatively trivial – in a prebuilt engine (especially without access to source) sometimes the most trivial details can be a nightmare to change.
  • Many preexisting engines are bloated.  If you are writing a simpler game, sometimes it’s like using a sledgehammer as a flyswatter.
  • Your game might have very unique mechanics that are difficult, impossible, or too performance-intensive to implement in a preexisting engine.
  • Most preexisting engines are very good at importing assets (3D models, textures, etc).  But what if you want to generate your own assets within the engine (i.e. procedural generation/synthesis).  Many engines are ill-suited for this purpose.
  • A trivial and superficial point, but nonetheless something to think about: you can stretch many preexisting engines to their limits, but you will probably will not have as much of an opportunity to create something technologically innovative.

hacker guide states:

  • The world is full of fascinating problems waiting to be solved.
  • No problem should ever have to be solved twice.
  • Boredom and drudgery are evil.
  • Freedom is good.
  • Attitude is no substitute for competence.

I think “hacker” is a just a fancy word for “pioneer.”  They like exploring new areas, and hate covering mapped ground.  It might not be the most rational or profitable course, but “real” hackers are more about having fun then churning out a few extra bucks.  If you roll your own engines, you might not be a hacker, but you are probably on the right path.  Grasshopper.

You might argue that times have changed, and it is no longer feasible to roll out your own engine and meet audience expectations.  If you are a AAA company, this is probably the case, but if you are an independent developer, ugly and lo-fi are hip.  Hardware has changed, nothing else.  You can still write games and pretend like you are living in the days of shareware, 3.5 inch floppies, and BBSs.

You might also argue that if a hacker is someone who hates reinventing the wheel, why would they create their own engine when much of the work has been done for them elsewhere?  The answer to that depends on the purpose of the engine.  If you are simply building your own copy of the Unreal engine, you are not doing anything new, and there is no point to writing your own (other than perhaps learning, and the ability to easily modify and open-source it).  If you are writing your own engine, hopefully its because you want to try things that other engines cannot do (or cannot accomplish with the same level of performance).

All of that aside, there are more fundamental reasons for creating engines.  In a healthy software ecosystem, there are options.  Not everybody wants (or can afford) the latest AAA engine – some times people want simpler, smaller, and cheaper (or free / open source) alternatives.  Somebody needs to create these engines, they are not formed in a vacuum.

So what are the drawbacks (aside from the obvious ones)? Your first engine will probably be a failure.  A messy, flaming failure.  So will your second, and third.  But at some point, you will probably get the hang of it.  If you want to learn, keep scrapping.  If you want to actually get a game out the door, suck it up and stick with your current engine, or use an existing one.  Most importantly, if you want to build a game, do not get caught up building an engine.  Do the bare minimum to get the game out, do not obsess about adding features to your engine.

[Edit] As Richard Fine pointed out in the comments below, it can be kind of fruitless for a newcomer to write their own engine when they have no idea of the complexity or scope of what it takes to make a solid engine.  I think there is truth to this – you might be able to learn a bit faster by learning how to use other engines first and getting an idea of how they function.  Nothing wrong with that, really.  Alternatively, you can get your hands dirty and learn the hard way – it is possible you will come out with a different (not necessarily better or worse) understanding of game engines.

Am I biased? Absolutely. But I am also speaking as someone who has tried many preexisting engines (UDK, Unity, Torque, and a few others), and I have been writing my own engines for over a decade.  If rolling out your own engine is such a bad thing, you might think that at this point I would have learned not to do it?

I have now built and scrapped over eight engines (I think).  My current engine is a few weeks old (screenshot below!).  It is voxel-based, and will probably never see the light of day.
But I am having fun at least. :)