Arson (Unity3d Web Player)
Time-frame of project: Spring 2012 (5 week project)
Project status: complete
Original pitch presentation here: https://docs.google.com/presentation/d/1lh1khzhAOhxcxPiAoKVWolEmGSknQxBY-_HzKss3SA0/edit#slide=id.p
Final presentation here: https://docs.google.com/presentation/d/1RX8WApHDeAqwpZWTS7w7kOmpfWMBacWDmcnCo4FPK0c/edit#slide=id.p
Role: Game Designer, Programmer
Arson was our second and final project in my Video Game Design class, and we were given 6 weeks to create a networking multiplayer game using Unity3d. It was the first time that any of us had created a multiplayer game that used networking and it was a slow and grueling process to make this game, but it felt very rewarding to have it working well in the end.
I first had the idea for Arson when I was trying to think of a neat way to make an asymmetric strategy game that relied on fire vs. water mechanics. Arson is a 2-player competitive strategy game where each player has a city and tries to burn down the other player’s city. Players have control of two different units: an arsonist (with the ability to set buildings on fire) and a firefighter (with the ability to put out fires and dose buildings for a few seconds to make them invulnerable to fire). Each player owns a city that is composed of several buildings. When a building is lit on fire, the fire will spread to all surrounding buildings after being on fire for a long enough time. To balance out the rate at which fire spreads, an arsonist carries a “torch” that goes out after each time a fire is lit, and the arsonist can only re-light it by going back to the player’s “firepit” (located in the center of his or her city) and standing next to it. Meanwhile a firefighter can infinitely put out fire or dose houses (although the dose wears off after a few seconds) but only one at a time.
The game was originally going to be completely asymmetrical where one player controls only the arsonist character and another player controls only the firefighter. However the networking implementation was taking so long and required a lot of our previous code to rewritten (we naively decided to start implementing game mechanics in a single-player game and then tried to add in networking at a later point – a mistake none of us will make again) that most of the planned mechanics got cut from the game. To make the game more interesting for both players we decided to make the game symmetrical: each player has their own city and control versions of both characters in the game. This gives the player more tasks to do at all time and ensure that they do not feel bored (waiting to react to the other player) or that the game is unfair (by making the game symmetrical we were able to avoid having to deal with balancing the game).
The biggest lesson I learned from making this game had to do with learning how to make a game fun despite having to cut out a ton of mechanics because there wasn’t enough time to implement them. The final game is far simpler than originally imagined, although I am quite proud of how compelling the game still is. We had to boil the mechanics down to their simplest form and put all our effort into making that they worked and were enjoyable.
You can play the game and read our post-mortem of it here: http://gamedeved.com/content/stars-craft-project-3-final-submission#overlay-context=node