Anti-td-group - Last Assignment built an antitower defence game PDF

Preview

Summary

Last Assignment built an antitower defence game...

Description

UMEÅ UNIVERSITET Institutionen för Datavetenskap Report

August 27, 2018

Project

Applikationsutveckling i Java 7.5p Anti-Tower Defence - Arnolds Revenge Group

1

Name

Elias Åström Moa Hermansson Olle Lundmark Joel Hansson

E-mail

[email protected] [email protected] [email protected] [email protected]

Graders Didrik Lindqvist [email protected], Olof Holmlund [email protected], William Viktorsson [email protected]

Anti-Tower Defence - Arnolds Revenge

Table of Contents

Table of Contents 1 Introduction

1

2 User Help 1 2.1 How to build the game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2.2 How to start the application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2.3 How to create a custom level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.3.2 in . . . . . . . . . . . . . . . . . . . . . . . 2 2.3.3 in . . . . . . . . . . . . . . . . . . . . . 3 2.3.4 in . . . . . . . . . . . . . . . . . . . . . . . 3 2.3.5 in . . . . . . . . . . . . . . . . . . . . . . 3 2.3.6 in . . . . . . . . . . . . . . . . . . . 3 2.3.7 in . . . . . . . . . . . . . . . . . . . . . 3 2.3.8 in . . . . . . . . . . . . . . . . . . . . . . . 3 2.3.9 in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3.10 in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3.11 in in . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3.12 in in in . . . . . . . . . . . . . . . . . . . . . . 4 2.3.13 Order of tags in level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Demands 4 Design 4.1 Units . . . . . . . . . . . . . . . . 4.2 Towers . . . . . . . . . . . . . . . 4.3 Tile . . . . . . . . . . . . . . . . 4.4 Map . . . . . . . . . . . . . . . . 4.5 Threads . . . . . . . . . . . . . . 4.6 Decisions during implementation

4 6 . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. 7 . 8 . 9 . 10 . 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 System Specifications 5.1 Model classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 Tower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.3 Tile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.4 Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.5 Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.6 TowerArea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.7 AreaTowerAi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.8 TileMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.9 Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 System communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Loading a map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.2 Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.3 Spawning a unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Game loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6 Thread specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.1 Threads description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.2 Thread communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Elias Åström, Moa Hermansson, Olle Lundmark, Joel Hansson

i

12 12 12 13 13 13 13 13 13 13 14 14 14 14 14 14 14 15 15 15 15

August 27, 2018

Anti-Tower Defence - Arnolds Revenge

5.7

Table of Contents

5.6.3 Thread safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Javadocs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6 Further development 16 6.1 Creating your own Units and Tiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1.1 Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1.2 Tiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7 Algorithms 7.1 Game Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Move . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Find next tile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Find target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Unit testing and Test Driven Development . . . . . . . . . . . . . . . . . . . . . . . .

17 17 18 18 18 19

8 Manual testing

19

9 Logger

20

10 Media Disclaimer

20

11 Appendices

21

Elias Åström, Moa Hermansson, Olle Lundmark, Joel Hansson

ii

August 27, 2018

Anti-Tower Defence - Arnolds Revenge

1

2

User Help

Introduction

The project assignment was to implement a so called Anti-tower Defence game. The user sends out troops that the computer shoots down. The user has a limited amount of credits to buy troops to send out and for the user to win the game a certain amount of troops needs to reach the goal of the map. The game uses several different threads that works parallel with each other. The game is developed with TDD (Test Driven Design) and JUnit. Version handling done with git. Link to the git repo: https://git.cs.umu.se/oi09olk/AntiTD-group1

2

User Help

2.1

How to build the game

Change the current working directory to the directory containing the file pom.xml. Then execute the following command: mvn clea n pa ck age

This will compile the application into a runnable jar-file at the location target/AntiTD-1.0-SNAPSHOT.jar which contains the application and its required resources.

2.2

How to start the application

To run the compiled and packaged jar-file. Do the following command. java - jar tar get / AntiTD -1.0 - SNAPSHO T -jar - with - d ep en de nc ie s .jar

This will run the game against the default set of levels. It is also possible to play the game with custom levels by passing a command line argument which is an XML file for the custom levels. The following command will run the game with the custom levels contained in the file customlevels.xml. java - jar tar get / AntiTD -1.0 - SNAPSHO T -jar - with - d ep en de nc ie s .jar cus to ml ev el s .xml

Elias Åström, Moa Hermansson, Olle Lundmark, Joel Hansson

1

August 27, 2018

Anti-Tower Defence - Arnolds Revenge

2.3

2

User Help

How to create a custom level

Levels are read from an an XML-file. It has the following format: < levels > < le ve l nam e =" { LEVEL - N AME } " > { LE VEL - DA TA ...} < le ve l > { Op ti on al ly mor e lev els .. .}

Each of these XML-files can contain any number of levels. The name attribute specify the name of the level. The level data consists of more XML tags. • the root tag, must always be present • definition of a new level • how much money the player starts with • how much money the player gains every second • how much money the player gains when a unit manages to reach the goal • how much money the computer starts with • how much money the computer gains every second • how much money the computer gains when a unit gets killed • how much goals the player must score to complete the level • a definintion of a tower area in the level • the tile-map of the level • the tile-map of the level • one row of tiles in the map

2.3.1

Define a new level. Takes the required attribute name which is the name of the level.

2.3.2

in

The amount of credits the player starts with. The only attribute is value which is the number for the variable.

Elias Åström, Moa Hermansson, Olle Lundmark, Joel Hansson

2

August 27, 2018

Anti-Tower Defence - Arnolds Revenge

2.3.3

2

User Help

in

The amount of credits the player get each second in the level. The only attribute is ‘value‘ which is the number for the variable.

2.3.4

in

The amount of credits the player get when a unit manages the reach the goal. The only attribute is ‘value‘ which is the number for the variable.

2.3.5

in

The amount of credits the computer starts with. The only attribute is value which is the number for the variable.

2.3.6

in

The amount of credits the computer get each second in the level. The only attribute is value which is the number for the variable.

2.3.7

in

The amount of credits the computer get when it kills one unit. The only attribute is value which is the number for the variable.

2.3.8

in

The amount of lives the computer gets. The amount of goals the player needs to score to win the game. The only attribute is value which is the number for the variable.

2.3.9

in

Specify an area for turret placement. Has one string attribute id which is used to identify the area. And one number attribute priority which defines how much the computer will prioritize placing turrets in that area.

2.3.10

in

Defines the tile grid for the level. Contains a number of rows of tiles.

Elias Åström, Moa Hermansson, Olle Lundmark, Joel Hansson

3

August 27, 2018

Anti-Tower Defence - Arnolds Revenge

2.3.11

3

Demands

in in

Defines one row of the map. Any number of rows can be specified. But all rows must have the same length. The length is determined by the amount of s in the row.

2.3.12

in in in

Defines the tile at a location in the map. Has one required attribute type which specify the type for the tile. The value is a class-path to a Java class which contains the code for the tile. It also has 2 optional attributes, area and start. The area attribute enables the computer to place turret on the tile, the attribute value is id of a previously with ‘‘ declared area. The other optional attribute start can contain the string true, this means that this tile is where all units spawn. The map has to have one, but not more than one starting tile.

2.3.13

Order of tags in level

In the tags must appear in the following order. • how much money the player starts with (optional) • how much money the player gains every second (optional) • how much money the player gains when a unit manages to reach the goal (optional) • how much money the computer starts with (optional) • how much money the computer gains every second (optional) • how much money the computer gains when a unit gets killed (optional) • how much goals the player must score to complete the level (optional) • a definition of a tower area in the level (optional, can be more than one) • the tile-map of the level

3

Demands • The game should use multiple threads. Done. • The games update frequency should be based on time and not the speed of the computer. Done. • When you win or lose you should have the option to play again or quit. Done. • The GUI should use Swing. Done. • The rendering should be done to avoid flicker. Done. • There should be a menu with: New Game/Restart, Restart level, Pause/Resume, Mute and Quit. Done.

Elias Åström, Moa Hermansson, Olle Lundmark, Joel Hansson

4

August 27, 2018

Anti-Tower Defence - Arnolds Revenge

3

Demands

• There should be a menu with: About and Help. Done. • There should be at least two types of units. Done. • The game should have multiple levels. Done. • The levels should be saved in a file called "levels.xml". The XML should be validated. Done. • Every level should contain regions where the computer can place towers, paths the units can take, special rules for the level such as the amount of units that has to pass through to win. Done. • There should be multiple ways that units can take to the goal. The user should be able to choose in the game. Done. • All results should be saved in a database. Done. • You should be able to use a filename as input to the game. This should load a different set of levels based on the filename. Done. • There should be an interface called landOn that is called when a unit walks on a tile. Done. • There should be a special area implemented except for the ones described above. Done. • There should be Teleporter troops. Done. • The program should be compiled into a jar-file called AntiTD.jar this should be done using Maven. Done. • The project should use Git for version handling. Done.

Elias Åström, Moa Hermansson, Olle Lundmark, Joel Hansson

5

August 27, 2018

Anti-Tower Defence - Arnolds Revenge

4

4

Design

Design

When designing the basis for the game the first couple of things decided were that the game should use the MVC design pattern, the game should use simplistic graphics and simple sound clips and the game should run on multiple threads. Decisions were made about how the classes should relate to each other. See Figure 1. and Figure 2.

Figure 1: Design overview model

Figure 2: Design overview view and controller

Elias Åström, Moa Hermansson, Olle Lundmark, Joel Hansson

6

August 27, 2018

Anti-Tower Defence - Arnolds Revenge

4.1

4

Design

Units

It was decided that units should use an interface or an abstract class. This class should keep track of position, hit points, speed, next position and any other necessary fields. It should also have methods for moving and taking damage. See Figure 3 for original plan.

Figure 3: Design overview Unit

Elias Åström, Moa Hermansson, Olle Lundmark, Joel Hansson

7

August 27, 2018

Anti-Tower Defence - Arnolds Revenge

4.2

4

Design

Towers

It was decided that towers should use an interface or an abstract class. This class should keep track of damage, range, attack speed and position. It should have methods for finding and attacking units. See Figure 4 for original plan.

Figure 4: Design overview Tower

Elias Åström, Moa Hermansson, Olle Lundmark, Joel Hansson

8

August 27, 2018

Anti-Tower Defence - Arnolds Revenge

4.3

4

Design

Tile

It was decided that tiles should use an interface or an abstract class. This class should keep track of if units can walk on it, if towers can build on it and the landOn interface. See Figure 5 for original plan.

Figure 5: Design overview Tile

Elias Åström, Moa Hermansson, Olle Lundmark, Joel Hansson

9

August 27, 2018

Anti-Tower Defence - Arnolds Revenge

4.4

4

Design

Map

It was decided that the map should keep track of an array of Tiles. The other classes in the model should be able to get access to the tiles at given positions. See Figure 6 for original plan.

Figure 6: Design overview Map

Elias Åström, Moa Hermansson, Olle Lundmark, Joel Hansson

10

August 27, 2018

Anti-Tower Defence - Arnolds Revenge

4.5

4

Design

Threads

It was decided that threads should be used for the following: • GUI. • Game logic and rendering. • Sound. • The database. See Figure 7 for original plan.

Figure 7: Design overview Threads

Elias Åström, Moa Hermansson, Olle Lundmark, Joel Hansson

11

August 27, 2018

Anti-Tower Defence - Arnolds Revenge

4.6

5

System Specifications

Decisions during implementation

• 2017-11-12 Xml-maps is created with rows of tiles (see mapformat.xml). • 2017-12-20 The game updating speed should not be dependent on FPS. • 2017-12-20 Frames get drawn independently of game update speed. • 2017-12-20 Pause only pauses game updating, not rendering. • 2017-12-22 Created a seperate frame for selecting maps. • 2017-12-23 Moved the rendering loop from view to getGraphics, sends a finished bufferedImage with the graphics state of the game to view and shows that. • 2017-12-30 Changes to the xml, documented in LEVELHOWTO.md in the repo. • 2017-01-03 Moved all exception prints from console to a logger. • 2017-01-05 Changed the audio to use both floatControl volume and mastergain so that it works on both windows and unix systems. • 2017-01-06 Changed the units so that they use position class and Direction enum to move instead of the old way. Changed the levels so that they are clonable and it clones the level instance each time it is started.

5

System Specifications

The game is built using a design pattern called MVC: Model, view and controller. This means that everything that is shown outwards is done in the View part of the program, all calculations are done in the Model part and the communication between the two are handled by the controller part. This makes the View and Model parts of the program independent from one another and makes development (initial or future) easier. The three parts will have one section each following this one.

5.1

Model classes

The model is the biggest part of the program. It is split up into packages handling different parts of the model. These will follow in this chapter.

5.1.1

Unit

Unit is a cluster of classes centered around the Unit-class. The Unit-class is an abstract class representing a unit. This abstract class contains methods for getting and setting all of the different values of a unit. For example speed, health and armor. It also contains methods to create, update, move and damage. This class is then backed up by subclasses representing different kinds of units. U...