Welcome back to another entry within this series. Let’s just jump right into it. As with any form of game development, we would need documentation to keep track of concepts, current work in progress, what is needed, etc. At the moment, you already created a piece of documentation - the papermap. This will help you envision your project and give you a reference for how you want your map to look like in the end. However, we need more. Now, we have to create the design document: This document is one of the most important things that you would have for your map. It outlines the theme of the map, the assets that the map will use, and an idea on how the map will be completed. Due to the flexibility of the design document and the project at hand, you can say that you can not fully complete a design document. However, to get a document that is useful for development, you should flesh out the following pieces of it.
- Number of Players (subjective): The intended amount of people that can play on this map at a single given time.
- Engine Being Used: It is the engine that you will be doing most of your production on.
- Concept: What you are trying to aim for with the map and what you want the player to experience.
- Objective: The overall goal that the player will need to achieve to beat the map. There can be multiple objectives, but make sure to make the main objective as fleshed out as possible. See how the other objectives help or lead the player in beating the main objectives.
- Tools used within the level: Basically, what items and interactables that are available within the entirety of the map.
- Asset List: The items that you, as the developer, would need to create to build the entirety of the map. When we say assets, we mean things such as textures, whiteboxes, particles, items, character/enemy models, etc. Think of it like this - every individual piece that makes up the physical level is an asset.
- Function List: Scripts or any sort of code that you will be making
- Map Size: Just how big your map will be in the possible final build. Try to use some sort of unit of measurement that is easy for you to use as a reference while sculpting out the map within the editor.
- Story Placement: Some games do have some sort of single-player mode or story mode that you can play through. The maps that you will play through will change in some way during different parts of the story. Some assets might be present/not present during certain parts and some mechanics might be present within only certain parts of that story as well. If you want your map to make sense within the context of the games' story/if you are trying to develop a map for the main campaign, you have to indicate where this map will appear within the main story. Make sure to use visuals from previously created maps to capture how that map should look at that part of the story. Doing all of this helps make your map much more consistent and believable to the player, which helps with the immersion.
- Audio Effects List: Similar to the Asset and Function Lists - you’re just going to outline what kind of sounds that will be present on your map, where those sounds will be played, and under what circumstances.
- Walkthrough: A step by step instructional on how to 100% complete your map ( get all the collectibles, reach certain parts of the stage, defeating certain enemies, etc). While you can publish the walkthrough and allow players to follow it to help them get through the map, this is more so for you, as the developer, to use as a reference for understanding the flow of your map and where certain events will occur. It also will help in the creation of your pacing chart, which you will use in tandem with the walkthrough section of your documentation to balance out your map so that it makes sense gameplay-wise.
- Pacing chart: The pacing chart is a numeric chart that quantifies how hard a part of a map is compared to the other parts. As said before, this would be used in tandem with the walkthrough section of your map so that you can go back and balance the gameplay so that some parts are not too hard or too easy. I feel like the pacing of the map should grow in the shape of a hill - difficulty starts very low, but gradually gets harder as time goes on. It will then reach an apex - or the highest difficulty of the map - and then it will start declining in difficulty until it is easy again. This helps build up the player so that they can grow and be prepared for the challenges that they face.
- Milestone log: This log helps with separating the tasks that need to be completed before a certain date. It helps with keeping everyone on track, and ensuring that a product is made by a certain date. This is not necessary if you are an independent developer just doing this for fun or on his or her own time, but it is vital when you are in a professional setting and trying to get a product out to a stakeholder. To create a milestone log, create tasks that will help you develop pieces of your map. Then create a set of time windows ( It could be a week, a month, or a year. But make sure you get solid dates down for these time windows), and then place these tasks into those specific windows. If it seems like these tasks are too much to handle within a window or if a task needs to be completed before another task can be completed, organize them in another window. You’re just creating a list of things to do, and giving yourself a deadline to complete them all.
If you want an idea on how a design document should look, check out the design document that I made for my Portal 2 map.
If you want an idea on how a pacing map should look, check out the pacing map for my portal 2 map as well!
That’s pretty much it for this week! Next week, we’re going to jump straight into Hammer and start developing something great. Until then, be well!
UAT offers the following Gaming Degrees; Game Art and Animation, Game Design, Game Production and Game Programming