Thursday the team collaborated to combine the material each individual member produced for the core mechanics sprint. The goal was to achieve helicopter motion, animation-state-based rope “physics”, a camera that follows the player, and some basic winch control for picking up and manipulating objects in the game world. Immediately we ran into some problems trying to get the camera to follow the player because by the design of the Flash pipeline that seems to be a bug-ridden and counter-intuitive mechanic to program. I sat in and listened to the programmers discuss the solution and while I kept silent for the most part we ended up stepping out of the cave of horrible bugs into a new light of a redesigned camera system that will most likely serve the player’s needs as well as cater to both our programming needs and our looping world design. We ran across a few design issues: if the camera follows the player, and the player wants to fly high up, what happens when he loses sight of the ground? Are there going to be boundaries in our world? Where? Vertically? Horizontally? If we have the camera follow the player in the X direction but not the Y direction, there will be an awkward conflict in touch control. One of our programmers has been reassigned from rope physics to camera code in order to create a redesigned camera:
- The camera will at all times center on the player.
- As the player rises in height, their intention is to either get a view of the game world or to drop an object from a great height, and so the camera will zoom out so the player can rise without losing sight of the ground.
- As the player dips toward the ground, the implication is that they are swooping in to pick up an object or place one in a specific spot, so for accuracy the camera will zoom in as the player approaches the ground.
- As the player approaches the edge of the city to the right and left, the world will loop as though the helicopter’s path is cyclical.
This redesign of our camera maintains the flow of gameplay, provides the player with an appropriate amount of vision, and allows for a cohesive set of touch controls. While our issues with the camera have put us slightly behind our intended schedule, I think the discussion resulted in a much stronger design for the controls and the gameplay, which is more valuable in my opinion than being precisely on schedule because improvements like the one we made yesterday are the purpose and goal of prototyping a game.
Thanks for reading.