What Went Right

1. Design Principles. I should say up front that I’m a fervent believer in Formal Abstract Design Tools (see Gamasutra article) and I teach the MDA game design framework each year with Marc at GDC. Those concepts and that framework were extremely valuable when deciding how to implement a feature to achieve a desired result. It aided communication and sped up the tuning process significantly. That said, the goals that I had initially set for Oasis came from no framework; they were bits of inspiration and wisdom gathered ad-hoc from many sources. This appears to be a truth of game design, that process and theory can help when things go wrong, and they can help a designer pinpoint the relationship between a rule and a result, but inspiration and experience are hard to express and even harder to teach. Thus, I can’t justify the core principles chosen to create Oasis, but here they are:

"No bad clicks." A level consists of 85 carrots and one big stick. The player takes 85 turns discovering and rebuilding his or her empire, where every turn creates some kind of goodness. At the end of the 85 turns, the barbarians arrive.

"The sucker punch." The Oasis, which has no military value, is the key to winning a level.

"Stupid Drama." The term “stupid drama” was adopted early in development, and came from my amazement at how easily I was drawn into each battle. Even to this day, my eyes are glued to the screen during most combats. The source of the drama is simple: the combat system places players at a distinct numerical disadvantage; there are almost always more barbarians than city defenders. This creates an impression that each city is doomed and all hope is lost. However, with the help of weapons and technology, cities fight with more vigor than their barbarian counterparts, creating a dramatic climax toward the end of most battles. This same dynamic is played out over and over again, yet seems to draw most players in each time.

"All potent clicks are unambiguous." All actions are contextual. There is never any question as to what a click will accomplish. Thus, no context menus are required.

"Even experts will argue." There should be many successful strategies in Oasis, allowing players to feel a sense of agency.

And then the lesser principles:

"Life’s not fair." Oasis levels are not fair. They are created randomly, following a complex set of heuristics. It is not a foregone conclusion that a player will win a level militarily. If things look bad, a smart player starts to think more defensively.

"Information trumps strength." Information is generally more important than raw force, so look before you leap.

"Try to be lucky and maybe you will be." This is a principle not generally represented in modern games.

"You have to break a few eggs to make an omelet." Sometimes, players must let cities fall to the barbarians in order to take a stand at a more defensible location.

"Create real difficulty levels." Most casual games provide difficulty levels that players ignore because they increase the chance that the player will lose. Oasis has a victory condition that is attainable, so after a player has won repeatedly on a given difficulty, they are likely to proceed to the next one.

2. Playable from the Start.The first Oasis prototype took two days to create. I coded it in Java because I had fallen in love with the JetBrains’ IntelliJ editor and wanted an excuse to play with it. That first version of Oasis was an ugly beast, as the programmer was also the artist, but the basic game was fully playable. Over the following weeks additional features were added, such as Technology, and the ability to play more than one level without restarting. However, starting with a playable game had numerous benefits.

• Less talk, more implementation.
• It was easy to see if an idea broke the game because we were always playing it.
• By making it possible to play Oasis, people could experience the vision and decide that they wanted to play a part in the making of this game.

It was challenging to cut the feature set of Oasis down to something small enough to implement in a weekend, but a larger prototype might never have been made. The promise of the initial version propelled the project forward.

A philosophy of prototypes that I’m fond of goes like this: as a designer, you’re in a dark room and your game can be found somewhere on the walls if only you had a flashlight to search with. Game code is that flashlight and the batteries come from the energy of your programmers. The moral of the story is to find your game early, even if it means creating a throw-away prototype.

	The result of "one click" within Oasis.

3. No Feature Creep. Oasis managed to survive the almost unavoidable tendency to add unnecessary features to a game. There were plenty of suggestions that we received from our beta testers that seemed good at first blush, but which fell apart upon further examination. It was amazing how few ideas really fit in, probably because Oasis is such a small, tight game.

Perhaps the urge to add features was mitigated because Oasis was not only fun, but challenging from its first incarnation. Historically, I have been most tempted to add features during development when my current project isn’t as much fun to play as I had hoped. This might explain feature creep within design teams: developers want their game to be fun and challenging during development, even in a feature incomplete state. A better approach might be to tune the game toward the target audience, which does not generally include people with knowledge of a game’s inner workings.

4. Stick to Principles. Oasis is a game that strays from several turn-based game conventions, but hopefully to great effect. After the player has taken their 85 turns, they have ten seconds to deploy their population along roads to cities of their choice. This was a controversial decision, as it created a time limit in what is otherwise a turn-based game. We kept this feature, as it creates a point of tension that leads to a climax as battle begins. In our minds, it’s not that different from a swing meter in a golf game. The exciting “moment of flight” in golf is predicated by a brief time-critical period where swing strength is established.

Another controversial area was combat depiction. For some time we toyed with the idea of a cutaway combat resolution sequence. There’s no doubt that we could have created a more beautiful view of battle, but it would have killed the graceful continuity that was achieved by keeping battles on the playfield.

There are several possible outcomes at the end of each level of Oasis:

• The player defeats the barbarians and gains a glyph of power (winning the game when the twelfth glyph is earned).
• The player defeats the barbarians, but does not collect a glyph of power.
• The player does not defeat the barbarians with cities, but stops them with a glyph of power or at the loss of some power of his scarab staff.
• The player does not defeat the barbarians with his cities, and the barbarians drain the Scarab King’s staff of all power, defeating the Scarab King and ending the game.

The concept of losing a level militarily but not losing the game was controversial. Perhaps it was confusing to “lose” but be allowed to continue to play. However, this was a crucial part of the game’s design, as there was no way for us to easily tune the levels to be “fair.” Without fairness backing us up, we needed a safety net, which was the life force in Scarab King’s staff. This fit beautifully into the notion that clicking on the Oasis rewards the player with life points to be used in the case that the barbarians defeat the player’s cities. The conflict between ensuring a military victory and stocking up for a rainy day ended up being a signature design feature of Oasis.

5. Unexpected Help. Oasis improved significantly in its final months as production came to a close. Much of the game tuning had already occurred, thanks to the help of more than 6000 beta testers we solicited early in development. Their feedback on our message board not only helped us identify exploits and cheats, but helped us see holes in the tutorial and various aspects of the game’s presentation.

Our publisher also made some suggestions that improved the game’s presentation; the visual sparkle that accompanies the completion of a road network to a city is a good example. They also created a high score API that allowed players to see their global ranking at each difficulty level. Though we never played Oasis for points during development, it turned out that many Oasis purchasers were fanatical about their scores. Seeing daily, weekly, monthly, and all time high scores was clearly a boon to the community of Oasis players.

We knew from the beginning that audio would play a large role in the perceived fun of Oasis. We were lucky to have an award-winning composer, Michael Sweet, help out with the early sound effects, which was very helpful when we submitted a version of Oasis to the IGF judges. However, as time passed, so did the game’s presentation, requiring new audio. Luckily, a young composer, Harry Mack, a friend of one of our employees, created some sound and music for Oasis on the off chance that I’d like it. I loved it. His initiative paid off and we dedicated considerable resources into tuning the audio to completion.

Our family and friends believed in Oasis and helped play-test and tune the game. Their faith lent strength to the entire endeavor. We also received their financial support during some dark times when working on Oasis distracted us from pursuing consulting work.