In the Trenches #4:

Room Building: A 13-Step Program

by Laurel Stuart
February 22, 2002

In my last article, I talked about the basic attributes of a Skotos room. I am now going to discuss a method of orchestrating everything together to Build rooms. When I first started, I was very overwhelmed by the apparent complexity of a room inside the Dev Interface. Since I was overwhelmed, I procrastinated and turned to other aspects of designing my game. Forcing myself back on track, however, I created an easy method for designing rooms. This twelve step process enables me to create interesting, well-structured rooms on a consistent basis. Its not the only way to Build rooms and other objects, but it has worked well for me so far.

Step 1: Create Your Game Setting

The first step in room construction is to look at the bigger picture. You need to develop a general geographical setting that will be large enough to sustain game play, but with definitive borders. Devils Cay, being a small island, is conveniently surrounded by the ocean. Research led to me to create a fictional resort and decide to center initial game play there, leaving a large portion of the island undeveloped at the onset so that I could slowly expand my borders if and when the player base was large enough to support additional rooms.

Step 2: Create Your Logical Map

The real work began with the creation of a logical map. A logical map is a diagram containing a series of squares, one for each room, connected by straight lines to demonstrate the logical connections between rooms. Each square is the same size and contains the name of the room. For an example of a logical map, you can refer to Building Blocks: Maps http://www.skotos.net/articles/TTnT_53.shtml. My first logical map was fairly ambitious, with a large number of rooms based on a compilation of actual floor plans from several Bahamas resorts. Later, I downsized and removed all of the rooms I felt could simply be assumed to exist and that were not really essential to the game.

I constantly use the logical map for reference when writing room descriptions. For my own convenience, I include a compass containing all eight directional points in the corner on my personal printed copy of the logical map. I've also taken the time to name my exits and note the related sight lines for each room on this copy.

Step 3: Name Your Rooms

Technically, you have at least a working list of names as part of your logical map. Now is the time, however, to really analyze them and decide if they serve your building needs. Each room, for example, needs it own unique name even if it represents a type of area that might exist in higher multiples in the setting. There are six important things to remember regarding room names.

A. Room Name Should Be Simple

Keep the room name limited to a primary noun enhanced with an adjective or two at most. More elaborate Views (look, examine) provide ample opportunity describe a room.

B. Room Names Should Be Practical

Unlike some other objects, most rooms are named for either their purpose or their primary element. Unless you are deliberately creating a comical game, you'll want to avoid names that will provoke guwaffs whenever players read them or when characters mention them during poses.

C. Room Names Should Fit Setting

A game set in a mystical castle isn't going to use the exact same room names as a Mars colony. A little research into terms for objects that suit game setting and genre will delight players and help them to enjoy the game more.

C. Avoid Possessives

Don't use names like "Joy's Bedroom". Keep to names like the "Northern Gate" or "Small Boudoir" instead.

D. Avoid Prepositions

As with possessives, the Skotos parser isn't designed to incorporate prepositions into names. So skip names like "Shower with Curtain".

E. Avoid Cardinal and Ordinal numbers

Don't include numbers like "First" or "one" in your room name.

Step 4: Pick A Room To Build

Once you have your map and have decided on the right primary room names, its time to choose a room to start building. I've found that I do well when I assign myself just one room to work on each day, but commit to completing at least a draft of said room, no matter what circumstances life throws my way. The keyword here is "draft". The more I practice at room building, the more adept I become at it. I can already tell that I will need to go back and heavily revise the first couple of rooms I created to change certain details and add in features or protocols that I forgot. Since StoryBuilding is a unique craft, it's expected that beginning Builders will improve over time. A little Building every day goes so much further than working zealously for two weeks and then burning out and never finishing the project. Your game may very will be a time-energy investment of a year of your life simply to get it from proposal to launch.

Step 5: Create Basic Room Views

The first time I read the StoryBuilder's Toolkit, I thought that writing room views was a substantial extent of the text descriptions I would be writing. Little did I know that Views are really only the tip of the iceberg and the launching point in room design, because each View describes attributes that might require additional Views specifically for them. For example, a player should be able to look at a room and see a sculpture and then look at the sculpture to be provided with further description.

Another Storybuilder advised to start room views by writing the Look View first. After some practice, I agree. In three or four sentences, you need to touch upon the room's primary elements, including the exits. These elements will probably become the first details- those unique, non-portable room elements that require additional description-writing.

My technique for writing a rough draft of a Look room view is to pretend that I'm standing in the center of the room, facing north and I slowly turn in a full circle, describing the most obvious element in each direction including the four corners. If there is an exit, I make that the most important element. After I've created this rough draft, I re-write my description to make it more aesthetically pleasing and coherent. This description becomes my prime detail, which is what players will read by default when they "Look" at the room.

Once I'm satisfied with my Look View, I create the Brief, Glance, and Examine versions by respectively subtracting and adding to the amount of information provided regarding what exists in the room.

Step 6: Create List of Details

A room detail is a discrete, non-portable element. I find that its easiest to write my prime detail and then create a list based upon it of each unique item or unique group of items found in the room. I pick out the most important details, giving each a simple, distinguishing name and then writing a Look View for each of them. Every time a description creates new important details, I add it to the bottom of my list. I call this list a Visual Outline. I also note important portable objects that can be found in a room in my Visual Outline, but save any description writing about those for after completing my details.

Step by step, I go through and write 2-4 sentence long descriptions, until I feel that all of the important non-portable elements for the room are listed as details and all the details have descriptions. I ensure that my exits and sight lines are included as details in the Visual Outline. (which is why I note them on my map; otherwise I tend to forget them). I also include a description of the floor.

How many details should a room have? That depends completely on the room's complexity. Michael Blum designed the bungalow prototype for Devils Cay. This room contains eighteen details including Views established in a trinary day cycle (which I'll discuss in my next article). This one room contains a total of approximately 125 descriptions varying in length from one sentence to one paragraph. It serves as the model for the average level of detail I want the rooms in my game to have.

Step 7: Note Names Found In Each Detail

Details can have more than one name and usually do. These names are composed of the nouns used in the detail's View description. Usually each name is either a synonym or represents a particular outstanding element of the detail. Make a list of all the names you used for your detail within your Views. Include its singular and plural forms.

Step 8: Note Adjectives in Each Detail

Make a list of all the adjectives you used in your View. A three-sentence description might easily have 8-12 adjectives.

Step 9: Note Prepositions for Detail

There are currently nine important prepositions to account for when it comes to Details and the parser. They are: against, before (in front of), behind, beside (next to) close (close to, close by), inside (in, within), on (upon, on top of), over (above), and under (beneath, below). The parser needs to know if and how other objects (like characters or items) can locate themselves or be located in comparison with the object. For example, let's say that one of the details for a given room is the floor. Its possible for a PC or a portable item to be on the floor, close to the floor, near the floor, but geographically speaking nothing within the room itself is going to be under the floor or inside it. At some time in the future, when I'm more experienced at Skotos object-spatial relationships myself, I'll write an article specifically on choosing prepositions for different types of details.

Step 10: Rewrite Views and Spell Check

Once I have completed my entire Visual Outline, making sure all my details are accounted for, and each detail has the right Views, Names, Adjectives, and Prepositions, I read over everything. I make any changes and additions. If I've done all of this on paper rather than a word processing program (depends on when and where I've been writing), I type everything into a text file and spell check. Once I'm satisfied with what I've written, it's time to access the Interface and engineer the room.

Step 11: Input Information into Interface

I won't go into detail regarding the GUI or S7 Interface today. For now, I'm simply going to say that I take my Visual Outline and detail by detail, including the Views, Names, Adjectives, and Prepositions for each one, input everything into the Interface. This takes much less time than the writing itself. It is possible to open up the Interface and try and create everything "from scratch", but I don't recommend that for beginning Builders. I did the "scratch" method for the first couple of rooms I built and need to revise each and every one because my initial Building lacked essential components mentioned above. There's too much to remember, too many variables and blocks of text to account for. Preparing a complete Visual Outline of a room before approaching the Dev Interface ends up saving me enormous time and frustration.

Following the 12 Step Room Building process not only caused my description writing to become more coherent, but made the entire process suddenly more comprehensible to me. I can say that I'm really beginning to feel confident with creating elementary objects such as rooms.

Step 12: Get A Second Opinion

After you have inputted all the relevant information into the Interface, you have essentially built your room. Before you break out the champagne bottle, however, have a friendly Skotos crew member or another StoryBuilder glance over the room with you. They might have some valuable suggestions.

In many ways, being a beginning StoryBuilder is like being an apprentice in a Guild. You have a lot to learn. Some of it just takes practice and learning through trial and error. A friendly and patient mentor, however, can help a student along at a phenomenal rate. One of the best ways to learn how to design good rooms is to study the work of other StoryBuilders.

Step 13: Start The Next Room

Once I've made any changes to my initial room thanks to co-StoryBuilder feedback, its time to start the next room. Following the momentum, and launching into new rooms after a good night's sleep, is an excellent way to ensure that you do not procrastinate and lose interest in the Building process.

Final Notes

A good starting Chat Theatre has 20-30 rooms with the potential for some limited growth at a later date. My advice is to plan on investing the first month of StoryBuilding to nothing but rooms. Account for other pursuits such as school, work and family and organize at least two hours a day or 14-15 hours a week where you can focus solely on Building. If two or more people are co-creating a Chat Theatre together and each builds only a portion of the rooms, the process can go much faster or be done with a smaller investment of time and energy. I think most of the S7 folks, self included, made the mistake of underestimating the role of room construction as the first fundamental step in StoryBuilding. In hindsight, I think it cannot be over-emphasized that constructing rooms is really the best starting place for StoryBuilders. Save other concerns such as system mechanics and plot until after Building is done.

My next article is going to discuss useful tricks for thinking up room details and include advanced detail elements such as dark-dim-bright cycles and variable description creation. It will conclude my articles on general Room Building and I will move into discussing door and exit design.