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.
“The Revenge of the Birds” will be designed to be a single player game. And during the design we will try to three goals:
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.
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.
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.
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.
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.
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.
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.
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.
In this section we provide detailed design of the classes and explain the considerations behind the design.
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 Figure 3, attributes and operations in classes of package GUI are presented.
Figure 3. Classes in GUI Package
GUIManager class organizes the shown menus in the main menu screen and itself is a Jframe used to show related panels as a window. According to user clicks in the main screen, GUIManager sets the relevant panel visible. If game is to be started, it hides itself and sets a new PlayFrame object as the current frame. Therefore, it uses almost all other classes in the package.
All of these panels are the parts of the main menus as described in requirements report. According to the requirements specifications, we stated the required swing components required, briefly.
Figure 4. Recep changes settings
In Figure 4, a sequence diagram is given to present the set of operations to open settings panel and change options.