BugBattle — let the games commence!
Introduction
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.
Deliverables
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 Abdalla Osman and Vincent Roberge not later than 13h00 on Wednesday 12 April 2017. This will ensure your program can be integrated to the BugBattle framework for the competition at 13h40.
Submit:
a. As a .zip file:
- 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 .vpp file).
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.
Setup
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 Hunter and SuperPlant provide examples of how one can write a bug within the framework.
Definitions
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.
Tasks
Implementation
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!
Implementation Constraints
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 Creature subclass.
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).
Design Documentation
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.
Mark breakdown
Out of a total of 125, plus bonuses:
- serious attempt at honest
Creatureimplementation:50 - report:
26 - javadoc:
12 - VP-UML documentation:
20 - general code quality:
17 - finish bonus:
5for 4th,10for 3rd,15for 2nd and20for the winner - bonus for well-implemented exploit bug: up to
10