December 31, 2008

Breaking the Sound Barrier

Meridian will be my first game to feature audio.

When I made my previous games, audio seemed like a wholly unnecessary feature. I originally chose to include it just to get some practice and to give Meridian a consistent level of production. Now, after hearing the game in action, I'm starting to realize what I was missing; I'm starting to get why Greg Costikyan wrote that Asp's nonexistent sounds "are sorely missed".

The most immediate and obvious benefit comes with interface design. By using sounds for multiple events, I can indicate the connections between them. When a fleet enters a transportation gate, when a solar system spits a fleet out through a gate, and when the rally point for transportation changes, I use the same sound cue to show that it's really the same event (interstellar travel). Battles are easier to follow when there's a sound during each attack and upon retreat. When players select fleets by different means, the sound lets them know what's going on.

Then there's the background music. I spent some time looking through a few albums of Creative Commons-licensed music and found some great tracks. I don't know how they'll hold up over the long term, but just during the short games I play for testing I'm finding myself more and more engrossed. The atmosphere conjured by the sound effects seems to be just as important as the graphics'.

I'm applying the same learning process to Audacity that I used with GIMP: play with all of the options until stuff looks/sounds good. Hopefully I'll be able to do some decent audio editing on future games. Certainly anything I build beyond a tech demo won't be silent.

December 28, 2008

Evolution of Meridian

Meridian is nearing completion. Just menus, game saves, and polishing left to do. Now is as good a time as any to share how the game idea came to be.

I'd like to think I was originally inspired by the idea of a game set along a single line of battlefields, with those further back supporting the troops at the front, but in fact I was inspired by the title Meridian. It's a really cool word. Sorta like "asp".

Originally, a major part of Meridian was going to be managing public opinion on your home planets. You'd have renewable and nonrenewable resources on each planet. Using up nonrenewable resources hurt public opinion, unless they were near the front of battle and desperate. Losing and winning battles both caused the people to clamor for war (either for further victory or for revenge). If your people thought too little of you, you'd be kicked out of office and lose the game. Perhaps opinion would also affect your industrial efficiency. I also toyed with the possibility of having the option of negotiating for peace with the enemy leader, but your people would always prefer that you scorn peace and fight for glory. Peace was difficult, but the only real winning option. It would offer a (simplistic) message through gameplay.

But as I thought about the actual battle system and simulated the ruleset in my head, I came to realize that the whole public opinion aspect belonged to a different game. Meridian was, at its core, a game of managing resources and pushing an enemy further and further into a corner. Perhaps later I'll make a diplomacy game, but this is not it.

Raph Koster advised designers to figure out what the game is about and then do nothing that does not support that core game. I decided that Meridian was about "pressure": you had to methodically push back the enemy forces while they tried to do the same to you. If you push them too fast, they'll summon reinforcements in order to ensure a fighting chance. I wanted the feeling of a slow but desperate arm-wrestling match. More and more pressure until one side broke.

The basic setup was easy to imagine. I love hex grids, and the organization of forces into fleets of arbitrary size was fairly simple. I originally thought that you'd set a certain "tactic" for each fleet that would affect when they would retreat from battle, but I quickly discarded that idea and handed retreating control to the player. During the first few weeks of development I would lie in bed and imagine the game being played. I discovered a whole slew of small refinements were necessary in order to get the game I was hoping for. One critical aspect of the gameplay was hit and run attacks. Smaller fleets needed to be able to chip away at larger fleets in safety. This required that fleets be able to retreat, have the capacity to move two spaces in one turn on occasion, and have an initial first strike before the retreat. The battle system had to be just right, and it took me a while to figure out the current system.

The game takes place on only one solar system at a time, trying to fight towards the more distant systems. Originally, moving from system to system was originally going to take several turns, and both sides would bide their time before invading a new system (which might have made for an excellent interest curve). With this setup, the newly built ships of the losing side could get to the active solar system faster (since it was closer to their home systems). In order to turn this into a true advantage, ships were given an accuracy rating to represent how effective they were at destroying enemy ships. Newer ships had better accuracy ratings than older ones, so the losing side would have the most modern ships in play.

Later in development, I decided that having interstellar travel take time was not very significant from a gameplay perspective. The accuracy difference barely made a difference at all, since there were so few new ships in comparison to the total number of older ones. Instead, I went with the system that was easiest to program: interstellar travel is instantaneous and only takes place when ships are built. If I needed to, I could justify this with in-game fiction, but Meridian is not much story-based, so I didn't bother.

It wasn't until a few hours ago that I realized that with this simpler system in place, there was no longer any reason to maintain the changing accuracy ratings. Their main influence on the game was to clog up the UI with hard-to-understand percentages. If I just keep accuracy ratings static, the only important information to show in the UI is fleet size. I should be able to really clean things up.

There were a lot of other design changes during development, of course, but these were the most drastic and/or instructive.

Meridian: Coming Soon!

December 17, 2008

Ambition

Another Game Design Challenge that I really enjoyed. The requirements stated that it had to be an online game, but I think I might want to build this in board game form.
--------------

Ambition is an online game for 4 players. It mimics the conventions of a physical board game, with a virtual game board, game pieces representing the players, and cards that players can pick up and use.

All players start at the beginning of a path that has 100 steps. The players play in real time, with all players participating in each turn simultaneously. Players may take a maximum of one minute per turn. Gameplay centers around virtual cards. Players start with 3 cards. Each turn consists of choosing a card to play and choosing how to play it, and at the end of each turn, players get a new card at random.

There are three types of cards, each of which can be played one of two ways: either for the Greater Good ("played GG"), or All For Me ("played A4M"). The cards types:

1. Quandary Cards
Players have a 50% chance to pick up this type of card.
- If you play this card GG and ALL other Quandary cards in play this turn are also played GG, then you move forward 5 steps.
- If you play this card GG and ANY other Quandary card is played A4M this turn, then you move backward 2 steps.
- If you play this card A4M and ALL other Quandary cards in play this turn are played GG, then you move forward 10 steps.
- If you play this card A4M and ANY other Quandary card is played A4M this turn, then you move forward 1 step.

2. Help Cards
Players have a 25% chance to pick up this type of card.
- If you play this card GG, then you must choose one OTHER player who then moves forward 10 steps.
- If you play this card A4M, then you move forward 1 step.

3. Hurt Cards
Players have a 25% chance to pick up this type of card.
- If you play this card GG, then you move backward 1 step.
- If you play this card A4M, then you must choose one OTHER player who then moves backward 5 steps.

These cards essentially encode the Prisoner's Dilemma. Rational self-interest always demands that the cards be played A4M, but the best outcome for all is that everyone play them all GG.

In other words, Ambition is about selfishness and sacrifice. It is designed to teach a moral lesson through its game mechanics.

Two more rules enhance this lesson:
- If a player finishes a turn on spaces 1-29, they are automatically moved forward 1 space at the end of the turn. If a player finishes on spaces 60-99, they are automatically moved backward 1 space.
- Lastly, the game supports multiple winners. Any player who finishes within a 75-turn time limit wins the game.

These final rules amplify the fact that winning is nigh impossible through selfishness alone. Also, the open winning condition prevents the game from becoming totally cutthroat at the end.

Critically, Ambition must support an online chat channel during the game. Players must be allowed to discuss and negotiate as they navigate a complex social dilemma.

The numbers used in this design may be changed after playtesting, and the game may be colored and themed in order to make it more appealing.

Some lessons are best imparted through gameplay, and I believe that the lesson presented here (the basis for my personal understanding of morality) is one of them.

December 15, 2008

Fragility

Most interesting systems are fragile. I always knew this, but trying to create one has forced me to really learn it.

I'm trying to craft a set of rules for a fairly simple turn-based hex grid game. Each piece can move once a turn. Moving onto another piece (attacking) generates a battle, and one side may retreat from the battle. Pretty easy to follow.

Except that it turns out that I need to get everything juuuust right for it to work strategically. Does an attack count as a move? Once a battle is won, should the winner move onto the space? Should the retreat move backwards or should the retreat movement be at the player's discretion? Further, when attacking confers an advantage, when is it ever advantageous for a player to move a piece to a space adjacent to an enemy piece? Wouldn't both players then just dance around each other?

I've tried to solve this last problem by adding a "boost" mechanic, in which each piece can move twice after a 5-turn cool-down. There are all sorts of other little fixes that I've found necessary. Retreating pieces can retreat into any space surrounding the one right behind them except the one in which the battle took place. Pieces that win a battle can move afterwards, but losing pieces can not. Et cetera.

And while my tone might suggest that I'm frustrated or upset with all this, the truth is that I revel in this sort of puzzle-solving. This is game design, and it suits me.

I'm hoping to have Meridian feature-complete within a week.