The game is sound. The game score reflects **only** the agent's skill level in:

I)   Solving problems
II)  Providing hard problems
III) Introspective skills: predict how the solution algorithm behaves

1) An agent can't force other agents to consistently lose.
1) An agent can't force other agents to consistently draw.
1) An agent can't force other agents to consistently win.

=================================
Offer Challenge:
================
 The price of a challenge is in [0..1].

Provide Challenge:
==================
 A problem instance only uses relations mentioned in the type.

Solve Challenge:
================
 A solution to a MAXCSP problem must assign enough variables so that each clause is either satisfied or unsatisfied.

Accept Challenge:
=================
 The challengee must be a player in the game.
 An agent is not allowed to accept its own challenges.

Problem Types:
===============
For TBall, Problem type must be a singleton set. 
For Slow Pitch Softball, relations must form an implication tree.

ALL Boolean MAXCSP instances:
=============================
The set of declared variables must be a super set of the set of used variables. 
A clause must contain 3 distict variables. 
A clause must contain 3 >>>>distict<<<< variables.
The weight of a clause is a positive integer > 0. 
The problem type must be a set of distinct integers. 
The relation number must be between 0 and 255. 
The number of clauses must be at least 1.
The number of clauses and the number of variables is bounded by the maximum number of allowed clauses.
The number of variables is bounded by the maximum number of allowed clauses.

Semantic checks for Turn:
=========================
 Be active but not hyperactive.
	NumProposals = numOffers + numReoffers;
	NumOppositions = numAccepts + numReoffers;

	config.getMinProposals() <= NumProposals <= config.getMaxProposals();
	config.getMinOppositions() <= NumOppositions 


Semantic checks for game state correctness:
===========================================
 The game state is a list of challenges, Offered, Accepted, Provided. And an account for every player.
 should be consistent that is:
   No challenge should have offered = acceptor. 

What is the purpose of the game?
================================
The purpose of playing an SCG(X) contest is to assess the "skills" of the players in: "approximating" optimization problems in domain X, "figuring-out" the wall-clock-time-bounded approximability of niches in domain X as well as the hardest (i.e. least-approximable) niches in domain X, "figuring-out" hardest problems in a specific niche, and "being-aware" of the niches in which their own solution algorithm works best. This multi-faceted evaluation makes SCG(X) more superior to contests based on benchmarks that only test the player's skills in approximating optimization problems. During the game, players cross-test each others' skills.

Conjecture: when the game is fair, player scores reflect their relative skill levels. 
Conjecture: when a contest ends with a loser, the contest produces new knowledge for it. Thus stirring progress.
Conjecture: when the game is transparent (not tricky), players save time on learning about common pitfalls.

Supposing that these three conjectures are correct, then we want three requirements for SCG(X) design.
r1. It is fair: there is no strategy that reduces the opponent's chance of increasing their scores. (wining strategy)
r2. The game is productive. The chances of draw are very low (should we eliminate them? what if the two players are equally skillful?)
r3. It is not tricky: there is no strategy that increases the opponent chance of increasing their scores. (others-win strategy or loosing strategy in 2 player games)

Analyzing the current set of rules (a.k.a. semantic-checks), we can relate them to one of these three requirements.

semantic checks for a turn:
===========================
 Players are active [r2]. Otherwise, players can draw by not participating.
 Players are not hyperActive [r1]. Otherwise, players can have a monopoly which is a winning strategy.
 Players cannot offer challenges already in store [r2]. Otherwise, players can mirror each other.
 A challenge in store cannot have the same player as an offerer and acceptor [r2]. Otherwise, players can keep kicking the ball to themselves unproductively. This check is actually implemented by a pair of checks at the level of transactions; Namely, players cannot accept their own challenges, players cannot reoffer and accept challenges.


 


Karl Lieberherr, Ahmed Abdelmeged, Bryan Chadwick, Alex Dubreuil