Game engines – an artists guide
As a game player, or an artist who modifies games, you will no doubt have heard of an engine in relation to games. However, many people are unaware what an engine actually is, what is does, and how it affects them as an artist. Many people confuse a game engine with the game itself. This is an attempt to explain what a game engine does and why they are used – but to stop this being a novel I’ll approach from the point of view of an artist.
Essentially, an engine is device for collecting, managing and using assets. You put art and sound and logic in one end, and a game comes out the other end.
There you go, that’s that cleared up.
More details?
As I mentioned, many people confuse the engine with the entire game – an engine is not a game, but the core around which a game is written. An engine contains no game, its a layer of abstraction, a layer of processing that sits between the game (fun, story, art, sound, controls) and the hardware.
In the old days games were essentially written for specific hardware. They were one off chunks of code – you came to your next game and you rewrote it from scratch. Quickly programmers built up a library of reusable code, so that, for example, once they written had a good system for handling sprites they could simply copy that code into their next game – perhaps verbatim, perhaps making minor or even major improvements.
Reusing code is a great idea – rather than starting everything from scratch each time, you get a major head start. Soon these little snippets of code build up, and then you realise that playing sound in your last game and playing sound in your next game is the same, it’s only the sounds that are different. Just record the new sounds, bung them in and hey-ho, away we go.
So, rather than writing a game from the ground up each time, an engine provides a core to work around. When developing a game, the artists export their models and textures and animations into a format that the engine can read, as do the sound engineers. The game programmers write a control system that maps buttons presses on a joypad or a keyboard to actions in the game, but the engine does the work of translating the signals from the joypad into something we understand, like ‘Up’ or ‘X Button’.
But what will all those programmers do now that we have engines? Lots of things – they’ll find and fix bugs in the engine. They’ll make the engine run faster. They’ll add new features (and then fix them. And then make them faster). And they’ll even write nice tools for us artists to make it easier to get our artwork out of our heads and into the game.
Hurray for engines!
May 1st, 2007 at 6:46 pm
Thanks very much.I learned more from your article than I’ve been able to find out in the last 5 hours on the net. I,ve been teaching myself 3d animation and have not been able to find out how animation relates to games and VR.Your article has cleared up a lot of my questions.
May 2nd, 2007 at 12:22 pm
February 1st, 2009 at 2:13 pm
“But what will all those programmers do now that we have engines? Lots of things – they’ll find and fix bugs in the engine. They’ll make the engine run faster. They’ll add new features (and then fix them. And then make them faster). And they’ll even write nice tools for us artists to make it easier to get our artwork out of our heads and into the game.”
Oh my god… You are a totally artist, aren’t you?
Actually, there are lots of stuff that programmer have to do, such as game logic, special effect handling, A.I. system, etc. But not only “bug fixing”.
February 2nd, 2009 at 5:56 pm
“Actually, there are lots of stuff that programmer have to do, such as game logic, special effect handling, A.I. system, etc. But not only “bug fixing”.”
I don’t think Rick was saying programmers *didn’t* do those things; but think of it this way.. most programmers aren’t just programmers, they are AI programmers or Network programmers, or Graphics programmers, or Animation programmers, or … (drum roll) .. Engine programmers.
The emphasis of this article is about describing what an engine is (a core around which you build a game) and where it comes from (reused code from previous games). The programmer line you quote above is true (to an extent) for Engine programmers, but you’re right that the other programmers still have work to do. An Engine programmer’s job is never done!
If you want to audition work quickly, in order to demo some feature, you might not need any gameplay programmers, but you probably would need an engine.