Shop Mobile More Submit  Join Login


Submitted on
March 30, 2009
Image Size
435 KB


12,889 (1 today)
85 (who?)


Creative Commons License
Some rights reserved. This work is licensed under a
Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License.
Resistance - Level Art QandA by Athey Resistance - Level Art QandA by Athey
Level design process starts with the Designers talking in meetings and and writing a doc to plan out what sort of gameplay elements they want to make sure get into the level.

Like, first section is a hallway and the player gets to a room and fights leapers, next section a buddy NPC is there and you have to keep them alive while they open some door, and you get attacked by X number of baddies; next room need to be big because a Goliath comes in - etc.

After a bunch of meetings and rewrites, the designer for the level sits down with a layout artist and they build the very basic boxy shape of the rooms and hallways / spaces.
The layout is just a spacial reference and the designers take the layout and do a test population to see if their gameplay ideas work.
They usually DON'T, so the designer works back and forth with the layout artist a while to get it to the point where it works.

The layout has no textures, furniture, shapes, etc. It's just walls, floors, and boxes for cover and object placement reference.

Once the layout is a bit more solidified, it MIGHT (read: is supposed to, but often doesn't becasue of time restraints) go to a conecept artist working with the art director, who will take a couple screen shots of important rooms/spaces and do paintovers, filling in the space, planning out color, lighting, etc.

Then it's given to the level artist who takes the bland boxy layout, and the paintovers, and remodels the whole freaking thing to look pretty.

The level artist usually gets assigned a junior prop-monkey to do odd-job objects or to do a collision pass to speed things along, but sometimes they won't.


A detail that a lot of students aren't aware of is that most levels have to have a lot of extra and seemingly 'unnessecary' geometry for lighting and other technical puproses.

You know, how you hear all this 'low poly! low poly! low poly!' stuff in school about real-time art? Well, it's true, but I bet you'd get confused to crap if you actually looked at our terrain geometry because it looks like we're being insanely in-efficient.

Every flat surface; floors, walls, etc. is covered in a grid of polys.

Even a big huge square room, where you could have one giant polygon for the floor, a big poly for each wall, etc, is instead divided into a giant inefficient polygrid. It looks like a big crazy waste of polygons.

On the floor where you could have 2 tris (1 really big quad), instead you've got 60 tris, and that's for a 24ft x 20 ft space (generally, this is what we use, - we use a 4-ft grid). Relatively sizable room, but still - it could be 2 tris, but instead we use 60.

Why the waste?

Primarily, it's for Lighting.

In the latest gen machines - high-end PC Games, PS3, and (if you really push it and are optimal in other areas), the 360, you can have "real" lighting. Real-time lights, that cast real-time shadows, and look at the geometry to calculate the lighting right then and there.

This is a very CPU intensive task. Anything Gamecube/PS2/Xbox and lower, the Wii - most 360 games, and yes, even quite a few PS3 games, have most of the lighting pre-determined and "baked into" the terrain before hand, instead of being calculated in real-time on the fly.

But that DOES NOT MEAN that the lighting is baked into the textures. That would eat up WAY too many textures, and textures are expensive. Instead it's baked into the verticies with vertex colors.

The more dense the grid is on the mesh, the more detail you can put into the lighting. A lot of places will even go into the terrain and cut in edges where they want shadows to be cast.

It's a balancing act.

Verts eat up resources, so you do need to be sparce where you can, however if you're too sparce, the lighting looks like shit.

Another reason for the needed grid is poly clipping. This depends on the engine, but to save resources, the engine will only draw the polys that are on screen. So anything behind you won't get drawn.

If your polys are too large, you may get things clipping out that should still be visible. If the character/camera gets too close to an oversized poly, it will clip out. This is obviously not a good thing and you've probably seen it happen before.


Okay, so another question was if we use a ';pallete' of textures. The answer is yes, primarily.

It's highly recommended that we re-use the other artists textures and assets for several reasons.

1. It saves time. A texture that someone else made is a texture we don't have to waste time re-making. If it works for what we're making, then re-use it.
Most of our textures are made to tile to make this easier.
We also have a 'general rule' here for pixel density. 128x128 = 4ftx4ft
If we try to remain consistent with this rule, it makes it easy to reassign a texture with just a material id swap and not have to re-UV anything.

2. The other main reason for re-using textures is to keep things matching over multiple levels. Consistency.

On Resistance, we've got Chimera tech all over the place, and re-used a LOT of the same textures all over the different chimera tech in all the different levels.

If one of us made a texture for misc hexagon chimera metal that worked really nicely, lots of others re-used it.

Saves time, maintains consistency.


Keeping things efficient.

Okay, so the floors and walls have to have more density then seems sane - so what about furniture etc.?

Well, since we have to waste a shit-ton of verts on stupid flat surfaces, we have to try really hard to keep our objects/furniture/props low-polly as possible.

To best do this, most of the detail goes into the texture.

A wooden crate will be a box. A simple, flat, no-poly-detail-at-all 6-sided cube (probably 5-sided, since the bottom will be on the floor, so we'd delete that poly). The wood crate look will be 100% texture map.

As much detail as possible is put into the textures, because we simply don't have the resources to model in detail.

This will obviously be different if you're working on a next-gen console. With advanced shaders, and crazy cell-processors that can push a zillion verts, then you can model in a lot more detail then we can on the PSP. But they still keep the poly detail down to the minimum that they need, and often rely a lot on normal maps to add extra faux detail.

Just the same, it's important to realize that there are severe limits on textures as well.

Technically the PSP can handle 256x256 textures, but we RARELY use them. As a general rule, nothing larger then 128x128 is used. We often use 64x64 and even 32x32. (Yes that is a texture map that is much smaller then your avatar on deviantArt.)

These are also only 4-bit color density. 16 colors per texture map. Nothing more. The PSP CAN handle larger then that - It IS NOT a hardware limitation, but a self-imposed limitation. You'd be amazing how significant the texture file size difference there is between an optimized 16 color texture, and a 256 color texture. IT'S HUGE.

Low color, optimized textures are only like 4k per texture, and that's what we have to resort to, in order to fit everything into memory.

Making textures that can be re-used all over the level is important too. We don't unwrap every little object into it's own texture map. That's a waste. We do it for specific objects when needed, but a lot of general stuff is simple tiling maps that are re-used all over. We'll have a dirty metal texture that's used on lots of different things. The side panel for some machine. The legs for a metal work table. The body for some big metal contraption. The pipes in a room. The trim of a large metal door. All different parts, used all over the level, but using the same 128x128 texture map.

Very few things can be streamed from the disk on a PSP game. Battery life is important, and streaming EATS THE BATTERY. So the whole level has to be loaded into memory at the beginning, before the game play starts.

At our studio, we get 4megs for the level art. No More. Everything is divided up to try and give everyone enough memory to work with. Character geometry gets a file limit, particles get a file limit, Design has to work within a limit for their scripts; they also have to pay attention to memory for active NPCs for the AI - which eats up a lot of memory.

On Logan's Shadow we had Havoc (real-time physics objects), and havoc objects ate up a lot of memory. We didn't use Havoc in this game because we wnated to try and squeeze as many NPCs on screen as possible. We also added a lot of new enemy types like the leapers (The little dog-sized crawly monsters that pop out of pods and attack in packs). On the Syphon Filter games we never had more then 3 or 4 enemies on screen at once. We really tried to push that in Resistance, so we had to be more optimal in other areas.


That's all that comes to mind at the moment.
If anyone has more specific questions feel free to ask them and I'll do my best to answer.
Add a Comment:
infinityspiral Featured By Owner Jun 20, 2012  Professional Digital Artist
This is actually a really interesting read :) I hope you keep these up.
SamuraiTaiga Featured By Owner Mar 13, 2012
Fascinating lecture, and explains a great deal, though I'm not surprised at all. Film industry was often like this, with loads of "extra" details that didn't seem anything more than waste, but really added effectively to the overall imagery of the film. Writers - good writers - do the same, and the better ones never miss a trick in using those early details becoming occasionally very important later in the resoluton of a story scene.
Arekkz Featured By Owner Jan 7, 2011  Hobbyist Interface Designer
That is really useful! Thank you! I am a Game Design student myself, and I really want to go in to Level Design, so I found this really insightful!
Albrecht-Smuten Featured By Owner Jul 29, 2010
Oh god... you are a bottomless source of information and itīs so cool of you, that you share it. Probably a best reason to get the Deviousness Award Iīve seen so far (though something tells me you donīt care about it at all =) ).

Thanks a lot.
Satsumo Featured By Owner Jul 28, 2010  Professional Traditional Artist
This is very well written. A real explanation of how game environments are modelled, including the technical limitations and the workflow. People are always asking for this kind of information.

I especially like that you explain why there are so many polys in the flat surfaces.

That isn't just PSP games either. High end PC, PS3 and X-Box 360 games still use this method. Some rendering math is still too complex to done on a per pixel basis. Specular highlights, depth of field effects, volumetric fog, these are typical done on a per vertex basis.

It may need another generation before those extra vertices dissapear, possibly not even then. Plus, there will still be extra vertices for texturing.
jabranbaig Featured By Owner Mar 5, 2010
very nicely well done
Karmiska Featured By Owner Sep 25, 2009
Thank you for a nice explanation on game design workflow. I knew most of it, but it's good to hear it from a professional. I'm planning on a career in it and that was valuable information.
Roelor Featured By Owner Sep 17, 2009

Wat's the trianglecount of your average level,
(it could be that you mentioned it but I must've read past it.)

I am trying to model for lower performance machines, but the game engine doesn't support vertex colours. Is it still better to do it this way? (I'd still have to use a larger heightmap/polymap, (go over all the geometry with a transparant gray polys.
Athey Featured By Owner Sep 17, 2009  Professional Digital Artist
The triangle count of the level was never something we considered.
It was 'no more than 30,000 verts ON SCREEN at a time' (that wasn't how many verts were in the whole level, just how many the player could see as he turned around and faced different areas), and 'keep the level geometry memory under 4mgs. But that's for PSP. Whatever engine you're using most likely has completely different limitations. There is no universal law that applies to all engines or systems. If you aren't using vertex colors than the system must have some other way that it lights the levels, and THAT probably eats up it's own allocation of memory.
Roelor Featured By Owner Sep 17, 2009
(The only way is using shaders or shadow geometry or even realtime shading, Which (the realtime shading) I don't consider for the level itself.)

Add a Comment: