The Purpose of this Documentation

In preparation for creating 10-20 levels for a third person co-op shooter / exploration game, I was tasked with creating a specification for a tool that would aid in creating levels.

Acting as the level designer, I would need to build all of the features necessary to create levels with all the features listed in the overall design doc, and enable myself to create them in a timely manner, while being conscious of not using developer time to develop any unnecessary features or any features that would cause an undue burden on the team.

My Process for Creating this Document

Writing out all required features

Listing out required features per object

First I examined each object type individually from the documentation. By going through each object and writing what features I may need upon placement, as well as features that were required for multiple object types and general usage, I came up with this list of features:

Randomized X, Y Z Rotations: The game contained many miscellaneous objects such as rocks and debris. If these objects were randomly rotated when placed, it would make the levels look more natural. In addition, some objects such as trees and buildings would be standing upright, so the Y rotation must remain consistent while the X and Z are free to be randomized.

Y value: Set or Normal with Terrain: Some objects such as trees and buildings would need to stand upright on terrain, while others should be able to be placed at set Y values.

Brush tool; Placing Multiple Objects: To create levels quickly, there should be functionality to place multiple objects at once - for decorative objects and barriers like trees. With options for random distributions (for natural looking debris) or uniform (for more ordered objects like industrial equipment.)

Basic Features: Enter/Exit, Undo, Object Previews: Tool should contain basic features - a means to enter and exit the tool, A means to quickly undo misplacements, and a preview of how objects will look before placement. These features would allow me as a level designer to more easily and quickly create levels.

Object configurations: Some objects like storage and vending machines require configuration by the level designer. They can be in different states and have different contents - while also having a ‘random’ setting. Some objects also had collections that the level designer should be able to add them to on placement, such as lights connected to a circuit.

Automatic Object Hierarchy: As a level designer, it would be a helpful tool to be able to quickly select and see all objects of a certain type. For this, objects would have to be added to a hierarchy on placement, with all objects of a certain type connected to a ‘master’ object.

Starting with an Overview

I started with an Overview, and listed a quick summary of all of these required features. This would help the developer quickly understand what was required, as well as organize my own thoughts, and help to format the other parts of the document.

Illustrating General Usage

I continued by illustrating the basic functionality of placing an object, sparing no detail.

Listing out all required Attributes - Contextual and Non-contextual

Using my list for features above, I listed out all of the required attributes in specific detail, without telling them exactly how to implement them. This can hopefully serve as a blueprint for the code for the tool. and give a comprehensive overview of the functional ask for the developers.

In addition, I covered the object configurations - naming it Contextual Attributes, and organizing it by object type.

Object Hierarchy Suggestion -Stepping into Systems Design

Finally, with the space left, I created a suggestion for a potential object hierarchy that will help me as a level designer - knowing that this is a question which steps into System Design, and should be brought up with the relevant team in the project.

Revisions to the Document

Organization

Initially, the document was mostly a list of features by object type. However this didn’t serve to adequately communicate how the tool was meant to be used, and also assumed some basic things (such as the tool would be used in the unity editor with the mouse) - it was reorganized into the format above.

Removing Prescriptive Language

Some initial drafts had specific language that implied a certain implementation:

  • Pressing ESCAPE will exit the tool…

  • A copy of the object will be attached to the mouse…

  • These attributes will become visible when…

Removing these kinds of statements which imply a certain implementation will allow the developers to develop the tools in a way that makes the most sense and without wasting developer time; for example an exact copy is not needed to follow the mouse, just some sort of visual indicator of the object to allow the level designer to see what it looks like before placement.