Initial SCG Arena Problem Statement

This statement serves as input to the use case model. Patterned after the Arena Problem Statement on page 154 of Bruegge and Dutoit (OOSE, Prentice Hall).

SCG Problem Statement

SCG/Avatar supports a game-based software development process for computational problems CP defined by an input/output mapping. At least two competing and collaborating teams develop an avatar containing software for CP. The goal of the game is to have a focused, productive discourse about CP between the avatars, and indirectly, between the software teams, to find good software/algorithms for CP and to fairly evaluate all proposed solutions. The CP software is embedded in an avatar that proposes and opposes claims about how well CP can be solved.

There are many computational problems for which we want to develop high-quality software through SCG. Therefore we want to develop community support for running all those games for all those computational problems. Each computational problem uses different concepts and notations. It is a big advantage for the software developer when there is a consistent interface for all problems.

We want to use the SCG/Avatar game to (1) develop reliable software for computational problems, (2) evaluate potential employees, (3) develop new knowledge in the given domain, (4) evaluate algorithmic innovations fairly and (5) teach software development / problem solving techniques in a fun game environment. For example, several researchers claim that they have the best software to solve a specific computational problem. To determine who is objectively the best we define a suitable SCG/Avatar game, run a tournament and select the winner.


Provide an infrastructure for operating an SCG Arena, including registering new games and avatars, organizing tournaments, and keeping track of the avatars' scores.

Provide a framework to customize the accumulation of reputation points.

Provide a framework for game developers for developing new SCGs or adapting existing games.

Provide a framework for the software development teams behind the avatars (and spectators) to analyze the high-level game history in terms of "mega moves" called propose and oppose. The game history contains data which the development teams must translate into knowledge to update their avatar for future tournaments. The game history helps the development team to create a retrospective of the last tournament and to decide how to react. See, e.g.: Agile Retrospectives: Making Good Teams Great.

Provide an infrastructure for advertisers.

Functional requirements

SCG Arena supports five types of users:

The operator should be able to monitor the security of all the games in the arenas. Security involves: all avatars must follow the rules of SCG. There is no possibility to circumvent the rules and gain reputation without superior ideas and software. The operator can define new tournament styles (e.g., Swiss style tournaments), define new reputation formulas and manage users. The operator supervises the trusted third party, called the admin. The admin is responsible for running all the games and for checking the rules of each game.

The operator evaluates reports by avatar teams about security breaches. All avatar teams must agree not to exploit vulnerabilities in the SCG software but to report them to the operator.

Game definers should be able to define a new arena and new games in that arena by defining a domain and claims using a protocol. They should be able to advertise their game to attract avatar teams to it. Game definers conduct tournaments and declare a winner.

Avatar teams should be able to register their avatar in an SCG Arena, apply for participating in a game, play the matches, and drop out of a tournament.

Spectators should be able to monitor any match in progress and check scores and statistics of past matches and avatars. Spectators do not need to register in an SCG Arena.

The advertisers should be able to upload new advertisements, select an advertising scheme (e.g., sponsor a game definer), check balance due and cancel advertisements.

Nonfunctional requirements

Low operating cost. The operator must be able to install and administer an SCG Arena without purchasing additional software components and without the help of a full-time system administrator.

Usability There are tools for mining game histories to find clues for problems in avatars.

Reliability The admin should never crash. Crashes due to software bugs in game components should interrupt at most one SCG tournament. The other tournaments in progress should proceed normally. When a tournament is interrupted because of a crash, the game definer should be able to restart the tournament. At most only the last action of each interrupted match can be lost. Avatars that crash will be disqualified according to the game rules.

Extensibility. The game definer must be able to add new games, new tournament styles and new reputation formulas. Some additions, but not adding new games, may require the system to be temporarily shut down and new modules to be added to the system.

Scalability. The system must support the kick-off of 10 parallel tournaments each involving up to 20 avatars and several hundred of simultaneous spectators.

Target environment

Can the SCG Arena project be conveniently implemented on top of IBM Rational Team Concert?

All avatars should be able to access any arena with a web browser supporting cookies, Javascript and Java applets.

The administration function of adding new games used by the game definer should be available through the web.

SCG avatars may be written in any programming language provided they conform to the SCG protocol.

SCG Arena provides baby avatars written in Java for a game defined by a game definer.

The SCG Arena should run on any UNIX operating system, e.g., Linux.

Arena Information:

This document does not talk about the avatar interface using propose, oppose(refute,strengthen), provideProblem and solveProblem. See: