Project Description

CSCI3290 Spring 2003


The exact nature of the project for this class will be determined by the students and the instructor at the beginning of the semester. However, there are some things that any project will most likely have. I expect that you will write a computer game based on the infrastructure that I have created for thePAD2 class and their semester project. However, because you are more advanced in your CS careers and because you will be working at a group, what you produce will go well beyond what is expected of the PAD2 class and the basic implementation of your game should be completed no later than the midpoint of the semester. From that point you will be able to add some extra functionality and working individually on artificially intelligent agents for the game so that your agents will be able to compete against each other. The game should also include multi-player networking capabilities just so that you get some experience with how that is done in Java.

In order for all of these requirements to be met, the game has to have certain properties to it. I'm going to list here two possibilities that are at opposite ends of the spectrum for what you might do. Notice that human playability isn't even high on the spectrum for what is required. Also, a good project will be one that can be extended in multiple ways so that a basic implementation can be made with minimal effort and many different extensions can be put on it to give it more complete functionality.

Snipes: The game of Snipes was one of the first "graphical" multi-player games. It was also quite widely distributed because it came on all the Novell network installations. It is basically a top down shooter where your objective is to kill all the snipes without letting the snipes kill you. The game consists of a maze that the players and snipes move through. The players and snipes can both shoot though typically snipes don't shoot too much. There are also generators that produce the snipes. You have to kill the generators as well as the snipes and bullets shot by anyone can kill any of the other things in the game so of course it can be fun to shoot the other players just for fun.

After the original game implementation has been done the second half of the semester would be completed by having each of you write your own implementations of generators and snipes to see who can kill off the other players generators and snipe populations without human players in the mix.

Break-up:
Screen & blocks - This involves writing the maze generation. The original game only had one screen, but you could probably make it have multiple screens connected by links.
Players - This starts off as just a simple class that handles keybaord input for a single player game. It becomes significantly more complex when you start to deal with having multiple players at one time.
Snipes & Entities - The original implementation would have some basic AI just to let the snipes wander somewhat randomly and shoot at a player if one comes by. Obviously someone has to write code to do the bullets as well. Each of you will expand on this code to create more efficient "killing machines". As a group you can decide what the rules of communication between snipes has to be.

Enhancements:
You can probably think of lots of these, but some options would be put allow for different types of "snipes" with different generation costs, or to have other things that can be put into the maze. These things might include traps or mines or possibly different types of shooting. It's all up to you.

The advantages of this project are that it is fairly simple and it is very human playable at an early stage. Actually, that last part can be a disadvantage because development often slows down once a game becomes fun to play. The disadvantage of this path is that it doesn't break up as well into multiple pieces so if we have more than 4 or 5 people it will be difficult to give each of your something meaningful to do at all times. Figuring out how to handle multiple players will be a critical piece of the design.

Real-time Strategy: This would be something that might be like the Warcraft series of games or Civilization in realtime. My mental image comes from a game released slightly after Civ called "Master of Magic". In this game the basic implementation is that each "Screen" is the map of a world that has cities on it that can build troops, "Entities", and give you power. Your objective is to wipe out all the cities of the opposing forces. Because it would be played in real-time, having good intelligent agents to direct things will be critical. In line with that, making a good human playable interface could be quite challenging as well and it could easily turn out that the result of the efforts of this will be something that isn't very human playable, but is a good arena for combat between your various AIs.

This project can be broken into many different levels so that you can do extensions to it as you find time and the inclination. One of the other difficulties in this project is game-balance. You will have to decide how much it should cost to produce things based on their relative strengths so that the different AIs can't create super-units without expending a lot of effort in the process.

Break-up:
Screen & blocks - Here again there will need to be some logic written to generate the worlds and maps that the game will be played on. This can have extensions for things like adding different resources and types of terrain that can help players in various ways. Cities could be represented as blocks though entities might be more natural (they could be both because they are interfaces, but it isn't clear that would be ideal).
Players - Unlike snipes, it is not clear that the players here will have any graphical representation. Instead, they will mainly be an AI that interacts with the user mouse clicks and keypresses. They will need to "know" about the cities and units under their control to direct them, but how that is going to be done is a significant design decision.
Entities - All the units will certain be entities. They will be somewhat autonomous, but they should also be able to take directions from the AIs and the player.
AIs - In this game, figuring out how things are going to be controlled is a signficant part of the work. There will be AIs associated not only with the players, but also with the computer controlled opposition as well.

Enhancements:
These are everywhere for this option. One of the things that I see is the ability to "blow-up" on a battle in one part of the map. The screen as a whole will only give you the ability to see "gross" motions across the board. However, the player will probably want to be able to control things closer up for combat. This could be a place where members of the group could get to play with graphics libraries and possibly even the 3D graphics capabilities of Java.

This game can also be extended in many other ways. For example, Master of Magic added a magic system and other things onto the top of the style of game introduced by Civ. You could easily start with a game framework that is very basic like the original Civ and to which you can add more options and flexibility later on.

This idea is probably at the other end of the complexity spectrum. I think it is still likely that you could get sometime like a basic real-time Civ up and running fairly quickly. The biggest difficulty is being able to decide when you should stop trying to add enhancements and just get things to work.

Your decision: The ideas above are just suggestions of things that you might do. What really matters is that you construct a game that can involve multiple players over a network and where you can write AIs to compete with one another. I also recommend that you do it using my framework from PAD2 just so that you can get up to speed quickly but even that isn't a requirement if, as a group, you strongly want to work on something that doesn't fit into it nicely.