A quick article investigating artistic constraints developing at the interface between game design and technology.
One of the most basic choices in game design is camera management. Choosing to create a game in first, third person view, deciding wether cameras will be fixed or not, these are choices directly impacting processing cost (GPU time, if you want).
*** It takes very powerful hardware driving well optimised rendering engines to correctly display large amounts of painstakingly detailed artwork with a great depth of field. ***
In a typical scenario not all these are available; I orient my review towards “optimisation strategies” which directly encompass artwork and level design. The key idea is that good game art is a lot easier when designers, artists and programmers are willing to designate an area of interest. And as we’ll see, focus needn’t be constant throughout the gaming experience. So we can have everything (detailed characters, pretty environments, atmospheric scenes etc…) and do everything just right, but in most cases we can’t have everything at the same time.
First person games
The problem with first person cameras is that they easily develop perspectives which are deep and wide at the same time. Typically this drives savvy designers in either of two directions:
- Dungeons and Corridors. It is no coincidence that the first FPS games had so many dank corridors. In a best case scenario all that’s left two draw is walls, ceiling and a few NPCs.
(Doom, image found on gt4v.com)
What’s more, dungeons and corridors can be mapped on a grid, so you don’t really need a level editor. Heck, you could map your levels in notepad using a fixed size font.
- Foggy settings. Using fog to limit depth of field is a trick that never grows old (honest). While serious 3D programmers will look down on it, fog rarely makes a scene look bad and efficiently limits depth of field; within limits, it also produces visuals that scale down well over less hardware.
This time honoured trick predates graphic cards.
(Ishar: legend of the Fortress on Atari ST – image found @ mobygames.com)
Isometric views, with or without perspective
With first person games, we start with a problem to which we need to find solutions. In contrast, isometric views (forcing the camera to look 30 to 60 degrees down), are less demanding:
Diablo – image found on rampantgames.com
The obvious reasons being:
(1) the distance from the camera to each object is constant (or mostly constant if perspective is added).
(2) here we don’t need walls everywhere (!) since the camera angle naturally restricts the view to a very small part of the map.
So, this is inherently a savvy approach and there is hardly an excuse for messing up (displaying low definition artwork) – since isometric views are nowhere near as lively, dynamic and complex as first person views.
Platforms versus continuous terrain
Platforms are an awesome device, both for game artists and level designers. In short, platforms are a game convention allowing a very idiosyncratic (meaning, specific to games) form of ellipsis: using platforms relieves everybody from the need to consider ‘intermediate space’ that is either non playable or non interactive.
- Less load on the GPU
- Easier design. Often the junior artists I work with (and myself) find it difficult to design models which aren’t self-contained. It seems that there is an implicit requirement to (mentally) break down continuous environments into separate elements, then later reverse the process and design continuities. Good platforms need visual framing yes, but that is, apparently, more straightforward.
Walls may also be used to delimit playable areas. But walls increase fill (more GPU time) and create design issues – with a fixed camera for instance, the player can’t see behind walls which creates (tractable yet time consuming) problems with either first or third person views.
Platforms seem to work with any kind of view – isometric, first person, third person – the effect is the same. All you need (if anything) is a nice background to act as filler.
Super Mario War – image found on hartwork.org
Platforms are no worse than fog. They are a device which at times may seem cheap. In the meantime, platforms create wonderlands. Floating islands and castles (lost in the fog).
The obvious (lame) solution to warrant awesome game art is to freeze the camera. Two advantages:
- Everything is under control. You get the best shots and you can pre-render artwork for *hours*.
- Your GPU programmer will resign so you can hire another artist instead (yay!)
Okay, this is extreme. Still, many games take significant steps in this direction:
- Fixed angles. Even with an isometric view, using fixed cameras (instead of a turntable style approach) will yield a significant increase in performance (and/or art quality). Also (and although some players readily dislike it) using fixed cameras affords increased usability (at the cost of additional design).
- Games on rails. They’ve been doing it since game arcades, and they’re still doing it. Putting players on a rail pushes the idea of linearity to the extreme.
Non linear gameplay is a deep concept, but when it comes to media production, it is a thorny road as you’re practically scattering resources and incurring the risk of producing a lot of artwork that no single player will fully experience.
Providing a linear story line and defining artwork along a clear path, to the contrary, ensures that all resources converge towards a designed gaming experience. That rail games (however shallow) still encounter concrete success is no surprise ( not convinced? lookup Rage – ID software! – or Temple Run).
Arenas offer a choice that is (in appearance) even more limiting than putting games on rails – with an arena based approach, the camera needn’t be fixed; since gameplay is confined to very little space, it is no longer a problem.
Unreal’s mobile flagship, Infinity Blade, is a well disguised arena game: between fights ‘gameplay’ is on a rail – actually there’s no interaction but since the scenes aren’t pre-rendered the transition is seamless (‘we’re still playing but we’re not!’). During fights the opponents do not move (oh wait, the second half of every fight takes place 3 meters forward, right?).
I attended a post-mortem which leaves very little doubt as to how they fit the pretty artwork into a mobile format:
- Use cards (somewhat-elaborate-yet-to-cut-a-long-story-short-pre-rendered-backgrounds).
- No more than 2 characters on-screen.
- 2048 x 2048 textures, one for each character, including the complete UV unwrap (body, head, armour and weapons).
Using short sequences between fights also reinforces the narrative element. It doesn’t quite add up to a great story, but it makes a world of a difference – who think of this game as a pretty Virtua Fighter?
If we look at the approaches I described so far, all but arena oriented games share a common problem: how can we express characterisation when we don’t get a chance to display detailed characters in closeup?
So, one answer may be ‘using cut-scenes’; but (maybe my own bias), this tends to frame dramatisation ‘outside gameplay’. There is an approach, typical of JRPGs, which can give you the best of both worlds.
Yes! Regular navigation (isometric, FPS style or other) affords developing scope – the sense of being immersed in a large world – while arena based interaction (combat or conversation) allows maxing poly count and texture detail (isn’t it obvious? :D ) to reinforce characterisation.
(images found on epicagames.com)
From a technical point of view, methods are definitely available to help display (and fit into memory) beautiful vistas with a great depth of field:
- Mip-mapped textures
- LoD (level of detail) nodes
- JIT (just in time) pre-rendered backgrounds
- (and more…)
(Note, I only have generic notions about how they do this in realtime).
The Elder Scrolls: Skyrim – personal screenshot found on j-u-i-c-e.hubpages.com
Technical optimisations can be applied regardless of target hardware. What’s happening is that you keep more GPU time for drawing the foreground and I think it’s obvious even in the pretty screenshot above.
In the meantime, I think the approaches I described above are here to stay. Only the most ambitious projects running the latest hardware can deploy the production muscle needed to do everything perfectly at the same time. So I guess the main idea behind my article is that any project can achieve a balance between production cost, visual quality and rendering complexity.
Copyright notice: none of the images in this article were produced by me. These images belong to their respective owners.