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.
The stylized U, Unreal(tm) textures, images, and other graphics Copyright © Epic MegaGames All Rights Reserved. All Original Content and Compilations are Copyright © 1998-1999 Necrotic Software Inc.