DESIGN REPORT

In “The revenge of the birds” the mission is about killing all the birds with flu, which have attacked to the earth. The player should prevent the invasion of the world by these birds with flue. Some of the birds are flying towards the earth and some of them are on the ground. Killing the birds brings extra points and some bonuses like machines; cure kit and energy pack to the player. By these bonuses it gets easier for the player to complete the mission. At the end of the levels there is a more challenging mission that a big infected bird, which is the strongest of all other birds, attacking to world shoul, be killed. After killing this bird the player passes to the other level. When the earth is saved and purified from the infected birds than the mission is successfully completed.

1.2- Design Goals

“The Revenge of the Birds” will be designed to be a single player game. And during the design we will try to three goals:

1.2.1 Ease to Use

The main goal of our system is to create a system that is easy to use for the players. the interfaces and the system should be so clear that the player should not need any external help to play the game so that the game would be enjoyable. Also the system gives some options like save and load game. These options should be handled in such a way that the player should not have a complexity to use these options.

1.2.2 Functionality and Performance

Another goal of our design is to support functionality and performance in our system. The system should be as fast as it can be since in the game there are several objects in the game that are constantly moving and changing directions fast. If the speed of the system cannot be handled appropriately then the resulting project should not be as functional as it is expected to be. First of all the game “The Revenge of the Birds” would not be enjoyable with a lower speed and this is the most important thing in the marketing of a game.

1.2.3 Good Documentation

A good documentation is necessary for a projects design phase as it is also important in all other phases. By the help of a good documentation the implementation phase gets easier and it leads to better and more effective implementation.

1.3 Why Java?

Java is a portable Object-Oriented Programming language and all members of our group are able to use Java. Since java is a portable language it can be executed on any platform with JVM.

Also Java language has a large supporting class libraries and it has simple syntax. Also java supports multithreading and in our program we need to use multithreads. And writing multithreaded programs is much easier in Java.

Another advantage of the Java language is; just-in-time compilers and advanced memory management makes Java programs faster.

Since we have decided use Java language as our implementation language, we use Java classes when appropriate to simplify the design details.

2. Proposed software architecture

2.1 Overview

Purposed software is a single-game having numerous object interactions. Therefore, we aimed to design the game in a way that provides lowest coupling without making implementation harder.

2.2 Subsystem decomposition

We propose two packages for our software: GUI and GameComponents. GUI classes are responsible for user interface and GameComponents classes are GUI-independent representations of the game objects.

As dependency details is shown in Figure 1, only a few classes from different packages depends on each other. During game, main interaction between packages occurs between PlayFrame, GUI class of game play, and GameEngine, main sychronizer class of game objects. In each interval, GameEngine triggers PlayFrame to draw its objects.

Load and save operations are made by SaveLoadManager class. Therefore, related GUI classes (LoadGamePanel, load operation GUI panel, and InGamePanel, paused game menu panel which provides save operation) depends on SaveLoadManager.

Moreover, SettingsPanel changes static music/sound level attributes of SoundEngine and static game speed attribute of GameEngine. Thus, SettingPanel depends on those two objects.

Figure 1. Package Diagram of the System.

2.3 Persistent data management

In requirements, save-load operations are provided. Two provide these operations robustly, we purpose to use object serialization facility in Java. Thus, a default file is used as saved game database to/from which object serialization output is written/read.

Although during the rest of the report serialization interface relation is not shown to reduce the complexity. However, during implementation, all non-abstract classes should implement java’s Serializable interface.

2.4 Access control and security

Since requirements report does not state any security restriction and does not include user account management facilities, there are no user access restrictions in the software.

3. Subsystem services

In this section we provide detailed design of the classes and explain the considerations behind the design.

3.1 Package GameComponents

This package has all the GUI-independent game classes storing game play data and providing game play operations. In Figure 2, associations and hierarchy among objects in the package are presented. Since we believe that in analysis phase we have stated enough sequence diagram related to this package classes, we do not provide any further sequence diagram in the section.

Figure 2. Classes in GameComponents Package

In the class diagram, to increase the readability, we did not write all set/get methods of the attributes explicitly. Implementers should be aware of this.

MouseHandler

MouseHandler provides the abstraction to hook mouse events. This class works in an independent thread and whenever user clicks a button, button-clicked flag is set and it continuously updates its mouse position attribute.

However, it does not remove clicked flags automatically since more than one object would be using one instance of the class. Therefore, the object using the instance of this class should remove the clicked flags using set/get methods.

SoundEngine

This class provides the static methods to perform sound effects and background music. The level of the music and sound effects should be set to a level between 0-100.

LevelManager, GameLevel, GameLevel1, GameLevel2

LevelManager is the class creating a specific GameLevel object upon request. Each GameLevel object represents a game level and creates game objects in specific time.

Since GameLevel is an abstract class, for each game level, a class extending it should be written. getCurrentAirObjects and getCurrentGroundObjects methods should be overridden to provide creation of game objects during game play. In each update() call made by GameEngine, the current time is incremented.

In our implementation, we purpose two game levels, GameLevel1 and GameLevel2.

SaveLoadManager

Saves or loads the current game by using serialization utility of Java.

GameEngine

GameEngine is the threaded class synchronizing all objects in the game. It has a run() method inherited from java.lang.Thread which loops at a constant interval.

It stores BonusObjects, Bullets, AirObjects, GroundObjects in different list since they have relatively complicated collision situations such that:

- BonusObjects collides with AirCraft.

- Bullets collides with AirObjects and GroundObjects.

- AirObjects collides with AirCraft.

- No other collision check should be made.

Moreover, all object references is stored in a different list to provide them directly to the repaint method of the PlayFrame.

When user presses ESC, its pause should be set to true by PlayFrame.

In each run() loop, new objects entering the screen should be requested from GameLevel object.

Other details are given in the requirements document.

CollisionDetector

CollisionDetector provides detecting collisions between GameObject’s. It should use current image of the target objects to detect the boundaries of the objects if an exact collision detector is to be implemented. Otherwise, only the boundaries of the image of the object would be used.

GameObject

GameObject is the class representing the all objects that would be seen in the screen. Therefore, it has an image and the position.

ShootableObject

This class generalizes all the ground and air objects that can be shot by a bullet (or a bomb). Therefore, it has energy attribute representing the remaining energy of the object and point attribute stating the point to be gained by the player as the object is destroyed.

When object is shot by a bullet, it internally handles the changes in its method shotBy(). When it sets its destroyed value to zero, it should be removed from the screen. Note that these two event may not be occur at the same time since either object may still have remaining energy or it may be presenting explosion animation.

GroundObject, Ostrich, Farm

GroundObject is an empty abstract class generalizing all ground objects in the hierarchy. It is used to distinguish the object that can collide with the aircraft and that cannot. All ground objects (Ostrich and Farm) should override the update() method to describe the way it gets destroyed when its energy level is zero and should override getBonusObject to provide random/specific bonus objects when they are destroyed.

AirObject

AirObject is an abstract class generalizing all airobjects that can collide with the aircraft. As stated in the requirements report, these objects can be infected and gives damage to the aircraft when they hit to it. Their, getEgg() method provides the Egg object if air object releases an egg during the game. For other objects, this method would only return null all the time. The objects leaving egg should override this method.

FlyingHayb, Chicken, FertilizedEgg, ParaChicken, Egg, Duck, Dodo, Pigeon

These classes are the child classes of the AirObject. Their different behaviors can be obtained by only overriding getEgg() and update() methods as their behaviors are specified in the requirements analysis. In their constructors or update(), they should set their own images to curImage, which is inherited from GameObject class.

Bullet, Bomb

Bullet is the general bullet object that can hit air and ground objects. It damage value should be set by its creator Weapon object. Moreover, since it is a GameObject, its image appropriately set by the Weapon object.

Bomb is a specific type of Bullet class that is used to give damage to all objects in the screen. Its bomb effect is obtained by its specific implementation in update() method which provides the animation.

Weapon, Rocket, MartenGun, MachineGun

Weapon class generalizes the weapon used by the AirCraft and Rocket, MartenGun, MachineGun are the specific implementations of the Weapon. These classes should only override the getBullet class to create specific Bullet objects of the weapon.

BonusObject, EnergyPack, CureKit, RandomWeaponPack

BonusObject is the abstract generalization of the BonusObjects. BonusObjects would provide energy, infection cure and weapon. Specific child classes should override getHealthBonus, curesInfection, getBonusWeapon and update methods to specialize the type of the bonus object. If a bonus object does not have weapon bonus, it should return null for the method getBonusWeapon, otherwise, it should return the specific weapon object.

AirCraft

AirCraft represents the plane controlled by the user. It has an energy level, a number of bombs and infection status. As described in the requirements, if it is infected, in each update() call its energy level decreases.

Its moveAircraft takes mouse position and calculates the new position according to the location difference. Other details are presented in the requirements analysis.

3.2 Package GUI

In Figure 3, attributes and operations in classes of package GUI are presented.