HOME | DD

Description
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 'allete' 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.

Description
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 'allete' 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.