SCORE Project: DRisk
Title: A Dynamically Configurable Risk Game
Proponent: Nazareno Aguirre
Risk is a turn-based board game, in which 2 to 6 players fight over the occupation of 42 territories in a political map, trying to achieve a secret mission that generally requires the control of the territories in the map.
Risk has several known playability limitations. One such limitation is that the map configuration is rigid, in the sense that both the number of territories and the neighboring relation between territories (which determines how the attacks between territories can be performed) are fixed for all game instances. Another limitation is that the granularity of the map (in particular, how many territories constitute it) is also fixed, making some game instances very lengthy, especially when a small number of players is involved.
In this project, you will develop a highly configurable web based client server version of the Risk Game, that overcomes the above mentioned limitations.
Project Description
DRisk is a highly configurable computer based version of the Risk game. Risk is a board, turn-based game, played on a board depicting a political map of the Earth, divided into a number of territories, grouped into continents. The aim of the game is to achieve a goal, that is assigned to each player at the beginning of the game, and is kept secret from other players. Players control armies, which are deployed in occupied territories (and grouped in continents), and can be used to capture territories from other players. The results of attacks between territories is determined by rolling dice.
The goal of this project is to develop a turn based client server Risk game, in which users play the game through a web site. The game must implement all core functionalities of the standard version of Risk (see en.wikipedia.org/wiki/Risk_(game) for a detailed description), including rules for obtaining and placing armies, attacking territories, and fortifying, as well as supporting Risk cards. Additionally, the game must support greater levels of configuration, through the possibility of choosing the map one wants to play on, and different complexity levels.
More precisely, the game must:
- allow users to define and upload map configurations, including not only the aesthetic aspects such as images, etc., but also specific numbers of territories, grouping into continents, and neighboring relations (and optionally stronger restrictions on the number of players);
- allow for maps to automatically adjust granularity, by collapsing neighboring territories according to number of players and a user selected complexity for the game (e.g., easy, medium, hard).
Project Scope
The project must implement the features described above, i.e., all rules of standard Risk plus the configurability characteristics. Optionally, a single objective for the game can be implemented instead of the objective cards (this common objetive for all participants may be, e.g., conquering two thirds of the world). The game must come with at least one preloaded map (may be the standard Risk map), with the three complexity levels (easy, medium, hard), that cause collapses in the territories.
The choice of the development platform, including tools and programming languages to use, is left to the teams. Since the game is web-based, MVC frameworks such as Django or Rails may be useful. Besides the development of the software, teams must provide accompanying documentation, including a requirements document, a design document, and a brief user manual (installation and game playing).
Process Requirements
Teams can use any development process, although agile methodologies are suggested. All project artifacts must be hosted on a public repository with issue tracking facilities (e.g., GitHub).
In order to track the project's activity and progress, the following rules should be followed:
- For each major set of development tasks, a milestone characterising them must be defined.
- For each development task, an issue describing it must be defined, within the corresponding milestone.
- Task granularity is up to the teams. For larger teams a small granularity is better (work units may be method implementations, method documentation/contract provision, unit tests for methods, etc.).
- Prior to creating a new issue, users must check if the same issue has been previously created (important for large teams) to avoid work redundancy.
- The use of branches for working on partial solutions or larger issues is recommended.
- All users must make sure their partial solutions do not break the system (tests that passed before must still pass, project must compile, etc.).
Environmental Constraints
On the client side (and being the game web-based), the game must run on most modern browers (Internet Explorer, Chrome, Firefox, etc.). On the server side, teams are free to make the system run only on selected platforms, although the support of GNU/Linux is strongly recommended.
Level of Sponsor Involvement
The sponsor of this project will accept questions about the project topic at any time. As questions arise during development, these will be gathered and made available in the FAQ section, to help developers.
Sponsor contact: naguirre@dc.exa.unrc.edu.ar
Project Restrictions
None.
Project FAQ
Answers to selected questions will appear here.