After a bit, my team created a semi-working prototype of an early version of the game. It had most of the major features of Duck Pond implemented: there was a duck, on a pond, and the player can slide their finger through a zone of the screen to throw bread out to the duck. The duck could see the bread, swim over to it, and eat it. We even had the first trick programmed in, Groom. However, none of these features were finished; far from it, actually.
This is where I come back in. My programmer had designed the game so that many of the key variables of the game were all contained in one place. They variables included the size of the bread flicking zone, the movement speed of the ducks, the scaling factors for sprites to control perspective, etc.. Basically, any variable I wanted, he could create, thereby giving me, the designer, more control to craft the experience. Sweet.
A few notes about testing. First, if you are designing an App, you should have a Mac so you can run all the SDK, simulator, Xcode package and test your App. I had to upgrade mine to even run the latest operating system. Second, it also helps greatly to have a device to test on: iPhone or iPod touch preferably. Luckily, between my team we have most of the devices that may be running Duck Pond: iPod touch, 1st gen iPhone, 3G, 3GS, 4G, iPad, so we can test the game on each of these. One of the most common reasons an App does not pass certification for the store is that it crashes on at least one of the devices. The SDK comes with a simulator, but I found the best way to test it is the same way people will play it, on their devices.
The first, and biggest, task as the designer for Duck Pond is to make the bread flicking feel rewarding. We ran into a few problems early on. In the original version, players could flick bread in any which direction in the bread flicking zone. Essentially, the game was programmed to launch a piece of bread on a certain trajectory with a certain velocity matching the players flick line and speed. So, if the player quickly made a vertical line, the bread would fly out vertically with a decent amount of speed. Similarly, if the players made the same line, but horizontal, the bread would fly off to the side.
We quickly realized that having complete freedom to throw bread wherever was unnecessary and actually made the game more frustrating. Of course, when somebody goes to a duck pond, they can throw bread in any manner they would like, but this is a game, not real life. There is no point to allowing the player to throw bread way off of the screen. There had to be some balancing.
Another important issue had to deal with replicating flicks. Since the game would depend on the player being able to place bread in certain configurations around a duck to activate tricks, the player had to feel in control. Part of getting better at games is repetition, and when the player feels that they cannot even replicate the same actions, it becomes increasingly difficult. Imagine if in Super Mario Brothers, Mario’s jump height depended on how hard you pushed the button and the button was ultra sensitive - it would be no fun.
To tackle some of these issues, we implemented a new flicking system. First, we bound the angles that bread could be thrown out, essentially creating a cone shape of where bread can be flicked out. Then we broke this cone into ten degree lanes and told the game to round the player flick to the nearest ten degree lane so that the bread would come out more predictably. Lastly, we made the length the bread gets tossed proportional to the distance the finger draws on the screen instead of proportional to the speed and distance the finger draws on the screen. These improvements actually made the player feel more in control, despite the reduction in freedom. As with the other systems, we have variables to control each of these new functions including the overall number of degrees in the flicking cone, what degree to round each lane to, etc..
For me, this has been some of the most rewarding work done yet. It feels great to push your vision forward and watch some of the rudimentary aspects of the game be playable, improvable, iterated, and hopefully, completed. There are obviously many more examples of this type of stuff. I try not to stay too connected to any particular feature or function because you never know if it will work until you play it.
Till next time...
Joe the CEO
For screens, news, and other details, check us out on Facebook
or send us a mail at firstname.lastname@example.org