Torch the Flag
- Download this simple Java game: game.zip.
To build and run it, do
- Become familiar with the basic play of the game.
There are two teams (blue and red).
Each team consists of 3 sprites and a flag.
The objective is to destroy the opponent's flag before they destroy your flag.
The health of each sprite is indicated in a verical bar behind it.
The health of each flag is indicated in the flag pole.
When a flag runs out of health, the game is over.
The sprites can throw bombs.
There is no limit to the number of bombs, but there is a small energy cost for throwing one,
and a short cool-down period before another bomb may be thrown.
There is also a maximum distance that a bomb may be thrown.
Bombs explode on impact, damaging all sprites and flags within their blast radius.
When a sprite runs out of health, it becomes mostly-broken.
Mostly-broken sprites cannot throw bombs, nor can they be damaged further.
Mostly-broken sprites slowly creep back to their flags.
When a mostly-broken sprite reaches its flag, it reassembles itself, but starts again with no health.
The health of each sprite slowly recharges over time.
When a sprite is standing still and throwing no bombs, it recharges faster.
Sprites can travel faster over some colors of terrain than others.
(Reddish hues make it go faster. Bluish hues slow it down.)
- Examine the code.
This game is implemented with model-view-controller architecture. Most of the code is
contained in 3 main files:
- Model.java implements the model. It stores game state, including
the position, destination, and health of each sprite, the health of the
flags, the positions of the bombs, etc.
- View.java implements the view. It takes care of the graphical display.
(A game may be played with or without a view. Games without a view are
typically played much faster.)
- Controller.java interfaces between the game and the humans or software
agents that direct the sprites. Each time Controller.update() is called,
the game advances one time-step.
There are also two very-small files to help glue it all together:
- Game.java contains the "main" starting point for the game.
It begins by constructing two agents, one to control the blue team,
and one to control the red team. You can modify this file to specify
which agents you want to see battle against each other. You can also
specify to perform a "full tournament", which battles every agent
against every other agent (with no view) and ranks them according to
the number of wins.
- IAgent.java defines a Java interface for game agents.
To develop your own agent, you just need to write a class that
implements this interface.
All of the other files implement example agents.
- Human.java implements an agent that takes orders from the mouse.
This lets you, the human, play the game. This is useful for enabling
you to test the behavior of your other agents by manually battling against them.
(This agent assumes it is the blue team--if not, the controls are wierd.)
- SittingDuck.java implements a simple reflex agent. This is
the simplest example agent. It waits for a certain period of time,
then directs every sprite to attack the opponent's flag.
- AggressivePack.java implements a simple reflex agent.
The sprites all band together. They first try to kill off all the
opponents, then they attack the flag. Also, they dodge any bombs thrown
- Blitz.java implements a simple reflex agent.
It charges the opponent's flag, but also throws bombs at any opponents it
passes on the way, and attempts to dodge any bombs that are thrown
- Mixed.java implements a slightly more complex reflex agent.
It assigns one sprite to defend the flag, one to attack opponents,
and one to charge the flag. All of these agents dodge bombs that are
thrown at them.
- PrescientMoron.java is an example agent that utilizes artificial intelligence.
It periodically forks the world to simulate some candidate actions so it can
anticipate the consequences of those actions. However, it currently only uses this
ability to sloppily find its way to the opponent's flag.
- Implement your own agent.
Please keep all the code for your agent in a single file.
Please use your full name for the class name of your agent.
If your name is "John Doe", please name your agent class "DoeJohn", and put it in a file named "DoeJohn.java".
For other classes, please use static inner classes (inside your agent class),
so there won't be any name collisions with other agents.
Please use at least two of the AI techniques we learned this year in your implementation.
To make it easy for the grader to see what you did, I recommend that you put some comments at the top of the file describing what you did.
You might want to start with one of the example agents and improve from there.
Most of the methods your agent will need to operate are defined in Model.java.
You are not allowed to do anything like the following:
You are encouraged to:
- Submit multiple agents with different names.
- Communicate with other agents or other servers during the tournament.
- Instantatiate objects or call code written by an opponent.
- Use reflection to hack the game state.
- Utilize something that would give your agent an unfair advantage over others.
- Search for near-optimal paths.
- Fork the game and simulate possible outcomes in order to decide what to do.
- Evolve meta-parameters for your agent.
- Hard-code clever strategies.
- Make your agent adaptive. That is, note which stategies seem to work, and use them more. Or, behave differently, depending on the local terrain or the health of proximal enemies.
- Don't zip it up. Just submit the one java file that implements your agent.
The autograder will attempt to unzip it, and will fail. Don't worry about that--it still works--I just have not yet gotten around to telling my autograder not to unzip this one.
The grader will aggregate them all and run a tournament.
Click on the "Project submission" link on the main class page to submit your archive file.
If you have any difficulties with the submission server, please e-mail your submission directly to the grader.
Rubrick and prizes:
This project will be graded differently than the others.
The grader will examine your code and determine whether you have intelligently integrated at least two methods that we studied this year into your agent.
Your score will be based on his assessment.
A class tournament involving all of the agents will be conducted.
(A mystery terrain will be used for the tournament, so that you will have to write your agent to be as general as possible.)
Prizes will be awarded based on your ranking in the class tournament.
The prizes are stacking as described below:
|1st place||Bragging rights for ranking first. Plus, your agent code will be included in the kit for future classes (if you agree).|
|3rd place or better||Automatic "A" in the class. (You don't even have to take the final.)|
|5th place or better||Automatic 100% on the final exam.|
|10th place or better||Taking the final exam is optional for you. (Specifically, if your grade in the class is higher when the weight of the final exam is set to zero, you will receive that grade. So, if you are already getting an "A" in the class, there is no need for you to show up to the final exam.)|
|15th place or better||I will waive all the late penalty for your most late project. (But you still have to complete all the requirements for the project before dead day.)|
|20th place or better||I will waive three days of lateness as needed.|
|25th place or better||You will be honored as a victor by having your name read when I report the results of the tournament in class.|
|40th place or better||You will receive full credit for this assignment (as long as you did not plagiarize another submission.)|
|60th place or better||Good job. You can pat yourself on the back.|
To promote generalization, the tournaments will be conducted using a mystery terrain.
The graduate students will compete with the whole class for their rankings.
The undergraduates, however, will be ranked with the graduate students removed.
- If your name is "John Doe", please name your agent class "DoeJohn", and put it in a file named "DoeJohn.java".
For helper classes, please use static inner classes (inside your agent class),
so there won't be any name collisions with other agents.
- You are welcome to modify the game however you wish, but the class tournament will
be conducted without any changes you make outside of your agent's Java file
(unless you send those changes to me and convince me that I should integrate them into my copy).
- The ability to fork the game to simulate candidate short-term objectives is a powerful
tool for making difficult decisions, especially if you accurately anticipate your opponent's behavior.
The PrescientMoron agent demonstrates how to use this tool, although it uses it in a silly way.
- Each agent is given a balance of computation time to use each iteration.
If that balance falls below zero (meaning the agent took too long to make decisions),
then that agent will be skipped until its computational balance becomes positive again.
The allocation is reasonably large, so you should not be afraid to do some computationally-expensive things,
but it might be better to do computationally-expensive things at infrequent intervals.
The balance is capped at about 1 second of computation-time, so at that point, use it or lose it.
For precise details of this mechanism, see Controller.java.
Your agent can query its time balance (see Model.java) to decide whether to perform an expensive
operation, or just use computationally-cheap reflex logic.