Here is a video of the game being played from the perspective of the shooter:



Although I did not have the time to properly finish Jason Rohrer’s methodology, I did go through what I believe is the most distinct part of his game design process: creating a game in a vacuum. While working on Word Cave, I did not even start coding until very late in the process, doing my best to create the game in my head and on paper.

Rohrer makes fantastic games, and his design methodology clearly allows him to do this, but I do not believe it is an accessible one. Had I tested earlier and involved other people in the process, I believe the game would have been better and come together more quickly. One of the most problematic aspects for me was attempting to predict the behaviors of players. While I am sure it can be done well, I had trouble with it. Even when I thought that I had really considered things, I missed some aspects of the game that became immediately obvious once I started playing with a prototype (such as the ability to shuffle the letters, or the fact that it is difficult to plan out words at the top of the screen that are supposed to align with foes at the bottom). Because I have less ability to accurately predict player actions and reactions to the game to such as an accurate degree, it is simpler for me to make early prototypes and play them myself or with others.

One aspect of using Rohrer’s methodology that worked well for me and which I intended to incorporate in the future is the use of math and game theory as a way to test the game prior to making it. Although I was not able to bring game theory proper to bare on this game, running the letter distributions through some analysis resulted in a letter set in the game that I really like the feel of. The only change I made to how the letters are decided once I built the game was to increase the number of available letters from 10 to 11. Examining the game this way made it very easy to see how this part of the game would play out, and saved me from doing a lot of tweaking down the road.

Overall, Rohrer has an interesting and unique way of going about the process of making games, but it is one that I found somewhat cumbersome.

Journal Entry 11 – 4/24/12


Length of Session: 5 hours.

Step in Rohrer’s Methodology: Building the initial game

Tasks: Finishing an initial prototype of the game

Let’s Talk About It:

Last night, I put the finishing touches on the initial prototype of the game. Everything I sketched out in the notebook is implemented in the game with the exception of art, which their simply was not time for.  I’ll be posting a video soon.

By making the game, and just testing it with myself, I was able to see some issues and change them before testing with other people. The biggest of these changes was the addition of a “shuffle” button that the shooter can shoot to rearrange the letters. The lack of the ability to shuffle the letters became very apparent once I tried playing the game for a bit by myself. Shuffling is present in nearly every anagram game, and although I had considered it, I figured that since the letter placement had strategic significance, I couldn’t just let the speller shuffle over and over. The solution is to have it triggered by the shooter so that it costs a bullet. I believe this is the exact sort of thing Rohrer tries to predict when he places himself in the shoes of his players while brainstorming, but I am still having trouble examining all angles when a game only exists in my head.

Beyond this, though, the game plays out almost exactly as I imagined it on paper.

Unfortunately, this is not the end of Rohrer’s methodology. At this point he would test with a small handful of other people (since this is not a hugely complicated game, I doubt it would get the wider testing that Inside A Starfilled Sky did) and see how it feels. In doing this part, I would focus on their reaction and how they play rather than questioning directly in order to intuit how the game could be made better.

At this point, I would also be testing to make sure that the UI of the game is clear and intuitive. I will fully admit that my current prototype has pretty minimal UI, and that when the game gets a skin, it will need to be improved on. Because Rohrer tends to test late in the process, the game would be skinned before I take it to other people to test these things.

I am definitely eager to see how the game plays when it is being used by two people. I suspect it will work well, but I won’t know until it is played.

Journal Entry 10 – 4/23/12

Length of Session: 4 hours.

Step in Rohrer’s Methodology: Building the game

Tasks: Coding the game as I imagined it

Let’s Talk About It:

The game now has nearly every element of the final game. I have been doing some small refining as I go, but I am mostly building it the way I imagined it originally. I even re-integrated the pausing of the game when the stalactites drop because it does help aim and it’s nice to not have the foes moving if there is network latency.

Tonight I intend to make a game over screen that lists some stats for the players and hopefully make some art for the game. The values for the rate of enemy spawning will also need to be adjusted to make the game fun.

This whole thing being due tomorrow, I may have to forgo sounds. Unfortunately, this whole project was really a bit bigger than the time allowed for, which was a mistake on my part.

Also, I have started calling the game “Word Cave.”

The current menu for the game.

The shooter waiting for the speller to enter his IP and start.

Speller entering the IP of the shooter.

The shooter firing at a stalactite that will fall on the foe beneath it.

The speller with three letters selected.

After submit is pressed, the game freezes and the stalactites fall, killing any foes underneath them.

Game Over, man. Game Over

After a period of network inactivity, the player is bumped back to the menu with what is (currently) a really ugly notification.

Journal Entry 9 – 4/20/12


Length of Session: 4 hours.

Step in Rohrer’s Methodology: Prototyping

Tasks: Building out the first version of the game

Let’s Talk About It:

I worked at translating my final sketches into a functional if rough game. I will continue to work on it, but this bare bones version has:

– Networking across 2 iOS devces using OSC
– Stalactites that can be tapped to spell word
– Foes that kill the player
– A control scheme for both players
– Platforming physics for the shooter player

The shooting player can jump around while waiting for the speller to put in the IP address.

The only major part of the game not present in this version is the ability to shoot the stalactites. This is obviously a pretty big part of the game, so the current prototype is not quite representative.

I did find that I already needed to change a few things. My original plan of having only ten stalactites felt sparse, and I needed to work too hard to find words to spell, so I upped it to 11 (which conveniently gave me enough to use it as the keyboard for entering in the IP adress of the other device). I also found that pausing the game to drop the stalactites was awkward. It does not feel weird that they don’t hurt the player, and unless this seems like a bigger issue to me as I continue to make it (in something of a vacuum as far as play testers go, as per Rohrer), I believe I will keep the game moving as the stalactites fall.

Journal Entry 8 – 4/19/12


Length of Session: 2 hours.

Step in Rohrer’s Methodology: Prototyping

Tasks: Start coding the game

Let’s Talk About It:

I started implementing the speller’s view of the game. The app lets the user tap letters and submit words. I found that the letters being upper or lower case makes a big difference to the iOS spell checker, so I had to convert each string to lowercase before doing anything with it.

Journal Entry 7 – 4/18/12


Length of Session: 1 hour.

Step in Rohrer’s Methodology: brainstorming

Tasks: Final sketches of the game before programming

Let’s Talk About It:

Before I sit down to start coding this thing, I wanted to sketch out the two screens pretty much exactly as they would look to somebody playing the game as well as having a go at the look for some of the game elements.

I decided to go with a yeti look for the shoot after all. It just seemed like it’d be more fun.

The game will have 10 stalactites, using the letter distribution from the modified Scrabble set. The shooter will start with 2 bullets and get a bullet for each letter past the first three when the speller spells a word. The shooter starts with 3 health and will be given an extra one when the speller uses 7 or more letters in one word.

Next step: Coding!

Journal Entry 6 – 4/17/12


Length of Session: 1 hour.

Step in Rohrer’s Methodology: ???

Tasks: Testing Spell Checking on the iPhone

Let’s Talk About It:

My game depends on checking the spelling of words entered by the player, but I’ve never done that before, so I wanted to make sure I could. I figured that the iPhone had a built in framework for doing this, but I wasn’t sure how to use it or if it could interface with openFrameworks. Luckily, it was not too terrible to set up, and with a tiny bit of hack-iness I made an OF function that would return true when I entered a word that the phone knew.

As you can see in the output above, it does consider proper nouns & common acronyms to be words. It will also count any words the user has taught their iPhone. I’m going to see if I can limit it to the standard English dictionary, but I’m not too worried if I can’t.

Journal Entry 5 – 4/17/12


Length of Session: 1.5 hours.

Step in Rohrer’s Methodology: Game Theory

Tasks: Testing letter probability

Let’s Talk About It:

Although I could not think of a way to apply traditional game theory to the system I was creating for my game, there were ways to test it mathematically without just building it and seeing how it felt. I utilized an anagram finder to see how many words could be spelled form different numbers and distributions of random and weighted groups of letters.

Spreadsheets are how level design gets done.

A quick note about the anagram finder I used: It gave back some results (mostly abbreviations and acronyms)  that nobody would consider words, along with genuine words. There were far less of these than real words, and I eventually decided that it did not skew the results in a strong as I was more concerned with the difference in the number of words spell-able by each letter set.

When I was brainstorming earlier, I thought that just using randoms letters would work, so that’s what I tried first. Since I had also decided on showing 10 stalactites at a time, 10 letters seemed like a reasonable place to start. 10 letters wound up being pretty slight, so I tried out 11 and 12 as well. These results were better, but it seemed to be very noisy; Sometimes many words could be spelled, sometimes almost none. This pretty much came down to vowel distribution.

Because the player could so easily be screwed by not having vowels, I wrote a simple Processing sketch to give me letters using using the weighted distribution used by Scrabble, the only difference being that mine did not keep track of which letters had already been picked, and just provided each letter as though it was being plucked from an otherwise untouched Scrabble bag. This definitely made for more words to be spelled, and while there were certainly outliers, the number of words that could be spelled with a given set of letters was far more consistent. I decided though, that it made spelling too easy. There were too many options with just a few letters as Scrabble was optimized for a smaller letter set than I wanted to use.

To attempt to rectify this, I modified the weighting to make good letters slightly less common, and to raise the probability of letters that are not quite as good (although I left some of the trickier ones, such as Q) untouched. These results offered a nice distribution at 10 letters. Moving forward, this is the distribution I will be using.

Journal Entry 4 – 4/12/12


Length of Session: About 30 min.

Step in Rohrer’s Methodology: Brainstorming

Tasks: Try to predict problems in the game

Let’s Talk About It:

At this point, I have a pretty good idea of the overall feel of the game, so now I want to start asking specific questions and coming up with answers that will predict and correct for the way players are likely to interact with the system.

First, I tried to nail down some specifics about the stalactites, focussing on how many there should be. I want the game to offer a wide range of available words at any time so that players are considering which word to spell in order to hit foes, rather than just scrambling for any word they can. Normally, I would just build the system and test different numbers, but it was not to be with this methodology. Instead, I based the number around Scrabble, a game I am fairly familiar with. The standard opening hand of 7 letters in Scrabble generally offers a fair number of choices, but usually only one or two “good” words. I want to try for slightly more than that, so I am considering 10, which is a nice round number and should offer considerable choice.

Next I tried to put myself in the shoes of Player 1, the speller. I tried to figure out if there were any optimal strategies and how the system could attempt to discourage these. For example, to prevent the player from just spelling any word they see without regard to where the foes are because they have a good shot of hitting if they just keep spelling words, I will be including a recharge time on the stalactites, forcing the player to consider their actions.

At this point, I realized that for the game to be fun, there would need to be a pretty good number of foes running around for the speller to try and hit. I tried to figure out how to deal with that and happened on another solution that also encouraged the speller to spell bigger words. I decided that having many foes would make a one hit kill too punishing, so Player 2 should have a number of lives or health. The way they could get more health could be when the speller spells are particularly big word.

Finally, I had to start considering how I could bring game theory to this to really test the game out Rohrer-style. Because the game relies on spelling, it will be a bit trickier since anybody with a truly complete knowledge of the system (a person who knows every word and all of its anagrams instantly) is extremely far removed from reality. I believe I will investigate distribution of letters instead and try to determine how many words will generally be available and how much they would score in terms of ammo and lives.

Create a free website or blog at