Code Organization

On this page, I'll try to go through all the major classes in our code bases and how they function together in order to make our game.

At a super high level, our codebase consists of several large components which each offer a service. These services can be interfaced in one of two ways, depending on the services. In the first way, classes wishing to get the functionality provided by a service first implement an Interface which allows the service to then interface with the class. The CollisionEngine interface is used for the collision detection service, UpdateCycling is used for receiving update events, etc. When an object of the implementing class is then constructed, next to the "new Class()" line should also be a line adding that class of the appropriate service's service list. In the second way, classes wishing to get access to a service should have an instance of the service passed to them in the constructor. GameplayControl is an example of such a service.

There are three major instantiation classes - code regions whose sole responsibility is to construct a level, map, or game, by constructing the appropriate objects and then adding them to the appropriate service lists. If you want to build a class for a new mechanic, you will also need to modify these regions so your new class is instantiated correctly

Let's go over each of the major services, and how they may be used.

CollisionEngine - Collidable

This service is responsible for detecting whenever two game world objects are about to collide, and informing the parties involved about it. It is not responsible for resolving those collisions, when detected - that is the responsibility of the collided.

Classes wishing to be figured into collisions should implement the Collidable interface, and then be added to the colliders list at construction time using .addCollidable(). It takes the collidable and an integer constant (LayeredCollisionEngine.FLORA_LAYER or FAUNA_LAYER) specifying the layer that the object should reside on. Objects are only collided with objects on different layers; no use seeing if a static map tile could possibly collide with neighbor.

Updates - UpdateCycling

About 60 times a second, the game will try to update it's game state (where the bunnies are, how fast they're going, if they've won yet, etc). It does this by calling the update() method in GameplayState, which then goes through three steps. There is a list of objects in GameplayState called updaters made up of objects which implement the UpdateCycling interface. First, it goes through the entire list and calls startUpdate() on these objects, signifying the beginning of an update calculation. Then, runs the collision engine. Finally, it goes through it's entire list again and calls finishUpdate() on every object.

The service here is of the first type. If your class needs to update itself in some way every tick - move around, for example - it should implement the UpdateCycling interface, and put the code to update it's state in the startUpdate() and finishUpdate() methods. If your updating could be affected by collision detection, then the startUpdate() method is a good place to set up the state which your object would like to be at, and the finishUpdate() method is a good place to finalize the state after you've resolved any collisions which that requested state would have caused. If your updating doesn't affect collision detection, then which method you use is up to you. Finally, make sure that you add yourself to the updaters list when you construct your class.