| |
|
|
| |
Previously, every type of falling object had to have its own class that defined the object type's sprite, weight, and reaction to the cart/floor. This was pretty messy considering how many object types may only be used in one game mode--for instance, the many power ups in Power mode, once it's created, will never be used outside of Power mode. So, to increase customizability and decrease class clutter, game modes now use a FallingObjectFactory to define recipes (basically a sprite filename, a weight and an identifier) that can easily be built throughout the game mode using the identifier. FallingObjectDelegate is now used for all reactions to the cart/floor, rather than defining a standard reaction in the FallingObject subclass and then putting extra stuff in FallingObjectDelegate.
|
| |
|
|
|
|
|
|
| |
In order to prepare for tutorial mode (and eventually, the other game modes), a lot of GameLayer's functionality (reading the accelerometer, moving the cart, moving falling objects, reacting to collisions…) has been abstracted out to FallingObject and subclasses of FallingObject, as well as a new Cart class, and GameMode, a new superclass of GameLayer. The only things that were not abstracted out that probably will be in the future are the pause functionality and the tutorial bubble functionality (which will in fact be moved to the tutorial mode class).
A lot of work was also done to cut down on compiler warnings and a lot of #imports were moved from header files to implementation files because I realized THAT'S HOW YOU'RE SUPPOSED TO DO IT.
Refs #193
|
