You are here

Module Mapping 101 - Preparing a Module for Mapping


This article is for those readers who are not familiar with making maps for role-playing games, as well as those who do not yet know how module mapping can be utilized in Neverwinter Nights. Even experienced DMs may find the information presented here can help put NWN module mapping in perspective.

It may still be a few months before the release of NWN, but we have enough information to start planning our modules. You might want to only start with a small map, like a town and the surrounding area, but eventually you will want to include more of your world. It may even be likely that you'll want to map a large portion of a continent, or even the entire world. While this is certainly possible, keep in mind that these maps require a certain amount of computer horsepower to play in, and the bigger your module the longer it will take to build. It may be best to base its size on your story. In a typical module, you might only have the players start in their home town, travel in one direction and visit another town and one or two dungeons, and the lands connecting them. In another module, you can have the players start in their home town again, but travel in another direction to explore a forest, a village and another dungeon. By doing this, you will be using some maps (like the home town) in every module, with slight modifications between modules. You will not need to create all the maps for the entire world at once; a module should only include the maps your players are likely to visit during the time you are playing.

Here are some of the basic concepts we must consider for NWN Area maps:

  • A module is made up of connected Area maps. These Areas are connected by Area transitions which allow a player to leave the map (usually as they reach the map's edge) to arrive on another map.

  • An Area map is made of 10x10-meter tiles of a chosen terrain set (such as urban, dungeon or forest).

  • An Area map's maximum length is 32 tiles, or 320 meters, on any side.

  • When a server runs a module, each active Area map can require up to 10 MB of server RAM, or as little as 2 MB if there are few details (such as scripts, NPCs, triggers, & objects ).

  • As a compiled file for downlaod, a module will be small (possibly 1-5 MB of hard drive space).

Remember that the memory requirement for modules are different for players than for the server running it. The players do not download the module to their hard drive, but instead the server tells the client what the player sees; the client plucks the pieces from the installed game files and reconstructs the server's world right there. The server runs the module and keeps the active areas in RAM (we'll assume an average of 6 MB per Area). The players do not need as much RAM, since they will only see one Area at a time (and thus, for them, only one Area is ever active).

The Grid Method

Let's suppose we want to make a module covering about a square mile of land, including a large castle, a fishing village, and a cave. We have placed terrain that is impassable to the players at the edges of the map so the players can never reach the "edge of the world". There are other, more imaginative ways to do this, but that will be covered in another article. If we map out this entire area with a grid for maximum-sized (320-meter square) Area maps, we might end up with something like the map below:


The advantages to creating a module with maps connected in a grid formation are obvious. Players will be able to visit every square inch of our world. Also, it is easier for them to map it out as they explore. The drawbacks are less obvious. Unless our entire map is populated by interesting events (which is unrealistic and difficult), some Areas will be pretty boring (lots of open land and some trees) and take time to traverse. The biggest downside to this method of mapping is the amount of RAM required. We have 24 Area maps, so it might average (24 x 6) 96 MB, but could require as much as 240 MB! This may be fine if we have 256 MB of RAM, but what if our server only has 128 MB of RAM? We would be able to run this module if we made sure that each area averaged only 6 MB for its memory requirements. To do this we would need to keep the number of details (scripts, NPCs, triggers, objects and other items) to a minimum in some Areas, to counter the need for more of them in other Areas. But this could only magnify the fact that there are large boring areas serving only as "filler" space. This might be avoided with smaller modules, but for larger modules there is a more efficient way to map.

The Flowchart Method

Ideally, very little of your module's maps should be filler space. If we remove the grid from our previous map and take a closer look at our story, we see that things will happen in certain areas and other areas are just filler. In our story, most of the events will occur in the castle, the village, and the cave. We also might have events close to the map's edges, and on the roads and paths connecting them. If we concentrate on mapping only these areas, we might end up with a module map that looks like this:


Now we need only 15 Area maps, and many of them are smaller than the maximum size.

When a player leaves one Area's edge, he appears on the nearest corresponding Area's edge (shown with red lines). In this way, we remove filler space, and less is time spent traveling. Be aware that this method "compresses" time by skipping over irrelevant areas, but time in the game is compressed by nature. Players are involved in a story, where pacing is important. The time spent during the story's events are generally more interesting than the time spent traveling between those events. See "Designing Your First Episodic Campaign" for more about mapping your story.

Even if we were going to run this module without a story, we might use this flowchart method of mapping for the benefits of compressing time. Let's say we wanted to change the scale of our map to cover a much larger area. Using the grid method would prove futile after so many Area maps are added, but with the flowchart method, we can simply increase the virtual distance between Area maps. As DM we can balance this by compressing time and rule that 6, 4, or 2 hours of playing time (or one playing session) equals 24 hours of game-world time. We might even want to have a script in this module that changes the lighting from day to night every few hours.

The total size of this module using the flowchart method could fit into just 9 maximum-sized Areas, and may therefore only require an average of 60 MB of RAM. If we plan on running our module with 128 MB of RAM, we could probably add a few more Area maps, like a dungeon inside the cave, and a hidden grove beyond the impenetrable forest. However, we are not counting the insides of the castle or village buildings – but they would probably only add up to one or two more maximum-sized Areas in terms of RAM..

If we have lots of memory, then we could easily add many more Area maps. With an astounding 640 MB of RAM, we could potentially handle 64 Areas, and perhaps over 100 Areas (assuming we had enough hard drive space). The astute reader may realize that the RAM requirements assumed by this article is based on guesstimates put forth by BioWare long before the game's release. It may be that each area may need less than 2 MB, or more than 10MB if it's very crowded with details. Nonetheless the validity of mapping modules with a flowchart method remains: it requires less RAM to cover more virtual space than possible with the grid method.

The Best of Both Methods

Both the grid and flowchart methods have their strengths and weaknesses concerning module mapping. Area maps in grid formation are particularly suited to towns and dungeons, while the great expanses of the wilderness are best represented with a flowchart formation. In some cases, areas of wilderness may need to be mapped out on a grid; or a very large city may have portions of it mapped out as a flowchart (players rarely need to go on quests to visit every block of every city the enter). We should, of course, use whichever combination of methods in our modules that best fits the situation. In our example module map, since most of the traffic is likely to be on the road, it would probably be best to connect the Areas between the castle and the village with a staggered grid formation, resulting in a module map like the one below:



This map layout would probably run nicely with 96-128 MB of RAM. If we have 256 MB, or limited the amount of detail, we could easily have room to expand on this map, or add an entire underground dungeon with tunnels that could wind for miles. Remember, though, that your very first module doesn't need to be this large. Some of the adventure modules in Neverwinter Nights will use only a few Area maps at a time, since some modules will concentrate more on events which occur together in fewer areas. For example, we might want to start with a smaller version of our module, with just the village and the cave for a short adventure, using perhaps four to six of the Area maps. Later, we can create a new version of our module by adding a few more Area maps, like the castle and fields. By slowly building the size of each successive version, we will soon end up with as large a world as our computer's hard drive and RAM will allow!

Migrate Wizard: 
First Release: 
  • up
  • down