BugBattle — let the games commence!
All term you've been building a version of the BugBattle application. In this lab, your task is simple (yet potentially boundless): build a bug that's better than all the others and achieve World domination.
Submission is in two phases: an initial product after one week, a final product by the date and time specidied on the course website.
The Bugwars! final competition will be held at on the last lab session.
Wednesday 5 April 2017
You must bring at least one initial honest bug implementation with you to the lab period on 5 April 2017 (see below for definitions of honest bug and exploit bug.) The instructors will run blind competitions between bugs from different groups. This will enable you to gauge your bugs' performance without having to worry about other groups seeing your bug's secrets.
You may also bring one or more exploit bug implementations, if you wish. These will be pitted against other groups' exploit bugs.
Wednesday 12 April 2017
Your lab must be submitted by email to
a. As a
- Exactly one competition-ready honest bug implementation; and
- Optionally, one exploit bug implementation.
b. Your lab report, in PDF format. See the lab report requirements below; and
c. Your design model (as a VP-UML
The competition will be held in our usual lab room. The tournament will be done using a single elimination with a consolation game as illustrated here. Each game will consist of a single fight between two creature types. The game will start with 10 creatures of each type. The creatures will be randomly placed on the map. The game ends when one creature type eliminates the other. If the simulation stagnate without a clear winner, the simulation will be run again. If it stagnates again during the second attempt, then winning creature type will be selected based on the number of creatures on the map.
Your bug will battle in an enhanced version of the BugBattle application. It is quite different from previous versions BugBattle you've seen, so you'll need to familiarize yourself with it.
Download the source and UML diagrams (VP-UML, pdf). Import the source into an Eclipse project and generate the javadoc, with a “private” visibility level. Open the Visual Paradigm model file and study both it and the BugBattle javadoc. The classes
SuperPlant provide examples of how one can write a bug within the framework.
Honest Bug. An honest bug works within the spirit of the simulation world, as documented. It uses the documented organs, in the documented ways, and doesn't try to exploit weaknesses or odd behaviours in the framework.
Exploit Bug. An exploit bug is one that either leverages defects in the framework or goes “around” the framework to achieve “unfair” advantage, outside the spirit of the simulation world. If there is any doubt in your mind about whether or not something is an exploit, it probably is an exploit.
Your main task is to design, implement, and document at least one honest bug. A bug that stands a good chance of beating all the other bugs and achieving World domination. An awesome bug!
You may optionally design at least one exploit bug. A sneaky bug. A bug that wins by breaking all the rules!
Your bugs must be subclasses of
Creature and must obey the requirements documented in the class comment for the
Creature class. You must also observe all other constraints or requirements documented in other class comments.
Give your bug a unique class name. The entire implementation of your bug must be contained in a single
.java file. Any
Budder subclasses, other helper classes, or cooperating creature classes must be defined as inner classes of your main
In the class comment, clearly indicate whether the bug is an honest bug or an exploit bug.
You should not modify anything in the
bugbattle.core package (it would be pointless to do so anyway, since during the competition your bug will be executing in a “clean” version of the framework provided by the instructors).
Your bugs must be fully commented in Javadoc including a complete description of the strategy or strategies followed by the bug. It should be clear to a reader, without examining your code, exactly how your bug works and why it works that way.
Use VP-UML to document your design. As a minimum, you must include a diagram that shows the complete structure of each of your bugs, including any helper classes, etc. You must also include at least one sequence diagram illustrating the operation of the
doTurn() method for each bug. If there are several alternative executions of
doTurn() you should provide one diagram for each rather than trying to fit everything on a single diagram.
Each of your diagrams should have notes explaining what the diagram means.
Lab Report Requirements
Your lab report should be readable and self explanatory, including the following sections:
a. An introduction and description of your bugs and other code, to place your work in context for the reader,
b. A strategy section to describe how each of your bugs operates and interacts with its environment, that is, its strategy for survival,
c. A description of the bugs' implementation, including the use of any patterns,
d. If you are submitting an exploit bug, an explanation of the flaws or weaknesses in the framework that you exploited,
e. A description of your testing strategy for your bugs: how did you determine whether your bugs were working correctly?
f. A discussion of the use of patterns in the simulation framework: what patterns are used and where, are they appropriate, and are there other places in the framework where patterns could be usefully applied?
g. A detailed explanation of a new organ that you think would make the simulation more interesting; and
h. A conclusion section.
Out of a total of
125, plus bonuses:
- serious attempt at honest
- VP-UML documentation:
- general code quality:
- finish bonus:
15for 2nd and
20for the winner
- bonus for well-implemented exploit bug: up to