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:
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.
- Obtain two pieces of paper
- With first, build a paper airplane
- With second, wad it up into a ball (the "rock")
- Throw the airplane
- Throw the rock
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.
You see nothing unusual about of Alley of the Renderers.
At this location you may shop_[buy/price/retrieve/sell] or
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
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: