CM0112 Programming Project: Java Beetle

CM0112
Programming
Project
Java Beetle
Philip Strong
0807259
Cardiff University
School of Computer Science
BEng Computer Systems
Engineering
Philip Strong 0807259
Table of Contents
1. Abstract ........................................................................................................................................... 3
2. Introduction .................................................................................................................................... 4
3. Software and languages .................................................................................................................. 5
4. Specifications and Requirements.................................................................................................... 5
5. Design.............................................................................................................................................. 6
6. Implementation .............................................................................................................................. 8
7. Testing ........................................................................................................................................... 11
8. Conclusion ..................................................................................................................................... 13
References ............................................................................................................................................ 14
Appendix A - Initial Project Plan............................................................................................................ 15
Appendix B - Project Diary .................................................................................................................... 18
Appendix C -User Guide ........................................................................................................................ 19
Appendix D - Sample Code Listings ....................................................................................................... 25
Appendix E – Images ............................................................................................................................. 28
Appendix F – Initial interface designs ................................................................................................... 33
2
1. Abstract
This report documents the initial research, design and implementation, and conclusion
of creating a Java interpretation of the pen and paper game Beetle.
It was decided to make an application with hand drawn, easy to see buttons, to keep the
charm of the pen and paper game. Additional features were initially planned, however
only multi-round and scoring made it into the final build.
It was concluded that the project was successful, with a base to be built on for further
features, which were not implemented in the given timeframe.
3
2. Introduction
The aim of this project was to create a game inspired by the pen and paper game
‘Beetle’, in the Java programming language. This report documents the design,
implementation and testing, as well as including the user guide, diary and samples of
the code found in the final application. I planned to make the game more advanced and
personalised, whilst keeping the charm of the original pen and paper game.
Using knowledge gained in CM0123 Java, CM0124 Java II, CM0137 Systems modelling
and CM0128 Communication skills and Project planning modules, I have compiled this
document as part of the requirement for the CM0112 Programming project module.
In the appendices are the user guide, project diary, test results, code samples and a copy
of the initial project plan. The initial project plan documents the initial research
undertaken to prepare this project. Throughout this report, it is discussed that several
changes occurred from the initial plan.
There are several reasons to replicate a simple pen and paper based game for the
computer. Often, classic games such as this are readily available, however people do not
hear about them. If we are to make it distributable and downloadable, it becomes
available to everyone, with no preparation necessary. Some games can be tedious and
boring when played with pen and paper, and computerising them can breathe a new
lease of life into them, with a modern interface and playability. New features can be
added to the game to make revive a game, and make it more appealing to a more
demanding younger generation.
4
3. Software and languages

Java is an interpreted, high level programming language. With strong influence from C
and C++, it is compiled to an intermediary byte code, which is then run on a Java Virtual
Machine (JVM). (Elliotte Rusty Harold, 1998)
Java is cross platform, and runs on any system with a JVM, from full computers running
Windows, Linux and Mac OS, as well as smaller devices such as phones, mp3 players and
even microcontrollers.
I will be writing and testing this project in Microsoft Windows 7, and testing in Kubuntu
9.10 (Karmic Koala), using Java runtime environment version 6 update 20 in both.
The application will be written in TextPad 5.3.1. ‘TextPad® 5.3.1 is a powerful, general
purpose editor for plain text files. Easy to use, with all the features a power user
requires.’ (TextPad,com, 2010)
Project management has been catered for in Microsoft Project. I have used this package
to create a Gantt chart, and calculate approximate timings for each task.
4. Specifications and Requirements

The compulsory specifications outlined in the initial project plan are as follows:
The project must:

 Be implemented in the JAVA programming language
 Be for two or more people
 Have a clear user interface
 Have an exit function
 Have a user guide for a high level manager
The user interface must:

 Be clear and usable by younger generations
 Needs to be easy for multiple players to understand
I will explain how the program will be designed to meet these requirements in the
design stage.
5
In deciding the resolution of the game, I had to consider what computers may be
available to the consumer. Web statistics show that in the year 2010, almost all
computers have a minimum vertical resolution of 600 pixels, and a minimum horizontal
resolution of 800 pixels (w3schools.com, 2010). I considered using a higher resolution;
however I decided that it would be unnecessary, as it was not intended to be a full
screen application. My decision would be that my applet would need to be less than
800x600 pixels in size.
My next consideration was the screen format. The current trend of screens is
widescreen. Analysing my peers and family showed that every screen purchased in
recent years has been widescreen. To follow this trend, and fit within my 800x600 size
restriction, I decided that the closest standard widescreen resolution would be
768x480. This would give me more than enough screen real estate whilst being able to
fit on almost every personal computer screen. This will also allow the game to be
displayed on Netbook screens, which are typically 1024x600.
Another specification that I felt would improve usability and enjoyment of the game,
was whether to write it in a multithreaded manner. This was a decision I needed to
make before I started, as changing this half way through would have increased the
difficulty of programming. I felt multithreading would have no disadvantages in the end
product, and may have reduced difficulty in programming in some of the more
advanced functions. Making the game single threaded may have simplified coding
initially, however any advanced features or delays added would have been less clean,
and therefore the game was multithreaded from the start.
5. Design
To meet the specification, I have explained the choices I had when designing the game.
Under each requirement I have posed one or more solutions which are both efficient
and adequate.

o Write an Applet, which would allow the game to be run from within a
browser, but may incur difficulties during implementation depending on
6
the complexity, due to Applet restrictions, which are in place for security
reasons.
o Write an Application, which allows the game to be distributed on
mediums such as the internet, CD, USB memory stick etc. This allows
more functionality, but it is not clear whether this will be required by the
project.
o Allow the user to choose how many players, before the game starts. To
make the implementation clean, allow each player their own class,
containing all information relating to the individual.
o Use the Java Swing package. Several layouts are available, for simple
menu creation ‘FlowLayout’ and ‘BorderLayout’ are usable. Due to the
nature of the game, the ‘null’ layout is ideal for placing the objects
wherever required.
o On all platforms the game was run on, the Java virtual machine offered a
method of exiting, without having to be coded.
o A 6-page user guide is included with the game.
The user interface must:

o The entire interface can be hand drawn on a tablet, and big, clear buttons
can make it simple to see how the game is functioned, especially after
consulting the user guide.
o Show all players on screen simultaneously. This makes it simple to see the
beetle the player is working for, however the screen may look messy with
less players, leaving a large amount of unused screen space.
o Rotate players, showing only the current beetle. It must be clear who’s
turn it is, a bright colour should be used to make it obvious.
7
I had chosen to implement an application over an applet. This was to ensure I did not
have any problems with restrictions in the basic implementation, or in any advanced
features.
My choice to design the interface with a graphics tablet was due to my personal dislike
of the default interface of Java based solutions. This, and using the ‘null’ layout, enabled
me to make the interface look exactly as I wanted.
I chose to rotate the players, to let the game take up less space on screen, and let me use
higher resolution images at the same time. As my application was to have a ‘pen and
paper’ feel to it, the entire interface was black and white. This meant I could merely use
a red circle around the player number to highlight which player was active.
In Appendix F, I have included some initial designs. The pencil drawn designs are
designs that have all players on screen at once, and the rough tablet drawing is a
rotational design, close to the final design.
6. Implementation
The code is split between 4 classes. The class used to run the application is Project.
This contains the game logic and code flow control. The interface is handled by the class
Interface. As the interface is made almost entirely of JLabel and JButton
objects, this class is primarily to hold swing components. The player information is
stored in the Player class. This class holds information about player name, beetle
progress and score. It also has a method to check for beetle completion. The final class is
ActionEventHandler. This class catches all action events, and relays them to the
class they are intended for.
Appendix E shows all the images used to make up the user interface. Appendix E, Fig 1
shows the final design for the completed beetle, before the wings are placed, and
Appendix E, Fig 2 shows the beetle with wings.
8
On start
When the application is started, a new instance of the Interface is initialised. This
class is threaded, and thus it must be set up to act as a separate thread. This is shown in
Appendix D, Fig 1.1. The splash / welcome screen is then called; this is merely an
introduction to the application. The rest of the interface follows in a very similar fashion
to this method, with other objects substituted in place. The code for the welcome screen
is shown in Appendix D, Fig 1.2. Through trial and error, I found that when using
this.setSize(768,480) to achieve my desired resolution, a large amount of the
application was not visible. It appears that this method includes the graphics Windows
includes in the border of the application. To rectify this, and get a true 768x480 pixel
size of the application, I needed to cater for this Windows addition, and therefore I
ended up using this.setSize(782,516).
On dice roll
rollDice() (shown in Appendix D, Fig 2.1) is called when the dice button is pressed.
This action is captured by the ActionEventHandler class. The rolledCorrect
variable is set to 0. This variable is used later to define whether or not the player is
allowed to place a beetle piece.
incrementPlayers() (shown in Appendix D, Fig 2.2) is called, which

increments all player variables, and makes the player index loop.
The updateBeetle(int playerID) (shown in Appendix D, Fig 2.3) method is

called, which updates the player variables. This is done by looping from 1 to 15, getting
the value of whether the player has the particular part or not, and displaying it if the
player has. Before this, the beetle stage is cleared, and all parts set to false. The score
fields are updated, and a check is done to ensure the player hasn’t completed their
beetle.
The program returns to rollDice(), which sets the player number labels to show a
ring around the current player. There is an if statement to place a ring around player 1
at the beginning of the game. The random number generator then picks a number
9
between 0 and 5, and the dice button is set to show the value of the roll. Using the value
of the dice, one of six methods is called, rollOne(), rollTwo(), rollThree() etc.
Game logic
The game logic provides checks and links to make the application play the game. For
each dice number, 1-6, there is a roll and a part method. These methods for numbers
1 and 2 are shown in Appendix D, Fig 3.1. The roll method does checks to ensure the
part hasn’t been selected before for single parts (ie body, head and wings), and ensures
the player hasn’t reached the limit for multiple parts (ie eyes, legs, antennae). If the
player hasn’t placed this part before, then the status is updated, to show:
(playerID) may now place the (part).
For example, if player 1 rolls their first one, the status will be:
Player 1 may now place the body.
If the player has already placed the part, then the status message indicates that the next
player can play.
If the player is allowed the part, the rolledCorrect variable will be set to the part
number. The player may then click on the button which refers to the part they are
allowed to place. This will call the part method for this number, which initially checks
to ensure the player is allowed to place the part. If the player is, it will set the part as
true for that player, update the status and the beetle, and reset rolledCorrect to 0,
to ensure no other player can take advantage of the dice roll.
If the player is not allowed to place any parts, the buttons will not function.
Action handling
As I intended to implement more advanced features, I decided to abstract all action

handling into a separate, threaded class. The code for this class is shown in Appendix D,
Fig 4.1. When an action object is created, I added an ActionCommand. This allowed me
to tell the difference between different events, from different classes.
10
In the end, all of my action based methods ended up in the Project class, so the
benefit was lost. However, this way of abstracting the action handling away from the
body of the code was useful for adding test objects, and having the action handling in a
threaded class meant that if any other class was in a delay routine or under heavy load,
the event would not be ignored.
7. Testing
Testing was done on all requirements. Inclusive of ensuring all requirements were met,
the functionality of the application was tested to ensure all bugs were eliminated.
The following test framework was used to document all tests. Details of the tests can be
found in Appendix H.
Test ID
Test description
Test procedure
Expected outcome Test Outcome
1
2
3
Before testing, a number of issues were discovered. Firstly, an issue was discovered
where the status would not update after every state change. The cause of this was a
missing line of code, where the hideStatus flag was not set. Once this line had been
reinstated, the code flowed fine.
Secondly, it was evident during the implementation that it was very confusing to follow
the game flow, and it was then discovered by playing the game with friends that I had
confused my currentPlayer and nextPlayer variables, and so the beetle being
shown was for the wrong player. This was easy to fix, and now works correctly.
The final issue was that only player 1 was able to score points at the end of the round.
The problem, it turned out, was that the endRound() method was resetting the player
before incrementing the score. This was resolved, and the application was fixed.
11
8. Results
The final product meets the specification provided at the beginning of the project.
Whilst being fun to play with friends, it is quite clear that the game is based on the
original pen and paper based game. When comparing my code with my other offerings,
it is evident to me that my code is fairly lightweight, at only 800 lines. I put this partly
down to using images for the interface, but also down to extensive pruning whilst
implementing. I feel that in writing this application I have managed to capture
everything required and more, whilst not implementing any useless features which will
not add to the experience, just because ‘I can’.
9. Further work
I feel that given more free time, there is plenty of room for expanding this game with
useful functionality. I have added a scoring system over and above the original
specification, however there is clearly more to be had from this application.
A feature I had initially planned to implement was an AI player. Whilst there are still
remnants of this code in the source, it became difficult to implement whilst keeping the
code efficient, and also enabling multiple players from the same program. Given more
time, I feel I could quite happily implement an AI player whilst keeping the code small
and keeping multiplayer functionality. If I were to continue this project, I would also
allow the AI player to ‘miss’ goes to let younger, less skilled players to have a chance,
especially as this game is essentially a game of luck.
Whilst I feel the interface is attractive and funky, I would like to have subtly animated
certain parts, for example transitions and buttons, to capture the attention of the player
for longer. In this day and age, the user expects a more dynamic interface, and my
interface could be construed as old fashioned.
To further improve this game, a feature I wanted to implement was network play. As I
have had experience with networking in Visual Basic 6, I felt this would not be difficult
to code, however time was not on my side, and I had to drop the idea from the final
product.
12
10. Conclusion
The final product meets the mandatory criteria set by the project specification, and can
therefore be considered successful. The game both playable and enjoyable, and captures
the feel of the original game, with a modern, computerised twist.
To further improve the product, I would like to have implemented an AI player, to allow
the game to be played alone, and networking to allow the game to be played by many
simultaneously. A less static interface, with transitional effects and animation would
have further added to the appeal.
The project has been sufficiently documented and specific excerpts of code given to
show the functionality of the program.
I hope that this game can be enjoyed by many, young and old alike.
13
References
Elliotte Rusty Harold, 26th May 1998 [WWW]

<URL:http://www.cafeaulait.org/course/week1/14.html> [Accessed 18/4/10]
TextPad.com, 2010 [WWW] <URL: http://www.textpad.com/> [Accessed 18/4/10]
w3schools.com, 2010 [WWW] <URL: http://www.w3schools.com/browsers/browsers_display.asp>

[Accessed 17/4/10]
14
Appendix A - Initial Project Plan
Beetle Dice Game Project

Initial Project Plan
Overview
The task is to develop a computer implementation of the ‘Beetle’ dice game. I will be applying the skills learnt in my last
semester in communication skills and project management, JAVA 1 and systems modelling.
Problem Breakdown
The game is a simple game usually played by two or more, on paper. The goal is to draw a beetle before .
your opponents. Before you are allowed to start, you must roll a specific number to be allowed to draw .
the body, then following body parts can be drawn when assigned numbers have been rolled. Often the .
numbers are assigned as shown in the diagram.
Similar systems
Cootie
Taken from: http://www.amazon.com/Hasbro-4782-Cootie/dp/B00000IWDO
As far as I can find with my research, the only alternative to the traditional paper
method of playing ‘Beetle’ is an American interpretation called ‘Cootie’. The basic
game is the same, however instead of being played on paper, the aim is to make a
plastic model from individual parts supplied in the box.
This game is obviously aimed at younger children. Bright colours and chunky parts
make the game seem more appealing to children and goofy looking models add to the
charm. I am not keen on the idea of young children playing with small parts however. This game would require adult
supervision to be safe.
I think I can take some ideas concepts from this game in my project. I can use bright colours and charming images to make
the game appealing to younger generations, whilst avoiding the problem of small piece.
Initial Requirements
User interaction
User interaction features from the user must:

Possible addition features which can be implemented if the project is on time:
 Animated images on buttons and other objects 15

 More complex beetle image or an alternative picture

 Option to play with other insects / objects
Functional
This is a high level specification to be used as a guide for the rest of the project. More features may be added however these
must be implemented / followed. The project must:

Possible additional features which can be implemented if the project is on time:
 Multiple games with a point scoring system

 Special dice with body parts on rather than numbers
 Second dice with add, remove, steal etc to allow more competition between players
 Give players mystery cards with forfeit / double or quit etc options
Project Calendar
ID Task name Duration Start date End date Description Predecessor
1 Initial Plan 7 days 25-Jan-10 31-Jan-10 Project plan and initial specifications
Design use case and activity
2 diagrams 4 days 01-Feb-10 04-Feb-10 Model system functions and user interaction 1
3 Design interface 3 days 05-Feb-10 07-Feb-10 Design user interface 2
4 Code basic function 21 days 08-Feb-10 28-Feb-10 Code basic functions to basic specification 3
5 Code interface 4 days 01-Mar-10 04-Mar-10 Code user interface 4
6 Test basic function / interface 3 days 05-Mar-10 07-Mar-10 Test basic function and interface 5
Code advanced function beyond basic
7 Code advanced function 10 days 08-Mar-10 17-Mar-10 specification 6
Test advanced function / whole Test advanced function and complete project
8 project 7 days 18-Mar-10 24-Mar-10 ensuring there are no errors 7
9 User testing 3 days 25-Mar-10 27-Mar-10 Get various users to test and give feedback 8
10 Demonstrate application 1 day 12-Apr-10 12-Apr-10 Demonstration of application 9
11 Report - first draft 25 days 28-Mar-10 21-Apr-10 Create first draft of documentation 9
12 Report - revision 7 days 22-Apr-10 28-Apr-10 Revise documentation 11
13 Report - proof read 5 days 29-Apr-10 03-May-10 Proof read for errors 12
14 Project end - hand in 0 days 03-May-10 03-May-10 Deliver project 13,9
16
Gantt Chart
17
Appendix B - Project Diary

ID Task name Duration Estimated start date Estimated end date Actual start date Actual end date
1 Initial Plan 7 days 25-Jan-10 31-Jan-10 25-Jan-10 31-Jan-10

Design use case and activity
2 diagrams 4 days 01-Feb-10 04-Feb-10 01-Feb-10 09-Feb-10
3 Design interface 3 days 05-Feb-10 07-Feb-10 09-Feb-10 16-Feb-10
4 Code basic function 21 days 08-Feb-10 28-Feb-10 16-Feb-10 25-Mar-10
5 Code interface 4 days 01-Mar-10 04-Mar-10 25-Mar-10 29-Mar-10
6 Test basic function / interface 3 days 05-Mar-10 07-Mar-10 29-Mar-10 1-Apr-10
7 Code advanced function 10 days 08-Mar-10 17-Mar-10 1-Apr-10 4-Apr-10

Test advanced function / whole
8 project 7 days 18-Mar-10 24-Mar-10 4-Apr-10 15-Apr-10
9 User testing 3 days 25-Mar-10 27-Mar-10 n/a n/a
10 Demonstrate application 1 day 12-Apr-10 12-Apr-10 16-Apr-10 16-Apr-10
11 Report - first draft 25 days 28-Mar-10 21-Apr-10 16-Apr-10 26-Apr-10
12 Report - revision 7 days 22-Apr-10 28-Apr-10 26-Apr-10 01-May-10
13 Report - proof read 5 days 29-Apr-10 03-May-10 1-May-10 04-May-10
14 Project end - hand in 0 days 03-May-10 03-May-10 04-May-10 04-May-10
18
Appendix C -User Guide
User guide
19
This guide documents the use of Java Beetle, which is an implementation of the paper game Beetle in
Java™.
The aim of the game is to complete your beetle before your opponent. Each player takes it in turn to roll
the dice, to try and roll a number of a part they have not yet placed.
System requirements:
Computer capable of running the Java™ Virtual Machine
Figure 1 – Splash screen
When the application is first loaded, the user will be shown the splash screen, as shown in figure 1. After
two seconds, the user will see the ‘Number of players’ screen, as shown in figure 2.
Figure 2 – ‘Number of players’ screen
20
After the number of players has been selected, the players must enter their names, on the ‘Player names’
screen, as shown in figure 3. The default names are ‘Player’ and the player number, but it is recommended
that you put your name in to make it easier to keep track of the players.
Figure 3 – ‘Player names’ screen
After entering the names of the players, click ‘Accept Names’. You are ready to start playing.
Figure 4 – Main game screen
Figure 4 shows the main game screen. To begin playing, Player 1 must roll the dice. The dice rolled first
time by clicking the ‘Click to roll’ button.
21
Depending on what number is rolled, the player may be able to place a beetle part. The parts are as
follows:
1. Body
2. Head
3. Leg
4. Antennae
5. Eye
6. Wings
The first part any player is allowed to place is the body. Once the body is placed, the player is allowed to
place the head. To place the legs, antennae or eyes, the player must place the head, and to place the
wings, the player must have every other beetle part. Placing the wings ends the round, and scores 10
points to the player who got the wings.
When the dice has been rolled, the ‘Beetle stage’ will show the progress of the last person to roll the dice,
so the turn does not change until the dice is rolled. Figure 5 shows the screen after the dice has been rolled
for the first time.
Figure 5 – After the dice has been rolled
The players will roll the dice until somebody rolls a 1, when they will be given the opportunity to place the
body. This is done by clicking button 1, with the picture of the body on it.
22
Figure 6 – Player 1 is allowed to place the body
Figure 7 – After the body has been placed
23
Figure 8 – Player 1 with a completed beetle
In figure 8, player 1 has completed their beetle, and can click the dice to start a new round. Their
score will be incremented, and their beetle reset.
24
Appendix D - Sample Code Listings
Fig 1.1 Interface thread initialisation
Fig 1.2 Splash screen
Fig 2.1 Method called on dice roll.
25
Fig 2.2 Code called to increment all players.
Fig 2.3 Updates interface and beetle.
Fig 3.1 Game logic excerpt
26
Fig 4.1 Action handler class
27
Appendix E – Images
Beetle
body.gif antennae1.gif antennae2.gif head.gif
wings.gif leg1.gif leg2.gif leg3.gif
eye1.gif leg4.gif leg5.gif leg6.gif
eye2.gif leg7.gif leg8.gif
28
Dice
dice.gif dice1.gif dice2.gif dice3.gif
dice4.gif dice5.gif dice6.gif
Game interface
1.gif 1select.gif 2.gif 2select.gif
3.gif 3select.gif 4.gif 4select.gif
bodyButton.gif headButton.gif legButton.gif antennaeButton.gif
eyeButton.gif wingButton.gif title.gif
scores.gif
29
Players
1.gif 2.gif 3.gif 4.gif
name1.gif name2.gif name3.gif name4.gif
howmanyimg.gif
playernames.gif
30
Splash
welcome.gif
31
Fig 1 – Final beetle design without wings
Fig 2 – Final beetle design with wings
32
Appendix F – Initial interface designs
33
34
35
Appendix G – System design diagrams
Fig 1 – Use case diagram
36
Appendix H – Sample test data
Test ID 1
Test description Check splash screen is displayed for 2 seconds
Test procedure
1 Splash screen showed for 2 Run application, observe Splash screen was displayed
seconds time splash screen is for 2 seconds
shown
Test ID 2
Test description Ensure splash screen shows the correct image
Test procedure
1 Image shown is ‘welcome.gif’ Run application, observe Correct image displayed
image that is displayed
Test ID 3
Test description Ensure all images load on the player select screen
Test procedure
1 All images show Run application, observe Images are displayed
that images are displayed
Test ID 4
Test description Check layout of buttons on player select screen
Test procedure
1 Title is at the top, buttons are Run application, observe Layout is correct
in a row below layout
Test ID 5
Test description Ensure button press initialises the correct number of players
Test procedure
1 Command line will display Add System.out.println Correct number of
and output as many times as debug output to Player commands shown
the number of players class
clicked
2 Correct number of player Click through to next Correct number shown
name fields will be shown screen, view number of
player name fields
37
Test ID 6
Test description Ensure all images load on the player names screen
Test procedure
1 All images show Run application, observe Images are displayed
that images are displayed
Test ID 7
Test description Check layout of text fields on player names screen
Test procedure
1 Fields are equally spaced, Run application, observe Layout is correct
one per player layout
Test ID
Test description
Test procedure
1
2
3
38

CM0112 Programming Project: Java Beetle

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

CM0112 Programming Project: Java Beetle

Cargado por

Copyright:

Formatos disponibles

CM0112

3. Software and languages

4. Specifications and Requirements

The project must:

The user interface must:

 Be implemented in the JAVA programming language

The user interface must:

incrementPlayers() (shown in Appendix D, Fig 2.2) is called, which

The updateBeetle(int playerID) (shown in Appendix D, Fig 2.3) method is

(playerID) may now place the (part).

Player 1 may now place the body.

As I intended to implement more advanced features, I decided to abstract all action

Elliotte Rusty Harold, 26th May 1998 [WWW]

TextPad.com, 2010 [WWW] <URL: http://www.textpad.com/> [Accessed 18/4/10]

w3schools.com, 2010 [WWW] <URL: http://www.w3schools.com/browsers/browsers_display.asp>

Appendix A - Initial Project Plan

Beetle Dice Game Project

Taken from: http://www.amazon.com/Hasbro-4782-Cootie/dp/B00000IWDO

User interaction features from the user must:

 Be clear and usable by younger generations

Possible addition features which can be implemented if the project is on time:

 Animated images on buttons and other objects 15

 More complex beetle image or an alternative picture

 Be implemented in the JAVA programming language

Possible additional features which can be implemented if the project is on time:

 Multiple games with a point scoring system

ID Task name Duration Start date End date Description Predecessor

3 Design interface 3 days 05-Feb-10 07-Feb-10 Design user interface 2

5 Code interface 4 days 01-Mar-10 04-Mar-10 Code user interface 4

10 Demonstrate application 1 day 12-Apr-10 12-Apr-10 Demonstration of application 9

12 Report - revision 7 days 22-Apr-10 28-Apr-10 Revise documentation 11

14 Project end - hand in 0 days 03-May-10 03-May-10 Deliver project 13,9

Appendix B - Project Diary

1 Initial Plan 7 days 25-Jan-10 31-Jan-10 25-Jan-10 31-Jan-10

3 Design interface 3 days 05-Feb-10 07-Feb-10 09-Feb-10 16-Feb-10

4 Code basic function 21 days 08-Feb-10 28-Feb-10 16-Feb-10 25-Mar-10

5 Code interface 4 days 01-Mar-10 04-Mar-10 25-Mar-10 29-Mar-10

6 Test basic function / interface 3 days 05-Mar-10 07-Mar-10 29-Mar-10 1-Apr-10

7 Code advanced function 10 days 08-Mar-10 17-Mar-10 1-Apr-10 4-Apr-10

9 User testing 3 days 25-Mar-10 27-Mar-10 n/a n/a

10 Demonstrate application 1 day 12-Apr-10 12-Apr-10 16-Apr-10 16-Apr-10

11 Report - first draft 25 days 28-Mar-10 21-Apr-10 16-Apr-10 26-Apr-10

12 Report - revision 7 days 22-Apr-10 28-Apr-10 26-Apr-10 01-May-10

13 Report - proof read 5 days 29-Apr-10 03-May-10 1-May-10 04-May-10

14 Project end - hand in 0 days 03-May-10 03-May-10 04-May-10 04-May-10

Appendix C -User Guide

Figure 1 – Splash screen

Figure 2 – ‘Number of players’ screen

Figure 3 – ‘Player names’ screen

Figure 4 – Main game screen

Figure 5 – After the dice has been rolled

Figure 6 – Player 1 is allowed to place the body

Figure 7 – After the body has been placed

Figure 8 – Player 1 with a completed beetle

Appendix D - Sample Code Listings

Fig 1.1 Interface thread initialisation

Fig 1.2 Splash screen

Fig 2.1 Method called on dice roll.

Fig 2.2 Code called to increment all players.

Fig 2.3 Updates interface and beetle.

Fig 3.1 Game logic excerpt

Fig 4.1 Action handler class

body.gif antennae1.gif antennae2.gif head.gif