Malaria

The first assignment in our Values at Play game design class was to design a card game that would educate about malaria prevention. My game:


Malaria

Malaria is a cooperative game for 5 players, who must use nets, medications, and insecticides to stave off the threat of malaria in their village.


Setup

There are three decks of cards: the Defense deck, the Mosquito deck, and the Identity deck.

1. Shuffle each deck separately.
2. Deal one Identity card to each player
3. Deal three Defense cards to each player

Procedures

Malaria alternates between two phases, Day and Night, until the game is won or lost.

Day:

1. Each player draws a card from the Defense deck.
2. Players may exchange cards freely.
3. Players may play any number of Defense cards to protect themselves from mosquitoes.

Night:

1. Each player draws a Mosquito card.
2. If the Mosquito card shows more mosquitoes than the player is protected against, that player must keep the Mosquito card, bringing them closer to death.
3. All other Mosquito cards and all played one-time-use Defense cards should be placed at the bottom of their respective decks.

Defense Cards

The Defense deck is composed of the following cards:

• Quinine: Protects against one mosquito. Must be discarded at the end of the Night.
• Medication: Protects against two mosquitoes. Must be discarded at the end of the Night.
• Bed Net: Protects against one mosquito. Does not have to be discarded. Only one Bed Net can be used per player in any round. Extra Bed Nets are wasted. Can be upgraded with Insecticide.
• Insecticide: A player can place an Insecticide card on a Bed Net card to permanently extend the Net's protection to two mosquitoes per round.

Winning and Losing

Collecting 10 Insecticide cards (not including those attached to Bed Nets) means that the village can spray their houses with insecticide and kill the mosquitoes. All players win the game.

If any player collects the number of Mosquito cards indicated on their Identity card, then that player dies, and all players lose.

Aurora Update

Menus are working, including cool special effects. Three unique and interesting levels are in place. Basic systems work and are fun.

More importantly, the performance of the game just got better by a factor of LOTS. At first, having hundreds of units floating around freely and constantly checking for collisions was just too much to handle. I was able to make that problem go away most of the time with a more efficient algorithm, but the problem was still very much apparent when large groups got close to each other (i.e. a battle). The game would stutter, go down to a couple frames-per-second, and recover as soon as most of the units disappeared.

I finally pulled out the adult dev tools. I downloaded and used NProf, a .NET profiler. It records how much time is spent in the different functions of the game. I discovered that 80% of my difficulties were coming from a single function. It involved a lot of checking lists for members. I figured out that I could greatly trim the amount of checking performed, did so, and figured out a bunch of other performance hacks along the way. Performance still dips during a battle, but down to a still-playable rate. I doubt anyone will mind, now. Victory!

Still left to complete:
- Endgame conditions and an end-of-game finale effect
- Improve visuals and effects for building / destruction events
- Retool all my sound effects
- Tweak the soundtrack songs to make sure they're perfectly aligned with the game beat
- Polish
- Package
- Ship

The end is in sight. I'm feeling awfully optimistic about this.

Aurora Music

I did a lot of experimenting with the Aurora music system, hoping to essentially build a soundtrack out of sound effects. I could make it context-sensitive and everything! But, alas, I don't have the musical knowledge to do it right. There's a lot of potential there, but nothing sounded quite good enough to work. I also had several technical issues that put everything painfully off-sync.

Still, I didn't want to abandon the idea entirely. I found an album of free music called Rooftop 120 that was filled with great ambient tracks, all at 120 beats per minute. I can set the rhythm of events in the game to the same speed, keep my musical sound effects, and use this excellent music as background. It sounds pretty awesome, and I don't think I can do better by building it piecemeal.

I'm now working on smoothing out the AI and adding maps, and then it's time to start building menus and completing the outer structure of the game.

Values at Play

This term I'm taking my second game design course from Professor Mary Flanagan. This one is subtitled "Values at Play", with a focus on encoding values in gameplay.

Last year's game design class required one game per week. I'm guessing that this year will be similar. I'll post descriptions of my games here.

Aurora Thoughts

I'm making progress on Aurora. Recently I've been mostly focusing on experimenting with the UI and making the music system work (more on that later), but I'm also putting thought into the core gameplay structure. To remind you, the basic idea is that there are buildings and troops. Buildings produce troops at a constant rate. Troops can annihilate themselves against enemy troops, enemy buildings, or friendly buildings (to upgrade). Buildings can be upgraded once, doubling their production rate. It costs 100 troops to build, upgrade, or destroy a building.

In trying to create a pared-down RTS, I may have broken the genre. By removing most elements of luck and putting players on an even field, the game tends towards a stalemate. Most of the strategy involved right now involves trying to slowly-but-surely gain numerical advantage over the enemy. There are a few ways of doing this:

• Upgrade your stars before they do and have a higher production rate until they catch up.
• Let the enemy annihilate troops against your buildings, but not so many that your buildings die (so they are essentially wasted).
• Focus fire on an enemy building and gain a production advantage until they send reinforcements and recolonize it.
• Destroy an upgraded enemy building (you spend 100 destroying something that took 200 to fully build).
• Let the two enemies waste their forces against each other and build up strength from afar.

In the current setup in which each of three players has an outer building and an inner building (all three of which meet in the middle) in a symmetric formation, it's almost impossible to gain enough of an advantage to win. Usually you have to use the last strategy I listed: pull back, lose your outer building, and gather enough forces at the inner building (while your enemies engage in a stalemate battle) to eventually sweep over the map.

That takes too long, and it's too passive to be consistently fun. I'm led to believe that RTSs are mostly defined by the imbalances, asymmetry, and chaos they introduce. Rock-Paper-Scissors combat mechanics, asymmetric factions, and interesting maps are examples of this. I was trying to distill the RTS down to something simple, symmetric, and direct, like Chess, but the "essential" rules to which I am committed don't offer the complexity that's required to make that scenario interesting.

This leaves me with three options.

First, I can add larger, more complex, and maybe more asymmetric maps. Just the possibility of having multiple fronts of battle might be enough to solve my conundrum. I plan to try this first.

Second, I can cave in and change my basic mechanics, thereby admitting defeat in my design experiment, and make it into something different. Multiple building types, multiple troop types, flanking effects, etc. I'll add complexity until I force strategy.

Third, I can report the results of my failed experiment like a good scientist. If it's still unfun (but also still an honest attempt at an essentialized RTS), I can release it as-is and show it off in order to teach others the lessons I learned during its design. Principled and uncompromising, but maybe unsatisfying as well.

For now, I'm hoping that the first option will be enough.