Lilypadd is meant to be a children’s game for practicing addition and subtraction. Frogs jump from one lily pad to the next either adding or subtracting the numbers they show. Each lily pad is one of five colors, each representing a different way to hinder an opponent’s progress toward reaching the goal number. To activate that power up, the player must match (by color) three lily pads in a row. This ability to mess up the other player allows children to forget they are learning and adults to become excited about a children’s game.
I knew from the beginning that I wanted this interaction to be at the core of my game. At stage one, I decided that I wanted to make a learning game that, although geared toward kids, would also be entertaining for adults. My goal was to give players the ability to directly affect the progress of their opponents, so I knew early that there would be power ups and that both/all players would share one screen. Adding and subtracting seemed like an obvious choice for a children’s game and frogs just seemed to fit the game best.
What went right…
Simpicity: I knew from past game class experiences that I wanted to start simple. In the past I have set my eyes on a goal way too big for the scope of less than ten weeks and ended up with a pretty unfinished game. So, this time around I started with a simple game that I knew I could code, even if it was in a completely new language…This was the smartest thing I did all quarter. Instead of getting bogged down in details like concentric circles, like last quarter, I was able to set simple goals for myself and see my intended final product by the end of the quarter.
Early prototyping: The simplicity of my original idea allowed me to have a finished prototype early. This made it possible to see what would be fun about my game early on and use that knowledge in the rest of development. Early prototyping also gave me the chance to add extras like animations, menus and sounds.
Playtesting: This was not something I had really done before and it proved to be invaluable in my design process. My playtesters brought up new ideas about power ups and ways to make the gameplay more fun as well as pointing out some bugs and less interesting points in the game, which I was later able to avoid.
What went wrong…
Learning a new language on the fly: Okay, so in the end it wasn’t that bad, but the development could have taken a quarter of the time if I had created the game in a more familiar language, say Processing. I am glad I stuck it out because of XNA’s connection with Xbox Live and the new features Microsoft is providing, but it definitely created some kinks along the road.
Flying solo: I generally prefer to do everything myself, as I have been screwed over a few too many times by flaky partners. I am also very picky and like to do things my own way, so I opted to work on this project alone. I wish I had taken the opportunity to partner up with a CS kid or one of our more tech-savvy designers. This would have allowed me to spend less time debugging and learning XNA basics and more time designing the game play and creating artwork. I am glad I put myself in a position where I was forced to learn at least the basics of coding in C#, but I think the project could have benefited from a more well-rounded team.
In the next few months, I am going to continue working on the project, playtesting and making the game as fun as possible. Then you’ll see it on Xbox in the fall!