General
Guidelines
The maps that ship with RealCTF
were designed for balanced gameplay, fast pace, and minimum lag. All received
extensive playtesting. We hope to see many more maps designed for RealCTF
with similar attention to detail.
General guidelines for RealCTF
level design fall into several categories:
Most of these guidelines are
applicable regardless of whether you are designing a map intended for RealDMGame
(Deathmatch) or RealCTFGame
(Capture The Flag).
Poly
Count:
In order for a map to play
well on low-end machines, you must keep the number of polygons in view
at a reasonable
level. Use the "stat fps"
console command in game to see how many polys are in view. A good rule
of thumb is to go for an average of 30 polys in view, with a maximum of
50 in low-traffic areas. Remember that in a firefight these numbers are
going to go up dramatically with players and projectiles flying all over
the place.
In addition to polygons resulting
from map architecture you also have to keep in mind the horsepower required
to display meshes. We tried to keep a maximum of 3 meshes in view at any
one time. This includes all pickups such as weapons, ammo, armor, etc.
If you want a bunch of ammo of a given type in one place consider placing
one ammo of that type and changing its AmmoAmount property.
Map
Size:
Try to ensure that the fastest
path from flag to flag takes around 30 seconds. If you want to make a gigantic
map for
lots of players, consider
using Dynamic
Map Features to expose sections of the map only when a certain number
of
players join.
Textures:
RealCTF ships with a fairly
extensive set of team-oriented textures in RealCTFtxtrs.utx. To help players
orient themselves, keep some team-colored textures in view everywhere in
the map. This is especially important near
playerstarts so that when
a player respawns after death, they know approximately what part of the
map they are in.
Also, try to keep your texture
set to a minimum. The more texture packages you use in a map, the more
time Unreal
has to spend loading and
managing them.
PlayerStarts:
Use RealPlayerStart classes
instead of regular Unreal PlayerStart. RealPlayerStart classes give you
many important additional features such as team ownership, first spawn
vs. subsequent spawn, whether to include in CTF and/or DM, and the ability
to enable/disable based on Dynamic
Map Features. The RealPlayerStart class is described in detail in the
RealCTF
Class Reference.
For CTF maps, it is highly
recommended that you place several team-specific RealPlayerStarts with
bFirstSpawn=True in the same room as the flag. This allows players newly
joining the game to see their own base,
immediately recognize which
team they are on, and get oriented quickly.
Be sure to pay attention
to the direction that your playerstarts face. There's nothing more annoying
than to respawn with your face up against a wall.
The NextPlayerStart
console command can be used to test your playerstarts. I recommend binding
"NextPlayerStart 0"
to one key for testing bSubsequentSpawn
points and binding "NextPlayerStart 1" to another key for testing bFirstSpawn
points. Cycle through each
set as a blue player, then switch to red and do it again. Test with all
the game types you intend your map to be played with (RealDMGame and/or
RealCTFGame). Finally, if you use a RealPlayersTrigger
to
open up parts of the map,
be sure to test with the trigger in both modes.
Pathnodes:
Please make sure to define
basic paths for bots. If you're lucky, this will allow the map to be used
reasonably well in
BotMatch.
From the Unreal
AI section of the Unreal
Technology site: "You can place pathnodes manually, or you can use
PATHS
BUILD LOWOPT from the console
to get a first pass placement done automatically. In any case, you must
do a
PATHS DEFINE from the console
to create the connections between pathnodes." To do this, click the Window
| Log menu item in UnrealEd, scroll to the bottom of the log, and type
the two commands.
Since the demise of Randar's
Bot Page I don't know of any site that goes into Unreal pathnoding
in more depth.
Sky:
Normally in an Unreal map
you would use a CloudZone to make it so that rockets don't explode against
the sky. In
RealCTF maps, use a RealCloudZone
instead; it works better with the Beamer and doesn't kill a player that
happens to bump into it (e.g. by using the repulsor function of the Beamer).
Naming
Conventions:
All maps intended to be played
in CTF mode should have a Real_ prefix on the name. So if you call your
map Foo then
it should be saved as Real_Foo.unr.
This will force your map to appear in the menu when starting up a RealCTFGame.
Maps intended only for Deathmatch
play should be named with a DM prefix just as you would for regular Unreal
Deathmatch (e.g. DMFoo).
What if you have a CTF map which reconfigures itself with Dynamic
Map Features for Deathmatch games? Use the Real_ prefix.
Level
Properties:
To display the Level Properties
in UnrealEd, click the Options menu then click Level Properties (or just
press F6).
There are 3 properties under
LevelInfo you should make sure to set before you ship your map:
-
Author
-
DefaultGameType
-
Title
Feel free to set LevelEnterText
also but don't just set it to say "Foo by mouse" or whatever since that
information is
already displayed when a
player enters your map, based on what's in Author and Title. DefaultGameType
should be set
to one of:
-
Class'RealCTF.RealCTFGame'
-
Class'RealCTF.RealDMGame'
If you fail to set any of these
properties, you will get a Map
Warning. |