| Return to CIS 300. |
|
The method
should be changed to
public bool CanFireNow() {
return (COOLDOWN == 0);
} public bool CanFireNow() {
return (currCooldown == 0);
}
Inside the method GetAction(GameTime gameTime), the code block
should be changed to
if ((me.UniqueNum + gameTime.ElapsedGameTime.Ticks) % 10 == 0) {
MarkGoalTiles();
move = GetMoveAlongShortestShortestPathToAGoalTile();
} if ((me.UniqueNum + gameTime.TotalGameTime.Ticks) % 10 == 0) {
MarkGoalTiles();
move = GetMoveAlongShortestShortestPathToAGoalTile();
}
For this lab, you will take a game that has already been (hastily) constructed, and make it interesting by adding computer opponents. These opponents must be able to figure out how to move around the game board, acquire targets, fire at other ships, and generally try to win.
You will be designing the AI for the computer opponents. This will be done using a Finite State Machine (FSM) for each opponent. You must choose the nodes to use for your FSM's, direct when the AI shall change between states, and program behavior for each state.
While this may seem overwhelming, we have actually done a lot of the hard work for you already. Furthermore, this is not the only time you will see AI; we will have lectures on this later in the semester. The purpose of this lab is to simply give you enough tools so that you can "fake it" until you learn more.
Once again, this lab is not due during this lab period, but it is to your advantage to work through (and/or learn) as much as you can now, while assistance is immediately available. If you run into problems finishing the lab project later, please feel free to contact a staff member for help (Preferably a programming TA).
File: ShipAILab.zip
We have already set up the game mechanics for you. In this game, the player controls a ShipDemo ship on a large, 2-dimensional game board made out of tiles. You move the ship around the board by using the arrow keys. The spacebar fires photons in all directions from the ship. When a ship is hit by a photon, it gets pushed backward and the tile it used to be hovering over falls out of the board into space. If a ship is pushed by a photon off the board, the ship falls into oblivion and loses the match. The objective is to be the last ship remaining on the game board.
The photons blasting from a ship will be more powerful when the ship is above a "power tile." The power tiles are the blue tinted-tiles. If a ship is above a regular tile, it will fire photons in four directions. A ship over a power tile fires in eight directions.
You should start out this lab by unzipping the source somewhere convenient. You should know how to get this working from the previous lab. If you compile and run the game as-is right now, you'll notice a bunch of ships just sitting around, waiting to be shot off the edge by you. These are obviously the ships that need some intelligence.
There should be a pre-compiled executable binary of an example solution to this lab in the main directory. Run that to get a feel for how hectic the game can get when the computer-controlled ships know what they're doing (or at least look like they do). The example solution is not meant to tell you exactly what you need to make the game like, and it could certainly be improved upon, it is just included to give you a better idea of what this lab is about.
When running, you can press 'R' at any time to reset the game, which may be a time-saver when creating and testing your AI. In addition there should be a pre-compiled executable binary of an example solution to this lab in the main directory. You can run that to get a feel for how hectic the game can get when the computer-controlled ships know what they're doing (or at least look like they do.
Important: The example solution is written in GameX, the engine that this course used before XNA. Note that it looks very different. GameX has many faults, but it is much easier to mix 2D and 3D in GameX than it is in XNA. To simplify the engine, we have made the XNA version of the lab 2D only, so the games will look very different, even though the play is much the same. In addition, the example solution is not meant to tell you exactly how your AI should behave; it could certainly be improved upon. It is just included to give you a better idea of what this lab is about.
As before, the file GameEngine.cs controls most of what goes on in the game. Feel free to check it out if you want to learn about any of the game logic or the graphical effects (which have been considerably reduced for the XNA version of this game).
Other than the main code file, this project contains the following classes:
Note that by forcing all AI control to ultimately be given as a return value in the same way as player keyboard control, we completely avoid the problem of the AI being able to cheat or do things the player cannot. That is, unless you start arbitrarily calling functions that modify the game within the function that is supposedly just calculating the next move, which you obviously should not do.
Take a look at the AIControl.cs file to learn what functions and data members it has available. Of particular note is the FSMState enum. This contains values for all the states used in the example solution. You may change these if you like. Which state a ship is in determines what type of behavior it will follow.
There are also stubbed functions in the AIControl.cs file. Your objective in this lab is to complete all of these functions and make sure the resulting game meets the criteria described at the end of this lab. Alternatively, you may replace these with your own functions if you think you can come up with a better AI or a better structure for your AI, as long as you achieve the same overall goal (again, see below).
You will probably want to start out by deciding how your states are going to work and exactly what the behavior is for those states. Once you have that figured out, try coding the spawning and wandering states, and don't switch out of those states until they work well. Marking the tiles and getting the search for goal tiles correct will take some effort. Once you get each state working, focus on making sure they all work together in an interesting way.
To help you with debugging your AI, we suggest that you play around with Board.DrawTile(SpriteBatch s, int x, int y). Notice how it uses tinting to change the color of a power tile. We recommend that you use similar techniques to keep track of goal and marked tiles. For example, you might want to make goal tiles with a red color, or to draw another, smaller square on top of these tiles. This will allow you to track how your BFS algorithm is working. However, when you submit your project, you should either remove this debugging code from your project, or ensure that all this drawing code is inside a [Conditional("DEBUG")] so that this code does not compile in release mode.
It is important to note that you do need to worry about speed of execution if your AI is causing the whole game to drastically slow down or skip lots of frames. In particular, if you are not careful, breadth-first-search can be quite slow. It is better to take shortcuts that aren't noticeable most of the time than to not take them if that causes the whole game to be unplayable. Also, your AI code should be fairly general (i.e. your AI may not treat the human player as special, it may not assume that the board is always a specific size, it may not assume there are never more than a certain number of ships, etc).
Double-check that your algorithm is implemented correctly. If your AI ever attempts to move over a hole, or if it ever fails to move to a location it could reach to shoot another ship from within a reasonable amount of time, then something is wrong. We often get lab submissions where the AI performs a correct BFS and then ignores the results of the search and just moves in the general direction of the goal, so make sure you don't do that. Also make sure everything continues working normally after you press R to restart - if it doesn't, you probably have a bug.
The real objective here is to make an AI that is tough but still beatable, and thus fun to play against. If your AI poses no threat to a human player, or if it is impossible to beat, you'll probably want to change some things. Also, you should make your AI unpredictable (random numbers are your friend here) even when fighting against itself, which should be entertaining to watch and not reliably result in short-lived battles. Essentially, you are not trying to make the most efficient killing-machine possible; you are trying to make the most engaging and entertaining killing-machine possible, which is harder in some ways and easier in others. Keep working at it, and see what you can come up with!
The only file you need to change is AIControl.cs. The example solution was created without modifications to any other files from the way they are given to you. But you should feel free to edit the AI header file as well if you want to add any more functions or states.
You must also create a readme.txt file that describes all the states your AI uses, including the logic for marking goal tiles and switching among states. Describe the code you added to each function, and why. If you made any new functions or states, be sure to describe them, too. If you made any changes outside of the AI (which is not necessary), you must justify them here. Not all changes are acceptable; for instance, you cannot simply remove all the power tiles to make the AI easier to program. Furthermore, please don't make private variables public to bypass getter and setter functions. Extra-credit type changes are welcome, however.
Finally, tell us your impression of how well your AI works and if you can think of anything it could do better.
To submit, zip up all your code and header files, together with your readme.txt, and submit as "lab2prog.zip" to CMS.
Due Thursday February 7, 2008 at 11:59pm