Iteration 1 – Phase 1 – Problem definition
	Iteration 1. 2000 Dec 05 To produce anything It is clear that we need to have a fairly well defined idea of what it is that we want to accomplish. A goal in other words. In order to know how the game engine is supposed to act we really need a problem statement. The problem statement sets the domain within which we are to create our programs. It serves both as a guide and as an insurance policy against feature creep and lost focus. Problem Domain: The project is to deliver a computer system that implements all of the functionality of a common two-person conflict-based (war) board game. The user interface will present a graphical representation of the game map and of the player tokens. It will permit the active player to select and move eligible tokens on the map; to select which of the opponent’s tokens to attack; and to occupy positions vacated by the opponent as a result of successful attacks. The game program will handle recording of the passage of turns; apply any alterations to the game environment based on the current turn; provide for the arrival and departure of tokens according to the scenario schedule; enforce the sequence of player actions within each turn; enforce rules respecting limits placed on the use and movement of tokens; resolve all events requiring a randomly determined outcome; apply the results of all such events and any other player influenced events; permit the permanent storage of turns in progress; prevent player alteration of game events; and determine when the victory conditions of the scenario have been met, and by whom. The system will provide methods of entering, retrieving, and reporting various game state related information.
Problem Domain: The area of concern for the project. Elements that exist outside the Problem Domain may have considerable impact on the solution but themselves remain outside the scope of the project. It is the failure to keep them there that is the cause of much of the unhappiness with system development. Any item that makes the transition into the solution space despite being outside the original project scope does two evils. Firstly it diverts resources away from approved project items, a diversion which is not budgeted. Secondly, it complicates the solution to the problem by introducing new considerations, usually late in the development cycle. Both of these inevitably result in late deliveries, un-met expectations, and unhappy clients.
Home	Previous…	Next...