Friday, June 12, 2009

Engine vs. Game

When immersed in amateur game programming, there's 2 ways to go. The game of the game-making, or getting skill points on engine programming.

There's plenty of strong opinions of what's better and what's not, but the truth is they both have their strong points and appeals for the beginner programmer, this must be so, or else natural selection would have claimed one of these two ways long ago.

As for what I think...

Before going in depth on either of them, I'll do a fast forward and give the definite answer to life, the universe, and everything:

Whatever you have most fun making.

That's one of the few pros of being an amateur, you can actually code just for fun, whatever goes your way. Putting that aside, lets have a look at some real arguments:


  • You learn, not more (quantity of knowledge is in direct correlation to, basically, quantity of work, wherever making engines or games), but more basic. You go down a deeper level and fight with elemental bugs. As with everything in life, the more you work on the basics, the more skill you'll achieve in the long run.
  • You get a head's up on engine design and architecture, which will make using any 3rd party engine much easier, cause after figuring out the logical way to design that entity class, you won't be surprised when you find a physx::Actor and see some of the physical methods you did for your engine.
  • As you probably won't be writing the whole engine from the most basic level (bliting pixels to screen using hardware functionality for example, is too basic level) you'll get the hang of a lot of auxiliar libraries. Maybe opengl for gfx, tinyXML for those weapon data files you wanted, or sdlMixer for making your speakers blast some sound.

  • Its boring, up to a degree. Sure, you always have the hard-core programmer's joy of implementing a new feature here, tweaking a system there, but there's always a point when not seeing results starts eroding morale. It's not too bad per-se, but it can quickly kill a project, and that is something to be avoided.
  • It's harder, which to some translates to boring, which takes us to the above logic.
  • When all is said and done, you actually have nothing to show. No game here to play and show of to family and friends, nothing visible to put on your portfolio.


  • You learn to make a game, which is a obscure science that no one can teach. Something like illumination, but with a lot more networking involved.
  • You have a shinny new gem to add to your portfolio, and to impress chicks at bars (well, some chicks, at some bars at least).
  • You get your hands dirty with a full featured engine, and learn from their design and their functionality.
  • It's easier, and faster, make that much much faster.
  • You have things visible from near the start, and there is nothing for keeping morale up like seeing little everyday improvements to your project.
  • It gives you security, as you finish one game after another, and that in turn makes you push a bit further, take bigger challenges.

  • Half the work is done already. So that's one part you won't be needing to sweat, but it's also a part you're not gonna learn how it works.

The above is my personal experience, so the conclusion will be my personal advice:

Make some games, get the feel of some engines, see what works and what doesn't. Those structures and systems you build time and again (entity manager, log system, menu state machine, any of those ring a bell?) save them up and re-utilize them from game to game, that way you'll be making them generic.

When you've done that, make an engine. Learn from the bottom up, get a paper tablecloth and sketch a full blown design of the engine, and implement it with care and dedication.

That over with, get back to making games, and if the engine works fine, remember to release it to the nice folks of the interwebs, so we can learn from you!

No comments:

Post a Comment