The project consists of developing an original board game that can be played on the computer. The game is called “When Animals Attack” and is a turn-based strategy game where the object is to build an army of animals from around the world and take over the world. From the user perspective the purpose of the project is to create a fun, challenging game that can be played against other humans or a customizable computer player. From the developer's perspective we want to not only create a game that will be enjoyable but to also create intelligent computer players that will be able to learn how to play the game and improve over time much as a human would. We intend to initially create an AI player using developer-created heuristics and then create a learning AI player that will improve over time. It is our hope that the learning AI will eventually overtake the standard AI player we created first. The learning AI should also help expose weaknesses in the rules of the game that can be overly exploited by a crafty player. This will allow us to modify the game such that no one strategy can dominate others.
As mentioned above the project should provide a fun, original game where players can play human vs. human or human vs. computer, against varying difficulties of computer players. The users should also be able to save and restore games as well as play on randomly generated game boards so that each game is different.
AI – Artificial Intelligence – Computer generated strategy for solving non-predetermined problems. Game strategy in this case.
API – Application Program Interface
GUI – Graphical User Interface
IDE – Integrated Developer Environment
ML – Machine Learning – Artificial Intelligence based on patterns observed in large databases of played games.
VS.NET – Visual Studio dot Net API/IDE
WAA – When Animals Attack – Project
Russell and Norvig. Artificial Intelligence, 2nd Edition Prentice Hall, 2003
Steve McConnel. Software Project Survival Guide, Microsoft Press, 1998
The purpose of this document is to layout for potential users of this project (including the instructor) as well as for the developers how the completion of this project will be approached by team members. It is also meant to give the instructor and team members an idea of what the strategies for completing this project will be. It contains a description of the project organization, a list of team specific aspects, and a preliminary sketch of project requirements.
We intend to follow closely the process model layed out by the text Software Project Survival Guide. This entails the use of the checklists from Table 5-1 on pp. 65. An electronic version of these checklists are available here. This list includes the use of a Software Project Log, updated Top 10 Risks lists, a User Interface Style Guide, a Preliminary and Detailed Software Development Plan, a Software Quality Assurance Plan, a Software Architecture Document, a Software Integration Procedure, and much, much more. It also entails the use of a staged delivery plan. We feel that the use of this process will keep us on track to have a successful project.
We have selected one team member, Kip Armstrong, as the overall project leader. His roles will mainly be to lead meetings, and ensure that everything gets done on time. All major decisions will be made in a democratic process with all team members receiving an equal voice in deciding what should be done. In addition to the overall project leader, once the project has been broken down into modules, each module will have someone responsible for the timely completion and integration of that module.
We have so far defined the following specific roles for each team member:
Kip Armstrong:
Overall Project Lead
Client/Instructor Contact/Liason
Game Designer (rules and such)
Brian Bradford:
Project Site Webmaster
Project Historian
Casey Garner:
Documentation Leader
Documentation Style/Content Manager
Jacob Lords:
Quality Assurance Leader
Version/Repository Controller
Customer: N/A
Instructor: Throughout the course of the project development the instructor will offer constructive criticism and useful suggestion on how the project is coming along. At the completion of the project, the instructor will also play a key role in determining whether the project was successful in achieving it's goals or not.
We intend to make good use of reviews, walkthroughs, inspections, and audits throughout the course of the development of this project.
The Quality Assurance Leader will be in charge of scheduling code reviews to be performed regularly on new written code. The reviews will be conducted by a team member that did not directly participate in the writing of the specified code.
Upon completion of a given module of the project (such as the user interface) we will sit down as a group and take a walkthrough to insure that all problems and issues have been sufficiently covered. As much as possible we will also seek to enlist the aid of outside sources to participate in a walkthrough to offer outside suggestions.
At certain points during the semester the team will request the aid of the instructional staff for the course to perform an audit according to the guidelines given here.
At this time we don't have any specific schedule for when these reviews and audits will take place. However, we will be having a weekly team meeting in which such topics can be discussed once coding has begun.
As mentioned before, we intend to work together as a team in a very democratic process. However, we realize the importance of placing someone in charge of each particular aspect of the project. The overall project leader will ultimately responsible for ensuring that everything gets done in a timely and efficient manner. However, he will also be able to delegate responsibility for specific aspects and modules to other team members. Our team members seem to work quite well together and we don't anticipate any major problems at the moment. Our top priority will be to successfully complete the project in the required time. We hope to learn good teamwork skills through the completion of this project.
We previously chose the name Team Design Bug because we thought it was a pretty clever parody of a similar name. We will likely keep this name for our team – but now that we have a name for our game – When Animals Attack – we may also refer to ourselves by that name.
We have already determined that we will meet weekly as a team on Wednesday from 3:00-4:00. We will also meet at 3:00 on Fridays just before the management meeting to discuss our week's progress.
1 = very experienced 3 = some experience 5 = no experience
|
Skill |
Kip Armstrong |
Brian Bradford |
Casey Garner |
Jacob Lords |
|---|---|---|---|---|
|
Artificial Intelligence |
1 |
4 |
1 |
4 |
|
Machine Learning |
3 |
5 |
3 |
5 |
|
Gaming |
1 |
1 |
5 |
1 |
|
User Interfaces |
3 |
3 |
3 |
3 |
|
Graphics |
4 |
4 |
5 |
3 |
|
.Net Framework |
3 |
2 |
2 |
2 |
|
Databases |
2 |
1 |
1 |
1 |
|
Version Control Systems |
3 |
3 |
3 |
2 |
|
Working as a team |
1 |
1 |
2 |
1 |
|
Working with Children |
1 |
1 |
1 |
5 |
|
Baseball |
1 |
1 |
5 |
5 |
|
|
|
|
|
|
Human vs. Human Games (Hot Seat)
Human vs. Machine Games
Varying Levels of Difficulty
Original Game
Random Game Boards
Game Saving
Game Restoring
Installation Files
Game Files (Game State)
The Product Will Only Work in Windows Operating Systems
The Product Will Require the .NET Framework
The Product Will Not be Networked
Kenny Gee
Setting: Kenny is sitting in his small cubicle inside the Springfield Zoological society office. After a long, hard, morning of shoveling elephant dung and cleaning monkey droppings off the glass walls at the Springfield City Zoo Kenny looks forward to a relaxing afternoon of filling out paperwork and playing his favorite game – When Animals Attack – while his boss is not looking. Here he can take out his frustrations by participating in a veritable animal bloodbath on his personal computer.
Screen: On Kenny's screen is a window containing the WAA game. On the left and bottom of the screen are menus and information panels. On the right is large roundish playing board. The board is made of hexagons with various textures to represent environments found around the world. On the taskbar is a spreadsheet of the annual report of elephant excrements that Kenny can quickly pull up should his boss appear. Kenny takes great pleasure in building up a large army of rhinoceri which he can use brutily slaughter his opponent's defenseless chimpanzees. His only regrets that can not seem to field a force strong enough to drive his opponent's elephants into a deserved extinction.
Data: Joe interacts with the data using a mouse / keyboard combination. He is able to use sound and picture feedback to confirm his data manipulation and receive new data and takes particular pleasure in the pitiful wails of the dying chimpanzees after another successful battle.
Human vs. Human
Game functionality
Smart CPU and Smart Random
Functional AI with two levels of difficulty
All bugs fixed
Pleasing user interface
Formed into installation package.