Thursday, January 25, 2007

Game engine task

Game engines are the invisible glue that seems to tie together all the assets that create a game -a decent engine can literally make or break a game long before the user gets to sample any modicum of gameplay. At its most basic level a game engine ties together among other things a 3d renderer, collision detection, sound, scripting, animation, artificial intelligence, networking among many other things. Creating a link from the base level of a computer to the inputs of the user, often via a graphical api like DirectX or OpenGL As far back as Wolfenstein, engines by way of my nerdy legend John Carmack have written ever more and more complex engines adding in feature after feature as the power of pc's have increased the feature set of these engines has in turn increased - in fact game engines and 3d accelerators have an almost symbiotic relationship with the increasing speed of pc's linked to the ever increasing feature set of the engines.
A engines key engine technologies are constantly being updated and up hauled for a new faster technique in fact its rare for an engine to have a feature in one iteration but lack it in the next - game engines seeming to take a kitchen sink approach to features trying to pack in as much as possible.

Nowadays game engines are some of the most complex pieces of software written tieing together countless features to ultimately display and run a game. Because of there overarching complexity and the time it takes to program engines are often licensed out to third parties, the most significant of these are the Unreal and Quake engine games of which the licence for a single game can cost upwards of one million dollars for the latest Unreal 3 engine. These engines now include an entire suite of features and tools to better implement and create there game – merely having the engine is nowadays not enough, developers expecting an entire suite of tools to better implement and create there game.

Subtractive and additive could mean one of two things I’m not too sure which so I'm gonna detail then both – woo! Subtractive and additive editing is relation to how game levels are created, subtractive takes away a predefined block from the ‘void’ while additive editing means adding features to a featureless 'void', such as walls, floors etc much like space. I could write entire essays on why subtractive editing completely sucks simply because of my Quake engine knowledge but they fall on the unreal engine devil side so i'll ignore them. Simply having subtractive editing seems to rely more on blocking out a level then falling back on predefined models to populate the level while additive mapping rely's more on adding further details still in the level editor and allows quick and easy eidit and manipulation
(Think im gonna write a blog about all this actually)

Now the other Subtractive and additive doodad could have meant adding and taking away features of an engine depending upong its end use.
The most obvious examples i can think of are the Doom3 and source engine lighting implementations, the Doom3 engine uses a per pixel lighting engine meaning all lights in the game can cast shadows depending upon the objects surrounding it and is automatically updated if the objects move around, the shadows lenghtening and shifting - this is very demanding on most pc's so the Doom3 engine is limited to a few lights each time and refined to traditional corridor based enviroments while the Source engine relies upon precomputed lightmaps, the map creator places lights around key points in the level editor before compiling it which works out how each light would react and illuminate the surroundings. This is much faster and more suitable for larger expanses of surroundings the only problems is the lighting is entirely static - shooting a light would certainly not have the same outcome as if you shot it in Doom3 and moving or editing a light in the level editor would mean you would have to recompile the entire thing. A game like far cry which features both indoor and outside expanses relies upon both precomputed lightmaps and per pixel lighting to achieve the desired effect, i think developers will be dropping lightmaps almost entirely in future titles as the hardware becomes more powerful and fall back on stuff like soft shadows and the like

No comments: