For previous Question/Answers go here.
The Question:
"Last time I asked a question to various professional level designers about the process
of map design most had one thing in commen in their answer, 'Keep the framerates up'.
How do you go about trading visual impact for playable speed?
What process do you use to determine what is playable and what is too damn slow?
What benchmark, test, or magic rock do you use to determine this?"
-Idoru
The Answers:
"I think that frame rate is very important in level design and,
unless your goal is to design SPECIFICALLY for high end machines, you
should try to keep your map as simple as possible while still
maintaining nice visuals so everyone can get the most enjoyment out of
your map regardless of their machine speed. Generally when we start a
project, we determine a "target number" of polys that can be in view to
get optimum performance on our minimum machine. I try to always stay
below that number and I know that Raven's Eric Biessman generally tries
to stay fifty to one hundred polys below the target number! Amazing...
But, his maps are always visually aesthetic, fast, and fun and the
effort to keep it simple is very much appreciated by internet gamers.
Poly count isn't the only important thing to remember when designing a
map for speed...CLIPPING BRUSHES are crucial to a map's success...
Nothing is more annoying than getting stuck in a corner or on a door
frame and having someone frag you because you couldn't get off of it.
So, to make a long story short...YES, frame rate is very important to
me. To balance aesthetics with speed, just ask yourself the question
"Do I really need this?" about your architecture and if the answer is
"no," pull it out... The net players will love you for life! =) Just
sit back and let your textures do the work..."
-Kenn Hoekstra, Level Designer at Raven Software
"Block off entrances and exits with either zig-zagging corridors or with
area portals inside doors. Make areas of high detail small or put less
monsters in them.
Don't do your design testing with GL. Test in software mode. Also, test
on a "slow" machine. If it seems slow there, then it is slow. Use the
R_speed indicator (I keep mine bound to F7 for on F6 for off) to watch the
milliseconds (same as Quake). When you've got monsters in your map, try to
keep it below the magic number of 100 milliseconds. When building geometry
try to keep the central number in the string (in view count of polygons)
below 500. Lower is better."
-Paul Jaquays, Level Designer/Occasional Artist at id Software
"Before creating a map, you need to have a certain minimum or average
framerate in mind. This should be determined by what the map is intended
to be used for, as well as who its intended audience is. This means that
if you're releasing a single player map on the net, you may not need to
design for a p150 with 32 megs, since most of the people downloading your
map will have a better machine. On the other hand, the type of map is
important too. If you're designing a deathmatch map for 4 players, then
you need to test your map with 4 animating and firing player models in
every scene. If you're designing a 64 player deathmatch map, then be
careful of big rooms, even if they have low world polys. As far as the
actual benchmark, we all have the trusty 'r_speeds 1' to check our ms
between frames. For Sin, we have the convenience of using 'fps 1', which
is the same thing in an easier to read form. During a single player
experience, a player will be happy getting 15 frames per second, and maybe
10 in the far corners. (Remember, I'm not talking about your p2 300 w/riva
+ voodoo2 super user here.)
The process of trading visual impact for playable speed is a whole other
issue. The easiest way to make a scene look better is to add another trim,
or put another level of detail in the architecture. Before adding too many
polys to your scenes though, mess around with more basic shapes, and find
something that looks good in a simple form. All of the best levels out
there aren't a complex mess of architecture, rather they are often a few
simple shapes used right, and used consistently. Lastly, let the textures
do the work.. but not all of it, or the artists will get too much credit. :-)"
-Michael Wardwell, Level Designer at Ritual Entertainment
"For the professional, the benchmark is usually a budget and target frame rate
determined at the onset of a project that's roughly related to the game's
target system. For us, the minimum speed on the base system we're targeting
is about 18 frames per second. Of course, it's our hope that the base system
is the low end of what people will be playing our game on and the much higher
frame rates will be the norm.
Sometimes, something is just too cool to reduce to an optimal frame rate so
as a general rule, I never let a scene drop below 15 frames per second. When
I used to work at 3dRealms, the technique for determining scene frame rate
was to check fps with the view looking at the most complex scene possible
(worse case) for any area of the map. This is the frame rate we'd try to keep
above our benchmark.
Technique for keep frame rate high depends on personal style, the visual goal
of the area and the game play that will be taking place there. Here are some
general rules I think about when optimizing frame rate and planning for level
geometry detail:
1) Consider the game play complexity of the scene: Areas that won't contain
many actors or expensive special effects can afford more geometry and broader
views. If you want to create a crazy gun fight with a dozen guys in an area,
don't crank up the detail in the wall and ceiling geometry. In fight situations,
generic level geometry is transparent anyway. Players will be focusing on the enemy
and the fight and will probably not even notice your steel truss ceiling
structure.
2) Give the impression of realism: Often, I notice amateur designers trying
to imitate reality more closely than they need to. When you need to give the
impression of more than one thing (like chairs in a movie theatre), use three
to five, or build them in pews as Allan Blum III did in level 1 of Duke Nukem3d.
Don't actually build the more realistic dozens of chairs. It's expensive and
it's no fun to navigate. Always think about how simple you can get to give the
impression of where you are without burning your budget imitating reality.
3) Use detail to attract attention, less detail to avoid it: The player will
focus on things that are interesting. If you want the player to look at
something (hopefully something integral to the current challenge or overall plot) make
it very detailed and save your budget else where. Detail can be used to
misdirect a player's attention while a trap is sprung or direct a player's
attention when something important will happen there.
4) Conversely, use less detail where there's nothing to be interested in: If
a certain wall or floor should be of no interest to the player, don't make it
interesting. You don't want the player always focused intently upon your
pipes and mounting geometry below a Plexiglas floor when a key or
important puzzle element is nearby unnoticed. Unless your hope is to
frustrate a player. Detail is a clue...use it as such.
5) Use occluders: A large complex area can be effectively divided into two
areas with a set of geometry designed to block and limit view of complicated
things in either section. Occluders often affect pace and game play, so plan
for built in occlusion when outlining your map. No designer wants to ruin a
large visually striking scene by erecting a wall the blocks the view of the
most interesting parts. Planning for occlusion before you burn your detail budget
can eliminate the pain of optimizing later. Also, when using Quake tech, know
that BSP cuts when compiling your level will take a simple rectangle occluder
and use it to cut floor, wall and ceiling polygons into geometry significantly
more complex than it appears on the surface lowering frame rate.
6) Beware of overdraw: This isn't that important with Quake tech, but with
engines that allow mapper use of multiple passes for special effects and no
automated cuts of simple intersecting geometry, over draw can be a problem
especially when developing for early 3d accelerator cards. Fill rate is the
ultimate limiting factor and must be accounted for when designing your level.
7) Plan ahead: Freestyling is cool, but can often lead to headaches and
problems down the road. Careful planning of area budgets, visual goals
and rules per scene will allow the designer to achieve what he wants
without having to drop some things that the designer has grown attached
to.
8) Leave it and come back: When working on a map 12 hours a day for
a month, it's easy to become to personally attached to the work. Put the
level aside for a couple of weeks and work on something else. When you
come back to the level, it'll be easy to more objectively decide what rules,
and what sucks about the map. You know how you look at your old work
and think how some things you did were really cool and some stuff was
just plain dumb. Use the conversely related values of time and preciousness
to your advantage. It'll make it easier to drop unneccessary detail and get
the speed where you want it. You'll know where you get pissed off
about game speed when your mind is open.
9) Cut, Cut, Cut: Don't be afraid to cut out some of your work in the
name of frame rate. Make sure you save the stuff off, though, as you
may wish to use it for something else later. Never make anything
unless you're willing to cut it all when it just doesn't work for the
overall goal.
10) Focus on the fun: The only real requirement for a level is fun. While
visually striking geometry can impress, complexity doesn't always equate
to entertainment. Never potentially risk the fun of an area by erecting
occlusion geometry that slows down the player to keep your detailed light
fixture you spent six hours building. You get the idea...
-Randy Pitchford, Chief Game Architect at Rebel Boat Rocker, Inc
"This is definitely something that level designers wrestle with every day. I
can guarantee you there's not a level designer alive who wants to trade
visual impact for speed, but it's a necessity in many cases. One way of
doing this without losing a lot of the visual impact is with textures that
give you the same feel you were going for (a very simple example is a rim
around a walkway - if you can get a texture made that includes that rim
texture and the walkway texture, you haven't lost any detail and you have
the same visual effect you wanted). There's a definite advantage to having
artists available who can create textures that you want.
Short of having a new texture created, you can do things like flushing
light textures to the walls or ceilings they're attached to. Although this
means cutting up a brush or two to embed the light, it still hides faces
and I have seen it make a dramatic difference. You do lose a little bit of
the visual impact but the texture gives basically that same picture. The
whole process is a balancing act and can take a lot of experimenting and
redoing to get the framerate where you need it.
Determining what is playable is really based on your target machine and
your hardware requirements for the game you're developing. Every company
has an "old" P100 or P133 with 16 megs of RAM sitting around for testing
purposes. Running your level on your target machine is an excellent way to
see if areas will be playable, but it's not always practical. In the
Quake/Quake2 engine, we can look at r_speeds. Using r_speeds as an absolute
measure of speed doesn't work, but it can give you a very good idea of
where things are. It gives us a general idea of how "fast" the level is
running and allows us to spot problem areas early. Understanding the engine
and how monsters affect r_speeds is also critical in the overall picture of
framerate. A room that's running relatively decent according to r_speeds
might just bog down after adding a half dozen monsters for the player to
fight.
All of us look forward to the hardware only engines that will make this
issue a lot less important. Framerate will always be an issue, but someday
soon, it could become a much smaller one.
-Steve Thoms, Level Designer at Rogue Entertainment
"Well, simply enough, a FPS (Frames per second) counter is God when it comes to tweaking for playability.
In the mission pack we mainly stuck to r_speeds as the final benchmark of speed on a level, but there are other factors that
can choke down framerate. Thats why a FPS counter is more essential than just a poly
counter. If you want a room to be more complex than others, you may just need to
keep the number of visible monsters lower to lend to a higher r_speed. The only real
way to test that is with a Framerate counter. There is really no leeway when it comes to
framerate, we usually pick a target framerate on a target machine (usually the minimum required machine for a product), and make all efforts to never go below that
targeted framerate. Its all a balancing act, keeping everything in mind when creating a level, the
speed of the progs, the poly count on monsters and guns, the hit of blinking or dynamic lights,
the amount of visible textures, and everything else under the sun.
-Tom Mustaine, Level Designer at Ritual Entertainment
"some of my previous maps are quite famous for having areas with really high r_speeds, and i still end up
reducing areas because they are too slow today, so maybe you shouldn't listen to my advise ;)
framerate is important in every level, but also depending on the type of level you're building: a
deathmatch level should of course have a high and (more important) consistant framerate, don't build
areas where the framerate is suddenly going down drastically. since DM maps don't have to be too
detailed (still try to make them as beautifull and cool as possible, though ;)) reducing an area that is
too slow isn't such a big problem though, i think.
framerate in singler player levels can usually be lower, even if you are designing it with DM support.
i consider 10-15 frames on the low-end machine as ok - if you are showing some cool scenery that doesn't
include fighting the framerate may be a bit lower - but since you're showing eye-candy (hopefully still important to the gameplay) and the player doesn't have to move fast it is imho ok.
i guess r_speeds are used most often to determine if an area runs fast enough - in SiN we don't care
so much about r_speeds only, though. if all your areas have r_speeds under 600 you're great - if they
go over 1000 you should really think about reducing. but as long as the framerate is ok r_speeds don't
matter. we have a fps counter in SiN that should show at least 15-20 fps on our target machine
(P150/32MB) AFTER the level is lighted and the monsters have been placed.
you can determine the fps in quake and quake2 as well by looking at how many milliseconds a gamecircle takes to complete, 50ms are of course 20fps, for example.
the problem for many ppl who are really into editing is probably that their CPU is a bit above the
average and that levels that run ok for them may be too slow for a normal player. so looking at the
r_speeds becomes important again - i think 600 should be the guideline, 800 is ok, and you can go
even over 800 if there is something cool going on AND the player doesn't have to fight monsters.
-Matthias Worch, Level Designer at Ritual Entertainment
"...the first thing that you have to keep in mind is that
you should never give up visual impact for speed. You may have to
rework your ideas to have both, but visual impact is just as important
as speed. As with all things, there are a couple tricks and tips that
can really be lifesavers when it comes to this.
1. Let the textures do the work. This may sound obvious, but a lot
of people ignore this. If you are looking to make a super complex
level, try and figure out things that could be pulled off with textures
instead of architecture. You should also take care not to have too many
textures as that will really slow things down on an accelerated map due
to memory constraints on the cards. Not usually a problem, but
something that should be kept in mind anyway. Look to Quake II for some
beautiful textures that really helped to make the world come alive.
Good lighting will also help out incredibly when it comes to visual
impact.
2. Think before you make. This is pretty damn important. You need
to make sure that what you are working on won't be too expensive.
Sounds pretty obvious and stupid, right? Here's what I mean. Make sure
that you keep in mind what the game is going to be rendering at every
given area in your map. Just because something is around a corner or
behind you does not mean that it won't be rendered. The game has to
consider everything that has the possibility of being rendered. To make
it short, try to think up different ways to break up the visibility
check. Bent hallways and differences in heights (floors above floors)
are very good at doing this. Try to keep rooms and hallways from being
in straight lines, that way, it won't have to render as much.
3. Finally, the question of r_speeds. It all comes down to what
you want your minimum machine to be and what sort of map you are trying
to portray. If you want a fast map on even a slower machine (like a
P90) then you should aim low... say 250 to 350. If you want to push it,
then try for something around 350 to 450. Again, this is something that
you need to experiment with. You also need to take into account how
many monsters you want to have in a room. They will eat up processor
time too. Try to make your level never drop below 10 frames per second
on your slowest machine.
-Eric Biessman, Level Designer at Raven Software and Prime Minister!?!
"o figure out what your optimum speed should be the first thing you do
is get a machine that runs at your baseline audience's speed, say an
Intel P166. Then, you make a decision as to what the lowest acceptable
framerate should be, say 15fps minimum. Make a map with areas that have
lots of polygon faces and make sure you have "R_SPEEDS 1" set so you can
see the number of polys you're drawing. When your framerate drops down
to 15fps (you can tell by using TIMEREFRESH), look at the amount of
polys you have on the screen at that point and that is your "maximum
visible polys" setting. Make sure that no scene in your map goes over
that amount unless it's a very special area that won't see too much
action.
The resulting "magic number" is definitely going to be a frustrating
limit to design toward, but you must make sure that you adhere to it.
The best way to get a better looking scene with a low number of polygons
is to increase your texture complexity to make it appear to have more
structure. Instead of having a plain concrete texture on a wall, make a
concrete texture with support drawn in. This works wonders on walls
that the player will never be able to reach but looks cheesy close up
although in some instances the art can look rather good close up but
it's rare."
-John Romero, Game Designer, Chairman & CEO of Ion Storm
"...it's always a tough call and the dreaded Dragon of Framerate ALWAYS wins!
I often rip out alot of cool visual stuff at the end of a level's
development. It hurts, but it has to be done. Alot of time is spent on
balancing eye candy such that often three brushes can in fact flesh out a
mountainside when first thoughts were it would talk a dozen. Any view must
run at 15-20 frames per second. The human eye sees at about 24 fps, BTW. In
a month or so, the June issue of Computer Gaming World will have a very cool
article on framerate-related topics like Minimalism, Ikebana (Japanese Flower
Arranging), Occlusion, and the Parallax Phenomenon."
-Richard 'Levelord' Gray, Level Designer at Ritual Entertainment
"There are several different strategies I take when when dealing with framerate
vs. cool architecture. First, keep in mind that more polygons doesn't
necessarily mean an area is going to look better. Having good textures and
lighting on top of simple geometry can go a lot further than you may think.
Let the textures add the detail to the scene as much as possible in order to
extend your polygon budget.
Second, when designing for BSP-based tech (i.e. Quake/Quake2) keep in mind
that the BSP can really cut apart a level and unnecessarily increase the
number of polys in a scene. Find the sections of geometry that may be causing
problems and rework those. I sometimes will manually put in my own cuts in
order to deter the BSP from going too crazy in some places. Also be very
careful of CSG operations. CSG can be a real time-saver, but cutting
complicated shapes out of brushes can really start to add to you poly counts.
Finally, take into account everything that will be happening in the area
you're working on. For single-player maps, if you plan on very little action
and only a few or no enemies in an area, you can probably get away with a few
more polys. In places with more action and enemies, though, make sure you
stick to your budget, because you don't want the game to slow down when the
player is in the heat of battle. For multi-player maps, always assume that
the maximum number of guys can be in any area at any time, so the number of
polys in the geometry is very critical.
As far as benchmarks go, when doing Quake maps I always used the r_speeds,
r_draworder, and r_drawflat commands. R_speeds for checking framerate and
poly counts, r_draworder for visibility, and r_drawflat to see where the BSP
may be cutting things up too much. I haven't really done any Q2 editing, but
I'm sure there are equivalent commands to help you get benchmarks.
-Rob Heironimus, Chief Game Architect at Rebel Boat Rocker, Inc
Note: Answers are in the order I received them. I would also like to thank each individual that took the time to share their knowledge.