Map Design Standards
Here we discuss some of the best practices and common mistakes made when designing maps. This page doesn't really contain any "standard" per-say, but rather is a collection of advice and recommendations to help designers produce the best maps that they can.
- Use landmarks and features to distinguish areas of a map.
When creating a large dungeon, it is easy for multiple sections of the map to look very similar. This can cause confusion on the part of the player, as they try to figure out what section of a map that they are end. This situation can be mitigated by adding numerous "landmarks" and other features on the map that are unique enough that they can not be confused with other areas of the map. For example, try adding a large pile of rocks in a cave, or a fallen tree in a forest.
- Prefer using map tiles to represent something over a map object.
If you have a non-moving object on the map, such as a tree, you should always prefer creating it as a series of map tiles over creating a new map object if feasible. The reason for this is that every object on the map is an additional object that sprites have to perform collision detection with, so having a large number of objects on a map can cause performance to take a hit. Sometimes an object may be contained within a tileset image, so look around to see if that is the case. You may also choose to add the object to a tileset yourself.
If the object is not available in any tileset art and it would be cumbersome or unnecessary to add it to a tileset image, another trick that you can do is to turn off the object's collision property, which will cause the game to ignore it when sprites are performing collision calculations. Instead, you can override the collision grid at the appropriate area where the object is placed so that sprites can not move on this space.
- Don't make maps larger than they need to be.
One common mistake is the assumption that bigger maps are better. This is certainly not the case. Creating a map that is too large can cause the player to feel lost and frustrated if it takes too long to explore a map. This is especially true for "friendly" areas such as villages and cities.
- Don't make buildings too large in an effort for them to be "realistic".
Another error is to make buildings excessively large, or think that they need to include numerous miscellaneous rooms such as a bathroom. For most common structures such as homes, shops, and so on, the interior of the building shouldn't require to be much larger than one full screen (16x12 tiles). Indeed, many can be much smaller than that. Remember that the end goal is to make the game more fun, not more realistic. Small structures are a staple in classic RPG games and in a medieval setting like Allacrost, small structures make sense as well. If you are finding a lot of "empty space" in your structures after filling in furniture and other objects, you may want to consider resizing the structure.
Of course, there are exceptions to this rule and some structures will necessarily be excessively large, such as castle halls or mansions.
- Using the same map context for two or more areas that may be on the map screen simultaneously.
For maps with structures, one might think to create two map contexts: one for the outside, and one for all structure interiors. The problem with this is that if all structure interiors share the same context, then the player will be able to see inside a different structure than the one that they are in if the two structures are close together. This is incorrect design. The solution to this problem is to use more than just a single context for building interiors. There are a total of 32 contexts available, which should be more than enough to satisfy most maps. The easiest way to solve this problem is to use one context for each interior, to ensure that the spaces will not overlap with one another.
At the same time, however, it may be the case that we do not want to use a unique context for each building interior, as there may be more interior spaces than contexts are available. An easy trick around this is to reuse some contexts for multiple interiors, but only use the same context for two interiors if they are widely spaced apart. This way, you can alternate which contexts you use for each building, keeping a lower context count while still avoiding the issue.