Mapping manual/Pre-mapping stage

Before starting with the basics of mapping, the question to be answered is: what kind of map we're going to make? Is it a deathmatch or team-based one? Does the gametype requires bases? How the map is going to look like? These questions should be answered in the Pre-mapping stage.

What makes a good map?

"Never work oneself to death on just gameplay or just graphics. Only the perfect combination and harmony between each aspect can bring about a good game experience. (...) Things are created to work together - not independent of each other. Therefore, having knowledge of every aspect of level design is a must, even when one's task is to only create the floorplans."
-- Sjoerd "Hourences" De Jong

Consensus about what makes a good map is an endless debate which starts with everyone's perception of what a "good map" is. Don't let the people to fool you that there's only one kind of good maps (most of the time, the answer they may give you is "the competitive maps" or "maps for online play", but this is not always the case).

There is, however, a consensus on the basic requirements a map must have: They must play well, look well, and run well. The three at the same level, in no strict order.

"Whether designing a futuristic environment or a children's virtual playroom, a poorly planned 3D environment sporting unskillfully crafted textures is not going to have the same broad audience appeal as one that is well designed and thought out. Consider a great public building that many people love to visit and always feel good in because its designer has taken into account all potential audiences who will visit and interact with it. The designer of this popular structure did not address only a particular or specialized group of people."
-- Tito Pagán

The level must be playable for humans and bots. The level must be appealing and attractive while running smoothly and being fun to play. Leading on from fun to play, there must be a high degree of connectivity between areas, without losing control of VIS. Maps which only have good gameplay, but bad visuals (regardless of performance) dates a lot and doesn't add anything to the game. Maps which only have good visuals (regardless of performance and gameplay) only serves for flyby or benchmarking, but not for actual playing. Maps with only good performance have no utility at all.

This raises the question: what are good gameplay, good looks and good performance?

Gameplay

In his book, "The Hows and Whys of Level Design", Sjoerd "Hourences" De Jong, a very well known mapper responsible for Unreal Tournament 2004's most played map, DM-Rankin, defined "gameplay" as a whole composed of two parts: the Core Gameplay and the Map Gameplay.

The Core Gameplay is the gameplay provided by the game itself. It provides the essential rules which all the players are bound to, what players can or can't do in the game itself. This is the Q3 gameplay OA aims to preserve. The mapper's job is to adapt the map to the Core Gameplay as well as possible. Some concepts related to the Core Gameplay are the Rules, Chance, Tasks and Goals.

The Map Gameplay gives the player the ability to spawn in a world and use the Core Gameplay. It determines where the weapons are, what the floor plan looks like, and how the Core Gameplay is interpreted.

Good Map Gameplay depends on the kind of map. For competitive-based maps, there shouldn't be any annoyances or random things that get in the way of the players trying to best each other. Fun maps can have these as well, but at least some carefully thought gimmick, trap or something else which makes it stand over anything else. Any gimmick/trap/etc in the map should be countered by another gimmick/trap/etc, so it doesn't become overpowered. This applies to both competitive and non-competitive mapping.

For a deeper look into the Map Gameplay, including map flow, floor plan and different types of layout, check the map gameplay page.

Visuals

Good looking maps have coherent, consistent themes and styles that contribute to the overall visual experience. Washed-up, single-colored maps aren't really attractive. Likewise, a map that combines many different themes tends to detract. The looks of the map must be coherent, consistent, and should enhance the map. This applies to the models, textures, lighting, and even sounds.

One thing that can help you is to study architecture and texture styles. Id Software's Paul Jaquays recommends that you study architecture and texture styles, and that you stick to one architectural style. When designing architectural elements, study the real world. Try to duplicate the look and feel of impressive works, but with less complicated geometry.

Performance

Good performance is about the map being optimized/planned so it runs at a constant frame rate (speed) and doesn't stress the engine too much. Well-optimized maps are able to run on most systems, and it's a requirement for OA3. Mappers should be able to plan their maps with these optimizations in mind. There are tons of techniques for this, most of which are explored in the O+T page.

The limits of the engine

Quake III/OA's engine is extremely basic. Considering the aim of the original game, this was something appropriate, as it allowed mappers to only focus on making multiplayer-based maps. However, more elaborated ideas and features were hard to implement, or directly impossible. Over the time, like the game itself, people found workarounds to these limitations by creatively using the game's entities in different, unintended ways. You can find more info about this on the Appendix B.

Whether people like it or not, the engine is not going to change anytime soon, since this falls outside of the scope of OA, as OpenArena just wouldn't be OpenArena without the Quake III engine. This means that we have to work with what's there.

The planning stage

"Building contractors have a saying that is applicable to mappers as well: "Measure twice, cut once." The idea is that you can save time, effort and materials by planning ahead and visualizing the design before work begins. (...) Mapping is hard work and takes long enough without mistakes and miscalculations that require reworking, or worse, redoing."
-- From the UnrealEd Wiki

Taking inspiration

Ideas for map development can come from different places. The media in general can serve as inspiration for maps, as well as taking a look at other maps, either unofficial or official maps for other games. The OA wiki has an entire page on map ideas. Other source for inspiration can be UnrealEd Wiki's Map Ideas page. See also Texture packs for general applications of OA's textures.

Choosing a gametype

Depending on the layout you've chosen, there are some gametypes which may suit it. Remember that your map doesn't need to be compatible with every gametype. Seldom you may see a layout suitable for not only FFA-based gametypes, but CTF-based as well, and these are more exceptions than the norm. Stick to the gametypes you initially planned for, and only add support for other gametypes if it's possible to do so without making too many layout changes. For this, there's a bunch of questions you might ask yourself:

• Is your FFA map big? Then it may suit Team Deathmatch.
• Is your FFA map small? Then you might bear Tournament in mind.
• Is your FFA map in the middle? Consider adding LMS support.
• Does the map have many recognizable areas? Perhaps you might consider adding support for Team Deathmatch, Elimination or Domination.
• Do you plan to create a classic base-center-base map? Then it's clearly a CTF map, and you might even add support for CTF Elimination and/or Overload if the map is not too short.
• Does your CTF map have an important central area? Consider adding support for One Flag CTF and Harvester.
• Is your CTF map not too big? Consider then adding support for Double Domination.

Due to OA's multiple-gametypes-in-a-single-map nature, you might even be able to do better layout choices by, for example, choosing a main gametype (FFA or CTF) and then some secondary gametypes (TDM/Elm, DD/Elm/Ovl).

Sketching your map

A common and already proven recommendation is to start off with some sketches such as overhead (top-down) or 3D plans, in order to serve as initial guides. Then, make a very rough version of this in the editor of your choosing. Paul Jaquays, from Id Software, recommends that, if you're new to mapping, don't start with big things, better start out with smaller ones. There are many ways to sketch your map, so choose the one which may suit you fine. Some known sketching tools are pencil and paper, drawing/painting applications, cutouts/models, and "frankenmapping" or segmenting layouts. Creating your own rooms as prefabs may help you as well.

Also, in this stage, it's advisable to think about the weapon/item placement and try out locations.

Performance and good mapping

Another thing to bear in mind, at least for the beginner, is the performance. Two things suggested by Cardigan are the value for r_speeds and building with visibility blocking. The cvar r_speeds shows the number of polygons displayed at one time. An acceptable value for r_speeds is 10000 (excluding player models), though in modern systems, values of 15000 do work as well. Building with visibility blocking walls or structures is also advised.

r_speeds, of course, is not the only thing to bear in mind, as well. Transparent or multi-staged shaders also play a role on the map's performance. They cause the polygons to be redrawn with the respective effect added to them, adding an unnecessary strain on the engine. Even worse, each of these shaders add another level of redraw, worsening the situation. But for beginners, r_speeds is an accurate measure to test performance.

Remember to think about everyone who's going to play the game. It's not fun to play with a low amount of FPS.

Botplay should also be taken in account, as mapping with botplay in mind tends to benefit humanplay as well. Also, bear in mind that your maps won't end up in every single server out there, and even if you map for official OA releases, you're required to provide good botplay. Yet, they have some limits. More on the botplay page.

Overall, it's easier to fix errors in the planning stage than it is in more advanced stages.

Adding your own assets

OpenArena comes with a lot of assets (textures, shaders, sounds), however you may wish to add some of your own.

Don't forget the general rule that your assets (bsp, textures, sounds...) should NOT have the same exact "path+name" of stock OpenArena assets. For shaders, this is true for both shader file name and for every single shader contained.
A couple of examples:

• Do you need a modified version of "textures/acc_dm5/mud02.jpg"? You may place your custom version as "textures/mymap/mud02new.jpg".
• Do you need a modified version of "textures/cosmo_block/rock05" shader? You may use a text editor to copy that part of code from OA's "cosmoflash.shader" to a new "mymap.shader" of your creation, rename the shader to "textures/mymap/rock05new" and modify it as you wish.

Do not alter stuff directly inside stock OA .pk3 files. Make a copy of what you need (or create it from scratch) with different path or name, paying attention to do not override stock OA stuff.
Also, it's advisable to do not place in the same path two files which names differ by extension only: it's usually easier to do not specify file extensions in the editor (.jpg, .tga, .wav, ecc.) because the engine automatically searches for supported extensions, and in that case having two files with the same name could be a problem.

If you plan to make a GPL-compatible map (which is recommended to follow the essence of OpenArena, or in case you wish your work to be included in some "official" OpenArena package), don't forget to use GPLv2 compatible stuff only: Public Domain, CC-0, GPLv2+ (no GPLv3 only/GPLv3+). If you don't know the licensing of something you found around the net, you have to consider it as "all rights reserved", so unsuitable for GPL projects. And do not forget to make your assets sources available.

See also: DeveloperFAQ, Mapping manual/Compiling and packaging#Packaging the map, Mapping manual/Appendix F: GPL Compliance.

Bad mapping practices

It's better to know at this point, before you EVER start making a map, that there are some practices that appear to be legit (being available in the editor) but in reality have shown to cause nasty side effects. Here we try to tell you what those nasty techniques are and how to avoid them.

• Avoid the CSG Subtract tool. It generates several small brushes (and phantom brushes) and unnecessary vertexes which don't help in the slightest to the map. If you want to carve a part of one of your brushes, your best bet is to do it manually, via vertex editing and 2D/3D clipping.
• Use the CSG Hollow tool with caution. It generates overlapping at some areas and keeps faces being drawn by the engine even when they aren't seen. This can be manipulated later via vertex editing and 2D/3D clipping, but it's still something to bear in mind.
• When working with patch meshes never use Endcap, Inverted Endcap or Cylinder from the Cap selection menu. The vertexes in these options won't line up well with surrounding brushes and cause sparklies. In all of these cases, it's better to use bevels or inverted bevels. More at the curve manipulation page.
• Never, ever build a box around it to bypass any error. This is often a sign of lazy mapping.
  • For leaks, instead of using this workaround, fix the leak. Use the "pointfile" function from your editor in order to find where your map leaks. Sometimes these leaks are produced by an entity placed outside of the map boundaries by accident, or a very small hole behind a patch mesh or detail brush. Sometimes these leaks are caused by having erroneously selected the sky and then having unintentionally moved it together with some other item.
  • For the level in general, a skybox around the level (unless done in the way provided by the shaders page) increases the polycount and stresses the engine by obligating it to render parts of the map which can't be seen.
• Be careful when using "gametype" and "!gametype" keys, especially when using it with brush-based entities: this may cause real problems to bots. More about it in the gametype support page.
  • Also, test bot behavior when using this key. More about it in the Mapping manual/Bot play page.

Game and editor measures

These measures should be kept in mind when creating maps for the game:

• Average corridors: 192 height, 192 width.
• Wall top and bottom trims: 32 or 64 units high.
• Wall textures: 128 units.

Whichever editor you're using, stick to a grid size of 16 or 32. 8 if you need to do so. Lower grid sizes than 8 are completely inadvisable, as it causes tons of headaches. If something cannot be snapped to the grid, make it detail, so it doesn't screw with VIS calculations. For your initial sketches, Paul Jaquays recommends the 64-size grid.

Beta testing

"To avoid problems later on it is vital to rough out a layout first. This is normally textured, roughly lit and items placed. Then the level is compiled and played. This is known as an alpha build. Problems can be identified and corrected before details have been added and fiddly brush work begun."

--dONKEY

Once you have done everything, it's crucial to release beta versions of your map for testing. There are plenty of places to do so, such as the official OA forum. There's no need to detail the map in the first stages, as you are going to test the layout.

External links

• Cliff Bleszinski's "The Art and Science of Level Design"
• Aeon's Special on Mapping
• Multiplayer Design Guide at IceCreamYou.com

• Gamespy's Best 10 CTF maps - Part 1 - Part 2 - Part 3 - Part 4
• G4TV's 10 most influential FPS maps

<< Previous (Prologue)	Mapping manual	(Map gameplay) Next >>