Torch the Flag

1. Download this simple Java game: game.zip. To build and run it, do

   javac *.java
   java Game
   




2. 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.)



3. 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 at them.
   • 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 at it.
   • 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.



4. 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:
   • 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.
   You are encouraged to:
   • 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.



5. 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:

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.)

This project will be graded differently than the others. If you spend more than 5 hours working on this assignment, send an e-mail to the grader stating "I spent more than 5 hours working on assignment 8.", and you will receive full credit. If you don't want to spend so much time on this assignment, that's okay, there's another way to get full credit: I will include all of the example agents in the class tournament. If your agent ranks higher than all of the example agents, you will also receive full credit. (Note that beating the example agents is not the same as ranking higher than the example agents. Your agent must perform better in general, not just against them specifically.) If you don't meet either of these criteria, then I will examine your agent manually and assign a score based on my opinion of your effort.

Additionally, the following prizes will be awarded based on your ranking in the class tournament. (The prizes are stacking, such that you will receive all of the prizes below the one for your ranking.) If you rank in the top 5, you must be willing to describe your general strategy to the class.

Hints:

• 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).



• Agents usually die when they are stuck in some slow terrain, so using A* search is a good idea.



• Genetic algorithms have been used by victors in the past.



• 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.