We propose to design a system with components that incorporate the concepts of intelligent agents, collaboration, and game theory to model a specific domain. These agents will communicate openly with an engine that defines the domain. The domain chosen for this project is Avalon Hill's strategy game "Acquire"; however, the system will be open to the addition of new engines in the form of extensible modules. During play, the agents will pick from a set of heuristics to evaluate the world and decide how to act upon it. In general, the heuristics describe a strategy on how to play the game.
It is necessary to provide a brief description of the proposed sample domain. Acquire is a game whose objective is to build up hotel chains, buying stocks in the chains of your choice and effecting takeovers of neighboring chains. Players make money during these takeovers, also called mergers. The winner of the game is the one who has amassed the most wealth by the time the chains reach a certain "unmergeable" size. Acquire is a strategy-based game, like Chess, rather than luck-based, like roulette. Therefore, brute-force AI searching techniques are not adequate to its solution. Instead, planning and knowledge-based reasoning are more efficient and effective. We plan to build a domain engine that will represent the state of the world and legal actions, or operations, available to the software agents. An intelligent agent is a piece of software with an element of artificial intelligence, that allows the software to either emulate humans or help support them in a digital manner. Any number of agents (the game allows up to six players) will communicate with the engine through a protocol which allows them to send and receive messages regarding their actions and the effect they have on the world, as well as what actions the other agents have made.
The heuristics available to the agents define certain strategies that will help them choose actions during their turn. A heuristic "pool" of sorts will exist, and each agent will use only one throughout the course of one game. Sample heuristics include aggressive strategies, defensive strategies, passive strategies, or combinations thereof. It will be possible to test the strategies against each other in a game where all agents play in a competitive mode. Agents can also compete and collaborate simultaneously. For example, in normal play, agents all compete with one another to win, as only one can win the game. While competing, however, they can also collaborate with other agents to optimize their own position. Because of the time constraints, only a few heuristics will be developed by our team; however, the extensible nature of the heuristics modules will allow the addition of others after the first iteration of the project lifecycle.
Our proposed project is both practical and useful due to its modular architecture. Although the system as we will complete it will be capable simply of playing the Acquire game, our plan is to build the system in such a way that the substitution of other domain engines and/or heuristic strategies will be easily accomplished given the system's API.
Since it was formally introduced by John von Neumann, Game Theory has been used in fields such as Economics and Mathematics as a particular approach to the study of human behavior. A "game" became a scientific metaphor for a range of human interactions in which the outcomes depend on strategies chosen by two or more persons who can have opposite objectives, or collaborate towards a common goal. Therefore, Game Theory provides an interesting method to understand strategic problems of all sorts in a variety of areas such as the financial world, or in national security matters. In choosing more complex game models, one can simulate real-life situations and better plan his/her strategies in advance with no risks or losses. Because of this, the study of Game Theory is not denied its practical value. Game-theory problems have long been acknowledged to be scalable to real-world domains. Ultimately, our system could be applied to such diverse areas as economics, engineering, chemistry, and so on.
The schedule is somewhat dictated by the course. The Requirements document is due on Tuesday, February 20, 2001. The Design document is due on Monday, March 12, 2001. With these concrete deadlines, our team expects to meet twice weekly, at the very least for status meetings, but in general as time for collaborative brainstorming on the design and scheduling of implementation. These meetings are not expected to take the full 1.5 hours every time, but, using that as an estimate, we expect to log at least 30 hours each on this project during the first half (Winter Term).
At the current state of development, where the tasks to be accomplished are not yet defined, we anticipate the responsibilities of each team member to be shared equally. Since the first half of the project will be devoted to design, we envision a great deal of collaborative brainstorming. Writing will be collaborative, but with one person at a time being responsible for pulling the collective ideas together into a coherent document. The other team members will receive opportunities to approve or disapprove of any section or idea they choose, and help with proofreading. For example, a collaborative session was held for this Proposal document, and Lisa pulled the ideas written by each team member together into a coherent document, which was then approved by Luiza and Mike. For future documents, the lead writer will alternate such that everyone will have a chance.
However, we also foresee that, once coding and implementation begins, a division of labor will be necessary. We expect to define this division once the design has been more solidified and we know better what tasks will be necessary.