CompSci 108 - Fall 2009 : VOOGA

Introduction

Game Kat is a gaming engine that will allow users to play a variety of fun games, as well as program their own games or add on to current games. Games in this system include Breakout, Kat Cannon, and Race Kart. These games incorperate a Physics Engine and Networking. In addition, users will be able to either pause their games or save their games and resume them later. Game Kat also features a high score list. For novice programmers, there is an environment that walks through the steps of game development using our engine.

Team Members

Daphne Ezer - de22@duke.edu

Daphne is primarily a "backend" worker. She will create the universal design that all the games draw from, mostly in interfaces and abstract classes. Secondarily, she will write the general sections in the Artifact and API and create a physics engine to be used for Race Kart and Kat Cannon.

Kevin Jang - gj4@duke.edu

Kevin will be primiarly in charge of creating the Breakout game. Since that game will come first, much of how he chooses to refactor it will play into how the game desisn architecture will be structured in other games. His second reponsibility is to debug and document the breakout game.

Jimmy Shedlick - jps26@duke.edu

Jimmy is primarily in charge of creating the Race Kart game. This game will use networking so he will be working on getting that set up and implemented as his secondary responsibility. He will debug and provide documentation on the Race Kart game. As a side note he will also create and manage the repository.

Greg Kerzhner - gik@duke.edu

Greg will be primiarly in charge of creating the Kat Cannon game. This includes debugging. His secondary responsibility is to provide documentation on the Kat Cannon game and work with Daphne on the physics engine.

Elizabeth Liang - ewl6@duke.edu

Liz is in charge of the main GUI for the games. Secondarily she will be compiling information on the webpage and making sure the time log is created and used. She will be responsible for creating the level editor. She will also be on hand to create graphics for the games.

Team Design

GameKat Arcade

The main interface will launch when the program is run. It will show the games inside the arcade (breakout, katcannon, and racekart) and give the option of starting a new game for each. These components wil be housed inside a game unit and the main frame will display these units. There will be updated highscores for each of the game. The preferences can be set so that you can choose how many highscores to display. The file menu will allow the user to close the arcade and learn more about the program (version number, developmers, etc.). The settings menu will allow the user to change settings such as the language or mute the sound. The help menu will link to the different rules and controls of each game.

```
abstract class Arcade:
```
Contains games
```
class GameKatArcade extends Arcade:
```
Specific instance of our Arcade.
```
class ArcadeView extends JFrame:
```
Displays the arcade, holds the menu.
```
class ArcadeMenu extends JMenu:
```
Menu for the arcade.
```
abstract class Command:
```
abstract class for commands (start button, file menu).

If there is time, we would like to implement a web-based arcade. The games will most likely have some elements taken out in order to be made into an applet but the idea is to create a launching page to just play the game online and connect it to this website. The appeal of that is so others can get a sense of what the games are like without having the java code.

Game Engine

The basic engine itself will include the following classes/interfaces:

```
class Game:
```
contains all the levels and controls the flow of the game

General Game Elements

```
class Level:
```
contains initial positions of GameComponents and any behaviors unique to that level
```
abstract class GameComponent:
```
an object that is associated with an image and can be drawn
```
abstract class Movable:
```
anything that can move and handle collisions
```
abstract class Controllable extends Movable:
```
any Movable object that can be controlled by the user
```
enum PhysicsFunctions:
```
contains functions to be used by a physics engine

Implementation Example:

```
KatCannonLevel extends Level
```

Kat extends GameComponent extends Movable

Cannon extends GameComponent extends Controllable

Breakout

Our Breakout will have the following characteristics:

At the starting position, the ball will stay on the paddle so that a player can choose where to start bouncing the ball.
There will be three types of blocks: blocks that are broken at the first hit, broken at the second hit, and broken at the third hit.
Some of the blocks will release upgrader/downgrader chances upon being broken.
The upgrader/downgraders will deal with changing the paddle's speed, length, moving directions of the paddle, number of balls, ball's speed(no acceleration), ball's power, and number of lives.
The angle at which the ball bounces off the paddle will be adjustable by the player: the bouncing position at the paddle will determine this.
There will be many different difficulty levels. Once all the blocks are cleared, the player will move on to the next level with different initial layout of the blocks.
The score will be tracked based on the number of blocks broken and the time taken to finish a level.
Record time and record score will be stored in history.

The design of Breakout will follow the general design of our program. The game will be run on top of a background scenery that is not involved with the actual game. It will be divided into parts that are permanently set (i.e. the bouncing behavior of the ball and number of hits to break a block) and parts that are constantly updated throughout the span of each session of the game (i.e. the figure/speed of the paddle, figure of the ball/blocks. layout of the blocks)

Example Scenerio:

The ball hits the last brick, causing it to disappear, a new level to be loaded, the ball and paddle to be reset, and the game play started again. It should be clear from this description which objects are responsible for completing each part of the task.

In Breakout, the Game class will keep track of how many bricks are left in each session. The zero number of bricks will be an indicator for Game class that the current level is finished and it should set up the next level. Game class accomplishes this by calling the Level class, which contains initial positions of GameComponents and any behaviors unique to that level. In breakout, the initial layout of the bricks and velocity of the ball will be different in each level, and thus will be defined in Level class. Also, once all the bricks are gone, Game class will clear the current state of balls (i.e. number of balls, velocity of the ball) and paddle so that Level class will recreate them by calling constructors BouncingBall() and Paddle(), both of which implement Controllable and extend GameComponent and, by default, start at the center with zero velocity. Notice that BouncingBall class also implements controllable because a player can technically move it to either direction along with the paddle before it is thrown. Each level of the game will run on different backgrounds, also determined by Level class. Once the new level is loaded, the KeyListener of Canvas class is ready and a player can start the game.

Detailed Design:

The BreakoutLevel will include the following classes:

```
public class BreakoutLevel extends Level
```
This class extends Level class and overrides the method levelCleared() by its own levelCleared() method that returns true if all bricks are removed. In order to accomplish this, this class checks whether there is at least one brick left in myComponents list in Level. It not, levelCleared() is true.

Subclasses of GameComponents are as follows:

```
public class Paddle extends ControllableComponent
```
Since paddle is a controllable object that can be moved either left and right by a user, it implements Controllable and thus has a forceMove method. The Command classes needed for paddle are moveRight and moveLeft. Its collisionActions are those associated with its states such as its speed and length that need to be updated when collided with a power-up.
```
public class Ball extends ControllableComponent
```
This is a controllable object because, although the ball is mostly uncontrollable in the game, it has one command 'Kick' that needs to be called at the beginning of the game. Initially, it stays on paddle until a user hits space to kick the ball off the paddle and start the game. Thus, its initial position is set equal to the center of the paddle, and also has isOnPaddle() method that returns boolean value depending on whether its vertical velocity is zero. If the ball isOnPaddle() is true, the ball will not be included in collision checking because there will be no collision associated with the ball. The only relevant collisionAction of this class is bounce.
```
public class Brick extends Collidable
```
Brick is a collidable object because it can either stay static or move horizontally bouncing off the walls. The initial layout of bricks varies depending on the level, which is preset in XML, along with other initial states of game components. The collisionAction associated with Brick class is to decrease health and disappear. Upon colliding with a ball, it checks whether its health is greater than 1. If so, it decrements its health by one and otherwise it disappears from the game environment. Everytime its health is updated, the brick changes its image to display its current health to the user. If its health reaches zero and disappears, the brick releases a powerUp randomly at 50% chance.
```
public class PowerUp extends Collidable
```
PowerUp is a collidable object because it can collide with a paddle. Upon collision, it calls an appropriate collisionAction depending on its type. The type is an enumerator in PowerUp class that consists of speed-up, length-up, points-up and extraball. Therefore, the class has a getType and setType method to handle different types. The setType() method is a private method called within its constructor that randomly sets its type. When it collides with a paddle, the collisionAction updates the environment accordingly. For example, it can increase the speed or length of the paddle, or add extra points to the score.

Kat Cannon

Our Kat Cannon game will have the following characteristics:

The game has two distinct stages, the first being controlled by the user and the second random. The first stage is the INTRO stage and the second stage is the MAIN stage
In the first stage, the user first selects an angle of the cannon.
The velocity oscillates from high to low and is chosen when the user hits space. At this point, the cat flies out of the cannon.
After the cat flies from the left corner of the screen to the horizontal middle of the screen, the intro stage is over.
During the main stage of the screen, the cat stays in the horizontal middle but can move up or down. Motion is shown by objects moving from right to left on the screen in relation to the cat
There will be two types of objects, objects that help the cat keep moving and objects that slow down the cat, both extending immovable. Helper objects will be trampolines or bombs that launch the cat higher into the air and speed up its velocity. Harmful objects include patches of glue or cactuses and will slow the cat by decreasing its velocity or instantly killing it.
The game ends when the cats velocity is zero.
The score will be determined by how far the cat traveled.

The Game KatCannon will be run on top of background scenery that the cat will not interact with. The game has two major components, ones that are set once and once that are updated continually. The intially set component is the cats intial velocity gathered from the user selecting a direction and speed. From this point on, the cats velocity continually changes as it encounters objects. The user has no more input and the cat evenually stops and dies.

The katCannon game will include the following classes:

class Kat extends GameComponent implements Movable:

Represents the cat flying through the game

```
class Cannon extends GameComponent implements Movable:
```
Represents the cannon that determines the cats initial velocity
```
class KatGame extends Canvas:
```
Controls the flow of the cat game
```
class Track:
```
Holds all the obstacles the cat will encounter throughout its flight.
```
abstract class Obstacle:
```
Represents an object the cat will encounter during flight
```
class Helper extends Obstacle:
```
Represents a helper object that increases the cats velocity and prolongs its life
```
class Obstruction extends Obstacle:
```
Represents an object that will slow the cat down or kill it

Race Kart

Our Race Kart game will have the following characteristics:

A car can be controlled by the user using the arrow keys.
There will be networking so multiple players can connect into a single race with separate cars.
A track editor will be used to create basic tracks which can be saved and raced on.
A TrackPiece object defines a section of track, and the collection of these objects defines the course.
The physics engine will use constants which can be easily modified for different scenarios (such as making a car with a higher top speed).
The winner is determined through a collision with a finish line object, which will be at the end of the track.
Chat is implemented so users connected to the same server can communicate.
Other goals include making a championship with different tracks with a modifiable points system.

The design of RaceKart conforms to the design of our program with modifications made to support networking. The RaceKart class opens a panel which allows the user to host a race or join a race thus starting a server or connecting to one. Cars are moved and drawn to the screen based on whether they are controlled by the user or are an opponent's car, and collision detection is done on the user's car based on these opponents and the track. The Track is a collection of TrackPieces which form a loop, so multiple laps can be completed. Then, the winner is determined to be the driver who completes this course in the least time.

The RaceKart game will include the following classes:

```
public class RacingGame extends Game
```
A specific type of game which overrides the update() method, paintComponent() method, and the internal Screen class to create a racing game. Additionally, methods are added to support networking, and the Car and Track objects are contained within this class.
```
public class RacingOptionPanel extends JPanel
```
This creates a tabbed panel allowing the user to create a server or connect to a server. If a server is created, the client then connects to the server through “localhost” while the server runs in the background accepting connections from other users. This is integrated into the GUI through RacingGame, which has a JSplitPane with the option panel on the left and the Screen on the right.
```
public class RacingServer
```
This class accepts connections from users and has a list of input streams and output streams. At each iteration, it combines the data from each input stream and outputs the combined data to each output stream. This allows information sent from each user (i.e. the position and direction of that user’s car) to be compiled and sent to all other clients.
```
public class Track extends Level
```
This class extends the Level class and overrides the method levelCleared() by its own levelCleared() method that returns true if the finish line is crossed. Additionally, it contains a list of TrackPieces which defines the actual circuit.

Subclasses of GameComponent are as follows:

```
public class Car extends ControllableComponent
```
The car is controllable by the user through key presses which accelerate, decelerate, or turn the car. The physics specific to the engine determines how this input changes the direction and velocity of the car, stored in a Movement object. Additionally, the forceMove() method is implemented for opponent cars, since this data is read in through networking and the location of each opponent must be set at each step based on the transmitted location and direction.
```
public class TrackPiece extends GameComponent
```
A specific type of GameComponent which has a draw() method accepting arguments for a focal point and screen size. Based on this information, a shift in pixels is determined for both the x and y direction so that the components directly around the focal point are drawn to the screen. In this implementation, the focal point will always be the user’s car, so the components immediately surrounding the user’s car will be drawn to the screen. This gives the appearance that the user’s car is moving on the track.
```
public class TrackPieceStraight extends TrackPiece
```
A particular type of TrackPiece which has a location, size, 2 side walls, and direction. This is drawn to the screen as a straight section of track
```
public class TrackPieceCorner extends TrackPiece
```
A particular type of TrackPiece which has a location, size, 2 side walls, radius, and direction. This is drawn to the screen as a curved section of track.
```
public class Wall extends Collidable
```
An object that defines the edges of a TrackPiece which cars can collide with. The results of a collision with a wall are determined by the physics engine. Additionally, this also implements the draw() method based on a focal point and size, so that the walls are drawn along with the TrackPieces (since they are created as objects by TrackPiece).

Project Diagram

GUI/Model Interactions

Select and initialize game:

The arcade viewer will contain a list of all the games available, as read in from a resource file. Each Game will contain its icon image and the file name of the high score file, both of which will be accessed by the Arcade in the initial display. When the user clicks the button corresponding to the game, the Arcade will tell the Game to start() and will place the Game (which will be a JPanel) in a new frame. Each game will contain a list of Levels which will be loaded when the Game object is initially constructed, so when the Arcade requests that a new game start, it will set its current level to 1 and tell the level to begin. The Level contains a list of all its components and will initialize the actions of all its components. The Game's paintcomponent method calls the Level's draw method, which calls draw on all its gameComponents.

Control an object on the screen:

We will have a package of Command objects that associate different key actions or mouse actions with particular outcomes. These will be stored in a map in the Frame containing the Game and will be accessed by reflection/resource bin. When an action is registered, a copy of this Game will be sent to the instance of command (we are considering adding a layer of abstraction here to prevent the Command from accessing all the methods of Game). The Command will do the appropriate action on the Game.

Go to the next level:

Whenever the screen is re-drawn, the isFinished() method will be called on the level. If the level isFiniahed, then the next level is made the currentLevel and this action in inititalized.

Win the game:

If there are no more games to load, a dialog box will be displayed saying that you won the game.

Lose the game:

Whenever the screen is re-drawn, the isLost() metod of level will be called. If the level is lost then the user will be notified.

Report the high scores:

When a game is won or lost, the Game (which has been maintaining the score) will tell the user if the score is greater than the current high scores (as read from a file) and will re-write these scores to the file.

Detect and handle collisions:

We will have a package of CollisionActions that represent things that happen when two gamecomponents could collide. When the objects are updated and redrawn on the screen, the Level will check to see if any movableComponent has had a collsion with a different gameComponent using the MovableComponents hasCollided method. If there is a collision, the Level will send a safe list of all the components, in addition to a designation of the object that was collided with, to the GameComponent, which will decide which CollisionAction it should send that information too. The CollisionAction will take that information and update the gameComponents appropriately.

Level Editor

This GUI will generate a list of gameComponents, which will be changed into an XML document by the XMLWriter class. The name given to the level will be added to the game's level file, so when the game is read, it will know where to find the new Level's xml document.

The design for the level editor of breakout is shown above. There are three general components: a menu bar at the top, a side panel, and the work area shown in white. This will be the case for the level editors of all the other games though what is in each section will vary to better suit the needs of each game.

The main menu bar has three headings: "File" contains options to start a new level, load a level, save the current level, and quit. "Advanced" will be where other options for level customization are avaiable. It is from this panel, for example, that the user would be able to change the ball speed or the frequency of powerups. We chose to implement this in a sepearate heading since these are options that should be set only one time for each level, not as it is being built, and will help seperate the more novice level designers and yet still allow advanced designers to customize more aspects of their level. The final option in the menu bar is "Help" which contains information about how to use the level editor.

The side panel is loosely broken down into three sections. The Game Component section at the top will show images of the avaiable game components that the user can add to the level. Clicking on the add button will create a new instance of that game Component and add it to the working screen (and list of gameComponents). The information panel will show the current pixel location of the mouse on the work screen as well as the name of the object if the mouse is currently dragging an object. The lower portion of the side panel contains two buttons. One labeled "undo" will remove the last element in the list and effectively "undo" the last move. It can be clicked until there are no more items in the gameComponent list. Clicking on "Test" will open up a new screen with the level playing 'live' as if it were in an actual game. This allows the developer of the level to test frequently and with ease as he/she is designing the level.

The working area will show a mock up of the level that the developer is creating. Some objects such as the ball and paddle will be there at the creation of every level and cannot be removed or clicked on. An example of this is the ball and paddle in breakout. They will start in the center of the screen and cannot be manipulated. The blocks however can be added and once added, the user can cick on them and drag them around, releasing when it is in the desired position. This will update the gameComponent list and move that block to the end of the list. Blocks can be deleted by dragging them off to the left of the screen.

Task List & Estimated Time Usage

Model (10)

Create Interfaces/Abstractions
Implementation
Testing

Breakout (20)

Refactor Current Code
Add Extensions/Debug
High Score & Timer
Multiple Difficulty Levels
Graphic Updates
Applet
Level Editor

RaceKart (40)

Driving Implemented
Physics
Collisions
Networking
Course Design & Timer
Debug
Levels
Extensions/Settings
Course Editor

KatCannon (30)

Cannon and Cat
Random Elements
Course
Animation
Debug
Score/High Score
Manipulate Settings/Extensions

Main GUI (20)

Create Abstraction
Create JFrame Viewer
Updated High Scores
Fill in Menus
Graphics
Website Implmentation

Documentation (37)

Website (20)

Create Website
Initial Design Notes
Design Document 1.0
Design Document 2.0
Website Portal to games
Final Design Document

Project Artifact (3)
API (5)

Changing Settings
Adding Graphics
Adding a New Level
Adding a New Game

Java Doc (2)
Presentations (7)

Demo 1
Demo 2
Public Demo

Total Estimated Time: 157 Hours

Progress Log & Timeline

Monday October 26: Initial meeting, talked about the webpage and finialized the roles and extensions we would be aiming for. Started talking roughly about the design. Came up with a team name. 1 hour

Tuesday October 27: Liz worked on the website. Daphne sent in information for the intro, vision, and basic classes. Kevin sent in the paragraph for the breakout game. Jimmy sent in the paragraph for the Racing game. Liz wrote the progress log and the team responsibilities as well as formatted everything. Liz also created the time log document. Jimmy added basic classes for the racing game including Car and RacingGame. They will be changed later to extend abstract classes/interfaces. 4 hours

Tuesday October 27 - Initial Web Page

Wednesday October 28: Jimmy updated physics, implemented basic collision detection, and created the TrackPiece class. 3 hours

Friday October 30: Daphne added basic abstractions- Level, GameComponent, Movable, Controllable, and PhysicsEngine. Jimmy implemented networking, the RacingServer class and RacingOptionFrame to setup connection through the GUI. Unlimited users can now connect to the server and drive around the screen in RaceKart. 7 hours

Sunday November 1: Team meeting. Discussed what we need to do and assigned tasks in light of the design version due monday. Updated what progress had been done and made sure everyone was connected to the respository. Demo'd the net working component of Jimmy's came with 3 cars. 2 hours

Monday, November 2 - Team design version 1.0 and Estimate

Monday November 2: Liz updated the website and created a class chart. 2.5 hours

Tuesday November 3: Jimmy rewrote the networking code so that it uses reflection to call methods based on the current state of the program. He also updated classes to extend/implement the Engine, and moved everything to the RaceKart package. 3 hours

Wednesday November 4: Jimmy added chat client, updated graphics for the pane on the left of the screen (user input). 2 hours

Friday November 6: Jimmy added the option to choose color of car, basic collision detection codem, a ResourceManager which can be used to read in Strings for all files, and a text file which maps car colors to files. 2 hours

Saturday November 7: Jimmy changed to Collision code and created of Collidable class in Engine which is extended by Cars and TrackPieces. 2 hours

Sunday November 8: Daphne worked on the Engine. And Liz/Daphne/Kevin met to work on the Presentation. 9 hours

Monday November 9, in-class - Program version 1.0

Wednesday November 11: Daphne began to work with the xml level editor. 4 hours

Thursday November 12: Liz updated Sophia (TA) on progress.

Friday November 13: Jimmy made changes to draw track to screen: TrackPieceCorner and TrackPieceStraight extend TrackPiece; draw methods updated to take a focal point and screen size; focal point is location of user car, so all objects are drawn relative to the the user's car in the center of the screen. 4 hours

Monday November 15: Daphne made basic j-unit tests to test game engine. Team met to review design and update each other on progress. Suggested some changes to the API and drafted initial design document based on the idea of creating a tag game. 4 hours

Monday November 16 - Team Design version 2.0

Monday November 16: Kevin updated the classes for breakout, Daphne completed a draft of the api (click on the api link) and Liz updated the website. 3 hours

Thursday November 19: Team meeting to discuss level editor design and set some internal deadlines. Liz worked on a mock up of the level editor GUI. 2 hours

GameKats