Mapmaking 101 – First and Last
Design and Documentation
The first and last steps of scenario design.
When looking at the scenario design process for any game, whether it be Stronghold, Age of Kings, Empire Earth, or any game that will come out in the foreseeable future, the process of design can be broken down into three overly simplified steps:
The only one of these steps that really needs to be specialized for the game is the actual process of Creating as each game has a different scenario editor. In this article, though, we will look at the first and the last steps, which are rather intertwined with each other.
For the purpose of this article, planning will refer to anything that happens before you first open the editor and circulating will refer to anything that happens after you are satisfied with the final product and are ready to zip it up and send it on to Stronghold Heaven.
As was hinted at in the opening, it is important to realize that one of the most significant parts of design takes place before the first unit is placed, the first terrain is altered, or the first building is placed on the blank map. For, if you open the editor without a specific plan in mind, the final product you submit will reflect your lack of preparation.
The first question, at least when designing in Stronghold, is exactly what type of scenario you are looking to create. The six obvious choices are:
2) Siege That
6) Free Build
However, there is another choice that is not as immediately obvious as it is not one of the decisions the game asks you to make. The question is whether you want your scenario to be purely historic, to be based on a historic setting, or to be fictional in both storyline and location. This decision will impact the amount of planning that has to go into a scenario as we will soon see.
For the remainder of this article, we will not concern ourselves with a Siege That map, as many of the design decisions and the design process that goes into a Siege That map is a result of the terrain that is dealt to the designer. However, a Siege That map can be affected by the documentation that is presented with it and any other map type decision needs a varying amount of pre-planning.
One of the most obvious tidbits of design information that should be passed along for any game that has a historic background is this: if you are planning to label a scenario or a map as having a historical basis, much of your potential audience will want to see some evidence of historic research.
Really, that one tip cannot be overemphasized. Especially in a game that has a rather intellectual fan base, such as Stronghold, a map that claims to be historical, but shows no evidence of research or accuracy, will be found out and will be marked down in any reviews that may be written for it.
In addition to historically accurate occurrences that are a must in most games, Stronghold adds an interesting additional caveat and an interesting additional freedom. Because the central theme of the game is the building of castles, the design of the castle itself should, as much as possible, be accurate to the real life design of the castle. Additionally, many castles evolved over their history and the more advanced designer may even pick a particular point in the castle’s development to represent in the map.
Fortunately, it is possible to find online historical preservation sites that have indexes of castles from all over the Old World, many with floorplans that can be extrapolated upon, or even just photographs from which an external design can be roughed out.
Another resource is available for the more fortunate designer who is either living in, or just planning to visit, Europe. Nothing can beat ones own experience of visiting a castle to provide information for a siege or invasion map. In addition, maps with personal experience may look at a castle that is not as well known or about which the designer can provide much more intimate detail.
Whatever your source of historic information, make sure you have all of your information ready and on hand when designing, or else you will find yourself interrupted by having to redo some research. Also don’t forget that a map is more than just the buildings, it’s the terrain as well which, when possible, should also be, at least roughly, true to life, since many castles were specifically built to capitalize on strategic points in the terrain.
Do not be overly casual in your research if you wish to make a historic map.
Planning any map
No matter the type of map that you, as a designer, are thinking of creating, there are certain design questions that you must tackle. No matter what the map, there needs to be an idea about how the map will look, what the general terrain will be, where buildings will be placed and what buildings will be placed. In addition, for all but siege maps, there will also be the question of where and how many resources will be placed (and in this I include enough valley floor space for hops, wheat and apple production, if such is desired in the scenario), what triggers are desired in the scenario and what the victory conditions will be.
Terrain and buildings can be planned out in advance using whatever method the designer is the most comfortable with. Some will wish to sit down and plot out a map on paper to determine where to place cities, where to place major terrain features and where to place resources. Others may be comfortable planning a map out more generally and mentally. Some may be comfortable with some other modelling method, or just getting into the editor with a rough idea and the thought that the storyline may change as the design comes more into focus.
Plotline is also important especially if you, as the designer, plan to tie several scenarios together into a campaign. A standalone scenario, too, needs enough of a plotline to get the potential downloader interested enough to invest the time needed to download and to play the scenario. Remember that you are trying to justify taking, potentially, several hours of a player’s time on a more complex scenario, or an hour or two for a player to work through a particularily challenging siege.
Another storyline idea that some designers have chosen is to create an entirely imaginary kingdom, and create sieges and scenarios that are slices of the “history.” Being able to tie scenarios together creates a sense of history and can bring in an established fan base if early scenarios in the series are well executed. It should be noted, though, that just because the history is yours, you should not be lax in it, and storylines should not contradict earlier chapters in the canon without just cause.
There are, of course, any number of ideas that can be employed to create a good storyline and I hesitate to dig too deep into the concepts. Not every scenario needs fancy storyline tricks, a massive continuity to fit into, or any historical basis to be a good story. Most players who take the time to rate scenarios will just be looking for some effort and some thought. None will be expecting the great American novel (or insert your own country into the phrase), but all will expect at least something interesting in the storyline.
Certain triggers will need to be planned out, especially any that will drastically affect the play of the game such as invasions, wildlife occurrences, fires, or any resource theft or destruction. Again, this should be planned to the comfort level of the designer and will probably undergo changes as the design moves from rough to finalized stages.
Perhaps the most important decision is that of the victory conditions of a particular map and the justification for these victory conditions. In a map where the general idea is to destroy the enemy castle, ale coverage does not seem to be a condition that would be immediately logical. This is not to say that ale drinking should never be used as a victory condition in a build-and-destroy type map, but a brief description of why ale drinking is relevant to the storyline of the map would be necessary.
Of course all your research, all your justification, all your planning, all your storyline is for naught without proper documentation of the map, which is often the step that finalizes the map making process. It is in this way that the first and last steps of the process are intertwined so importantly.
Documenting and Circulating
There are three basic levels of documentation that designers can take advantage of when creating a scenario. This documentation ties in with the preparation process as it provides a way to impart the story and the proof of research to the players who download your scenario. Remember that any scenario that is being designed for upload to HeavenGames is done for the players and not for the designer.
From this point on, what I impart is preference and suggestion.
Levels of Documentation:
1) In Game Scenario Description
2) HeavenGames Author Description
3) Readme Files
Scenario Description: In Stronghold this can present a difficulty to the designer, as it is the only one of the three levels of documentation that is limited in size. For that reason, choose your words and your decisions of what to cover carefully. Most designers use this for the history of a castle in a siege and a direct introduction to a scenario, setting up the how and
(when possible) the why of the goals. Remember that there is a strong possibility that this is the only documentation that a user will read. It is also important to note that some users will want to avoid all hints, tips or walkthroughs, so this is not the place to include these.
Author Description: Remember that downloading a scenario, siege, freebuild, or any other map from HeavenGames is an investment of time on behalf of your audience. For a user without cable or other high-speed connection, just downloading a Stronghold scenario will take several minutes and playing the game will potentially take hours. The Author Description field at HeavenGames should tell a user why he should download the scenario, or entice the potential user in some way. This can include the text from the Scenario Description, it can include a picture file of the level’s minimap (see
this post in the forums for a list of sites that allow image hosting). Again, tips, hints and walkthroughs should be avoided as some users will want to avoid these.
Readme Files: These files should be included in the zipped file that is submitted to the HeavenGames site. Of all the descriptions, this is the one most open to interpretation. There are many who use this as a type of copyright statement and include instructions for unzipping the file to the proper location. Others may add to this an extended version of a Scenario Description. If you feel so inclined, any hints or tips should be included as a text file within the zip, either at the end of the readme or as a seperate file. They should be included in such a way, though, that the user can avoid anything that might give away the gameplay of the mission.
Back to the index