Sphero Final: Drive or Die (Adam King, Jack Ferris)
Overview
For every second your Sphero isn’t driven at full speed, you’re causing it to die a little inside. Yet your Sphero is fragile and it’s a dangerous world out there; objects are the bane of Sphero existence and colliding with anything at all eats away at your robot buddy’s lifespan. With health bars on the line, you are faced with only one choice…
Drive or Die.
The idea behind this app will be driving your Sphero. Sounds easy, right? Wrong. Your Sphero has a health bar, and for every second the joystick isn’t cranked all the way in some direction your Sphero will have a diminishing health bar. Yet walls, chairs, and other objects loathe the Sphero for its ability of mobility, and conspire to drain your robot’s health upon collision.
Your Sphero’s intelligence, however, is rather lax. Periodically it may become confused causing the joystick controls to suddenly be inverted. It may also suffer bouts of extreme slowdown, lulling its master into feigned safety, before accelerating back up to full speed without warning.
The Sphero’s health is tracked both by health bar and by the Sphero’s color. Green represents great health. Yellow means your Sphero’s health is moderate, while red indicates critical condition. A timer is used to show how long your Sphero has survived, and will ultimately be used to generate your final score.
The currently imagined screens involve:
A home screen, likely tracking the high score and hopefully providing the user with a selection of several difficulties.
A control screen, likely a joystick, health bar, and timer. Messages may periodically appear warning the user of a power-down, such as inverted controls.
A defeat/score screen, notifying the user that his Sphero has met an untimely end and displaying his final score, possibly along with statistics.
Risks/Hurdles
The main risks/hurdles will likely be implementing graphic aspects for the interface and bringing all of the aspects (joystick, calibration, collision detection, color changing) together. Individually, each task is simple to implement; bringing them all together and having them work well so as not to hinder gameplay could prove more of a challenge.
When the actual gameplay is in place, implementing extra features such as random moments of inverted control could prove tricky.
Division of Labor
Getting a base framework with movement controls, color changing, and collision working separately will come first. Once that framework is complete, tasks will likely be split into integrating movement and collision, integrating collision and color/”health” changes, implementing the actual game, creating interface/graphics for the screens, and then hopefully implementing some extra features (such as inverted controls, other difficulties, etc.)