The Robot Game Specification V.0.2

History:
V.0.1 (unknown): initial writing
V.0.2 (2/11/01): added Program Structure (External), Game Description, DM and AICM documentation.


Contents:

1. Program Description
2. Program Structure (Internal)
	General Overview
	Game State Data Structure
	Display Module
	AI Control Module
3. Program Structure (External)
	Interface
	Program Interface
4. Game Description
	Overview
	Bots
		Equipment
		AI
5. 2D-3D Interface
	Game World
	Interaction
	Visualization
	Representation
	



1. Program Description
	
	The Robot Game is a program which lets programmers create AI's to control 'robots' which attempt to compete objectives in order to score points and win. These objectives usually include the destruction of opposing robots, with AI's created by other programmers. The game world is a varied one, containing walls, and other objects in a fully 3D world. The robots are limited by what they can sense, using the various sensing devices at their disposal. The robots can manipulate the world using devices designed for that purpose as well. Generally, the world is static, though there is the possibility for almost everything to change, and illusions can appear and disappear as well. 

2. Program Structure (Internal)

	General Overview:
		
		The Program is split up into a number of modules which communicate using data structures represented by classes. The program as a whole is modeled using an OOP design, representing robots, the game world, and the external display which represents the computer screen being viewed by the user.

	Game State Data Structure (GSDS):

		This data structure contains the information necessary for the representation of the game world as a whole, as well as the various specifications of the hardware on which the simulation is being run. Other information contained includes the states of the various robots, there owners and generally everything known to the program as it is run. This is the largest and most complicated of all the data structures as it contains all of the information in the entire game.

	Display Module (DM):

		This is the code that takes the data from the GSDS and displays it onto the string. It is responsible for also displaying the GUI and responding to the users input (through a sub module). There are potentially several modules, though all would use the same input module. These modules could include: 3D interface, 2D interface, accelerated interface (again, through some sort of sub module). A text interface is also possible. For the display module, unlike most of the other module, there is some chance that the sub modules will not be used for some situations that require speedy execution. For instance, the various 3D interfaces might be written each from scratch, rather than using a simplified API that is then customized for each platform/configuration.

	AI Control Module (AICM):

		The AICM is the heart of this game. It is somewhat like a server in that it allows the robot clients to get and set info about the world and their actions. The AICM deals with all the timing issues, as well as moderating the transfer of info to and from the individual robot AI’s. This module should be universal, though the timing and display interfaces still have to be defined. Ideally, though, the AICM should require no modification between implementations.
		Each robot is only given so much information. It has yet to be decided in what form to give this info, but two possible solutions are to give an emptied map similar to the one in the GSDS, while another, more realistic one is to return info only when it is requested, through radar function calls and the like. One problem is how much info the robots have at the beginning of each round, and how to get them that info. By using the first solution, this problem is solved, as each turn is like a new round, and the robots always have as much info as they should. The downside is that it is therefore hard to conceal certain pieces of information, such as how large the map is and how many robots there are. The downside to the second solution is complexity. Each robot would be required to store all of the information on internal memory.


3. Program Structure, External:

	Interface:
		
		The GUI of this game is relatively simple. For the main game, it should just be a window with various camera controls, as well as quit, save etc functions. Additional data such as robot vital statistics and other info could be displayed in small windows which could be positioned by the user. The program would typically be windowed, using the API for the window server being used (X or win32). The 3D interface would be somewhat different, as a full screen environment would be preferred. 

	Program Interface:

		This program would require each robot contestant to submit some sort of dynamically linked library that contains the robot AI. When the game started, each robot would be linked to a handler that would interface with the AICM. At this point it is likely that the handler would call a function of the robot which would transfer program control to it. The robot would then start calling functions of the handler to interact with the outside world. Each time a function is called, control would revert to the handler and AICM. Depending on a variety of factors, any number of other robots would get control before it reverted back to the original robot in the form of the function it called returning. In general, each robot would see no discontinuity in its control. This is beneficial because it gives away no information about the other robots.

4. Game Description:
		
		Overview:
			This game is nominally about destroying the other robots in the arena. It could potentially be adapted to other, more complicated, objectives such as working with a team to complete some objective, or even exploring a larger world than just a small, enclosed, arena. Though the world will eventually be in full 3D, it will start with simple 2D and enclosed arenas.

		Bots:
			
			Bots are the main objects in the world. They are generally mobile and autonomous. It could be permissible to have centralized bot control systems where one bot controls others, but no human intervention is allowed. Each bot has its own setup, determined several possible ways. For example, the bot could be pre-loaded by the computer, or by its owner, or it could determine its own makeup. However, except for filler bots, all bots will have their own AI, which is created by their owner.

			Equipment:
			
				The equipment carried by a bot is varied, including such things as radar, engines, weapons, special devices, and more. There are also several different chassis, and several different versions of each object. Additionally, each bot is equipped with a processor, which determines how fast it can make decisions. Theoretically, this could be used to determine the amount of processor cycles that each bot can use each turn, but more likely it will just determine how long each command takes to complete. For example, a bot with a fast processor would be able to give several commands quickly, though they may not be carried out immediately. This does bring up the problem of what to do in this case. Should the command be as fast as the processor, effectively allowing the bot to speed up the time it takes to get a radar image (though not the time to turn, etc.)? Or should some sort of (complicated) asynchronous protocol be set up to allow several commands to be give, and delaying the completion of those commands? This is and extremely important question, as it impacts the construction of the AI’s most significantly.

			AI:
			
				The AI of each robot is written by some person. There will be several pre-written commands which can be modified by less able programmers, but non-programmers will not be able to use this program effectively. 

5. 2D-3D Interface:
	Game World:
	Interaction:
	Visualization:
	Representation:


		Technical Specification:

		Game State Data Structure-
		|	
		-->	Hardware Info -information on the hardware environment of the host computer
			|
			-->	CPU, type and speed
			-->	RAM, speed and amount
			-->	Video, type and variety
			-->	Other info as needed
		-->	Situational Info -information on the current game situation, type, victory 			|		conditions, etc
			-->	Game type -the type of the game: deathmatch, ctf, etc	
			--> 	Victory Conditions -specific victory conditions, #frags, etc
			-->	Victory Actions   -what to do for a victory, give money, nothing, etc
		-->	Robot Info -information on the number and type of the robots involved and their 			|		owners
			-->	number of robots
			-->	configuration -individual, teams, other general 'political' situation
			-->	Info for each robot:
				|
				--> 	Owner
				-->	Detailed political specification
				-->	rank, point value, misc. info
				-->	AI type -built in or programmer created
				-->	AI programming link
				-- detailed physical specification --
				--> 	Chassis
				-->	Equipment list
				--> 	info on each piece of equipment:
					|
					-->	type
					--> 	damage status
					--> 	operational status
					-->	charges
					--> 	special info
		-->	Game World Data -information on the current status of the game world
			|
			-->	Game map -complete map of the game world, the position and 							orientation of the robots and other info.
			-->	???
			
----------------------------------------------------------------------------------------------------------------------

formal technical specification

class GSD {

	class {
		string CPUType;
		int CPUMhz;
		int RAMAmount;
		int RAMMHz;
		string VideoType;
		string VideoSubType;
		//Other info as necessary
	} HardwareInfo;

	class {
		string GameType;
		string VictoryConditions;
		string VictoryActions;
		//Other info etc.
	} SituationalInfo;

	class {
		int NumBots;
		string BotConfig;
		class  botInfo{
			string Chassis;
			class equiptment {
				string Description;
				int Damage;
				int OpStat;
				int Charges;
				string SpecialInfo;
			} Equiptment*;
		} BotInfo*;

	} RobotsInfo;

	class {
		int Xsize;
		int Ysize;
		
	} WorldData;

}