topnav

Series Info...Storms on Cloud Nine #2:

The Rock Test

by Scott Holliday
January 24, 2003

Last time, I introduced myself and Orphan Crown. At this point, I think it's fair to start talking about more general topics in online game design. I was thinking of branching directly into influencing good player interactions, but decided to instead focus first on the basic of basics... the rock test.

Here I have to give credit to one of the members of the Orphan Crown team, Bob Strawn. I originally learned the rock test from him while we were discussing play mechanics for tabletop RPG systems. The rock test concerns design philosophy of any kind, although the metaphor is related to building paper airplanes. It goes something like this:

  1. Obtain two pieces of paper
  2. With first, build a paper airplane
  3. With second, wad it up into a ball (the "rock")
  4. Throw the airplane
  5. Throw the rock
  6. Compare
The idea here: if your airplane doesn't fly better than the rock, you should kick yourself. Of course "better" has many qualifiers. Some airplanes do flips. Some spin. Some dip up and down. Some glide at leisure for long distances. Some are just pretty. However, rocks are quick and very easy to make. If your airplane failed the rock test, you should probably rethink the design.

I'm assuming that at least part of my audience is either building a game or hoping to do so in the future. As I build Orphan Crown, one of my constant questions has become, "is this better than a rock?" Since it's a text-based game, my rock for comparison could be a simple chat room with no mechanics. However, I could also consider any of the MUDs that came before or even the previous Skotos games. At some point, I'm talking about big expectations. But unless I plan to exceed the quality of what came before, what's the point?

How do I compare? All I have is my ideas, maps, charts, notes on paper, and some preliminary code. Thinking about the airplane metaphor, I need to test the flight pattern before the paper is even folded. Well, to be totally frank, I can't. The game is designed to have enough simultaneous players (variables) that there is no way to tell how it will come across. So, I have to simplify the question and take it one piece at a time.

One method is to look at each game system individually. Story items, puzzles, quests, crafting, economics, market-interaction, housing, food, the list goes on. Each system is scrutinized by itself. Sometimes I compare to other games I've played. Sometimes I compare to other mechanics that I've made in the past.

Another method is to try it out from the point of view of a player. So, I sit down and write a day in the life of myself as a future Skotos gamer. I watch as my imaginary self logs in...

(log in blarg) ... Welcome to Orphan Crown
You are at the Alley of the Renderers.
>examine here
You see nothing unusual about of Alley of the Renderers.
At this location you may shop_[buy/price/retrieve/sell] or task_[build/teach/work].
>shopbuy
Syntax: shopbuy [item] [quality] ['#]
At this location, you may buy: candle oil soap wax
>shopbuy candle good
Qualities: common normal professional adept expert master dream
>shopbuy candle normal
You may buy:
1: Candle (normal) : 3 coins
2: Candle (normal) : 4 coins
3: Candle (normal) : 4 coins
4: Candle (normal) : 5 coins
5: Candle (normal) : 5 coins
>shopbuy '1
You have purchased a candle for 3 coins.

And so on... I've got a notebook full of this stuff with notes on the side for changes I want to make.

What does it prove? Actually, quite a lot. By reading through it, I can make an early assessment of the intrinsic entertainment value in the various game systems. Equally important, it helps me plan how new player commands/functions would be the most intuitive/exciting and the least annoying. For instance, the bit above quickly proved that the market interface needs something to spice it up. Haven't figured out what yet...

In addition, by purposefully testing the design with several different play-styles, I quickly discover the areas that need more planning. For instance, what if I was in the mood to socialize today? What if I'm a loner and want to mess around with some of the puzzles by myself? What if I just want some combat excitement?

I'm sure every game developer has done this same process, though perhaps not using the same philosophy. From my experience, doing an imaginary run-through as soon as possible (using the rock test) is important. If you find issues or elements that need to be changed, earlier is obviously better. Even if everything works perfectly (and it won't), it will help to solidify your vision of the game and help you get started on the next step. This seems perhaps a bit too basic, but maybe it will encourage those of you who want to build a game someday but don't know where to start. For my own part, when I was writing up the proposal for Orphan Crown, I did a LOT of this on paper. I highly recommend it no matter where (or what) you are designing.

Next time, I plan to talk about "winning" and how it effects the dynamics of an online RPG.

Recent Discussions on Storms on Cloud 9:

jump new