TACWiki - User contributions [en]

Code How To's

2009-03-03T23:16:51Z

Brb6127:

This page provides tutorials for some of the most common actions a programmer may wish to implement. It may helpful to read the [[Code Overview]] first.

==Submit a Bug or Other Issue==

* Go to http://www.AutismCollaborative.org/bugs/
* Fill out the fields that apply to this issue

'''Type of Bug:'''
* Functional Problem
** Any actual "Bug"
* Suggestion
** A possible change to the game that may improve it
* New Feature
** Something that '''absolutely must''' be implemented
** Use sparingly; make sure it's not actually a Suggestion

'''Severity:'''
* How much this issue affects the game/application

'''Priority:'''
* How soon the issue should be resolved (relative to other issues)
* The majority of issues should be Low priority
* Use High sparingly

==Coding Conventions==

* Place the name of the file, authors, and copyright info at the top of each file
** Any person who makes significant changes to a file should add their name to the list of authors in a file
*** This helps anyone reading the code because they know who to ask if they have a question about something
* All private and protected class member variables are lowerCamelCase
* Private/protected class member variables are preceded with "m" (ie mLocalVariable)
* All functions, properties (sometimes called "smart fields"), and public class variables are UpperCamelCase
* Public variables should only be used with small classes that are used by only one or two other classes
* This code is intended to be viewed by many people who do not have strong programming backgrounds, therefore documentation is '''very''' important
** Document the purpose of each class's member variables, either next to their declarations or as a summary for their property accessor
** Create a summary documentation block for every function unless it is extremely obvious
*** This can be done by placing the cursor above a function definition and typing "///"
*** This block shows up in Intellisense when writing that function in code
** Add a summary to any properties that are possibly confusing or not straightforward
** Document every step of each algorithm (except for very obvious function calls like ResetSettings();)
*** Someone should be able to read only the comments in a function and still understand what it does
** See MeteorMadness.cs for an example of the appropriate level of documentation
* See the Load a Texture section for naming conventions of texture assets

==Create a New Minigame==

For a step by step tutorial with code examples, see [[How_to_Make_a_Mini-Game]]

* Declare the class
** Create a new folder under ColonySimulator
** Create a new file in that folder named NewMinigame.cs where NewMiniame is the name of the new minigame
** Place all new minigame-specific classes in that folder
** Have the class derive from GameScreen
* Implement the Constructor
** Initialize game variables
** Declare a ScoreCard (see Scoring tutorial)
** Log the GameBegin code (see the Logging tutorial)
* Implement Update()
** Do not assume a constant call rate
*** This function will almost always be called 60 times per second, but that rate may vary depending on CPU load
*** At the beginning of each cycle, get the time since the last cycle like this:
**** float dt = gameTime.ElapsedGameTime;
*** Build the time into all movement and timers, for example:
myEntity.LifeSpan -= dt;
myEntity.Position += myEntity.Velocity * dt;
* Implement Draw()
** Be sure to call each entity's Draw and Update methods. Optional: Register all entities with the XNA game object.
This will have XNA automatically call their Draw and Update functions at appropriate times.
** Consider using a generalized render-queue such as GenericWorldSpace '''(not yet implemented as of October 2007)'''
** Use the Raise function to place the minigame gamescreen on the stack based game system.
* End the mini-game using Done function. This will pop the mini-game off the game stack, returning the game to the previous state.
** Flush the particle system (see the particles tutorial) if any emitters were created
** Log the GameEndSuccess/GameEndFailure code
** Show the score

==Use Images==

XNA supports most common types of images, including JPEG, GIF, DDS, etc.

===Load a Texture===

Before you can load a texture in code, though, you must add it to the content pipeline:

* Import the content into the project
** Browse to the appropriate folder in Visual Studio's Solution Explorer
*** For example, Content\MiniGames\MyImage.png
** Right-click on that folder and select Add->Existing Item
** Select the image to import

Once that's done, you can load it memory using the XNA content manager:

Texture2D myTexture = Content.Load(@"General\myTexture");

The XNA content manager defaults to the content folder of the project, so all addresses can be relative from there. Also, the name of the image should be the same as the asset name. This can be set in the properties window.

===Display a Static Image===

Before manually drawing something to screen consider using some type of game object, be it an Entity, HUD element, or even a Ticker (see the tutorials below). Game objects all know how to draw themselves, so it is unlikely that a minigame will need to draw something directly to the screen. Should the need arise, however, here's how it's done:

* Load it in code:
GraphicsDeviceManager gdm = ...; // This is declared in GenericGameManager.cs
ConentManager cm = ...; // Usually a parameter, as in Update(ContentManager content)
SpriteBatch sb = new SpriteBatch(gdm.GraphicsDevice); // Basically a wrapper for a DirectX render target
Texture2D texture = TextureManager.Load(@"Content\General\myTexture");
Rectangle destination = ...; // Display destination
Color tint = Color.White; // Tint the image with this color
float rotation = 0f; // Rotation (in radians)
Vector2 center = new Vector2(texture.Width / 2f, texture.Height / 2f); // Origin of rotation
float zDepth = 1f; // Order to draw sprites within this spritebatch

sb.Begin(SpriteBlendMode.AlphaBlend, SpriteSortMode.BackToFront, SaveStateMode.SaveState);

sb.Draw(
texture,
destination ,
null, // What part of the source image to sample from--null tells it to use the whole image
tint ,
rotation,
center,
SpriteEffects.None, // How to mirror the image
zDepth
);

sb.End();

===Display an Animation===

Animations are created using the AnimatedSprite class. Here's an example:

//Declare Animated Sprite
//Parameters: Game object, SpriteSheet as a Texture2D object, Position as Vector2, FrameSize as Vector2, Number of Frames
AnimatedSprite testAnimation = new AnimatedSprite(this, Content.Load<Texture2D>("TestSpriteSheet"), new Vector2(200, 300), new Vector2(64, 64), 16);
//Pass a reference to the SpriteBatch that the AnimatedSprite will use
testAnimation.SpriteBatch = spriteBatch;
//Turn on the Animation
testAnimation.Animate(true);
//Turn off the Animation
testAnimation.Animate(false);

*Do not forget to call the draw and update methods of the AnimatedSprite explicitly, or to add them to the XNA game.components array so as to allow XNA to call them.

==Create a New Type of Game Object==

All specific game objects (players, enemies, collectibles, projectiles, etc.) should derive from Entity. This gives them easy ways to draw themselves, move, collide with other entities, and be passed to many tAC_Engine functions.

==Get User Input==

'''DO NOT''' use the standard XNA keyboard accessors (Xna.Framework.Input.Keyboard) or mouse accessors (Xna.Framework.Input.Mouse) because tAC_Engine does a lot of caching and logging behind the scenes. Use the InputHandler instead.

===Keyboard Example===

// Bind the 'A' Key to the event 'PressedA'
mInputHandler.Bind(Keys.A, InputHandler.Trigger.Pressed, (int)EventCodes.PressedA);
...
InputEvent inputEvent = mInputHandler.GetNextEvent();
if (inputEvent.EventCode == (int)EventCodes.PressedA)
{
// The A key was pressed
}

===Loading Keybinds from a file===

// Load Bindings from 'keybindings.dat'
mInputHandler.LoadBindings(typeof(EventCodes), RootDirectory + @"\keybindings.dat");

The Bindings file is a plain text, human-editable file that takes the following form:

"Event Name" (tab*) "Key Name" (tab*) (flags*)

====Keybinding Examples====

Quit Escape
* Trigger the Quit event when Escape is pressed.

PlaceBuilding Left mouse
* Trigger the PlaceBuilding event when the Left ''Mouse Button'' is pressed.

ZoomInStop OemPlus released
* Trigger the ZoomInStop event when the Plus Key is ''released''.

==Manage a Heads Up Display==

Use the HUD class for any HUD element (like health bars, menu buttons, etc.). Typically, you'll want to create a class that inherits from Widget2D. See MeteorWidgets.cs for examples.

==Display Text or Icons with the Ticker==

string text = "w00t."; // Text to display (can be "")
Texture2D image = null; // Can also be set to an image
Vector2 imageSize = new Vector2(25f, 25f); // Size of the (optional) icon
Vector2 offset = new Vector2(700f, 50f); // This will display the ticker 700 pixels to the right of the screen's
// center and 50 pixels below the screen's center
Vector2 velocity = new Vector2 (-10f, 0f); // Move left 10 pixels per second
Ticker.Font font = Ticker.Font.Standard; // Regular text
Color color = Color.DeepPink; // The manliest of colors
float opacity = .5f; // 50% transparent
float seconds = 5f; // Disappear after 5 seconds
bool fade = true; // Fade in and fade out

Ticker.Display(text, image, imageSize, offset, velocity, font, color, opacity, seconds, fade);

==Display Text==

First you must import the desired font:

* Create an xml spritefont file for the new font called FontName.spritefont and set the desired values.

Now for the code:

ContentManager cm = ...;
SpriteBatch sb = ...;
SpriteFont = cm.Load<SpriteFont>(@"FontName");

sb.Begin();
sb.DrawString(SpriteFont, "Some Text!", new Vector2(10.0F, 10.0F), Color.Azure);
sb.End();

==Use Sound==

===Import a new Audio File===

** Run the XACT tool from Microsoft DirectX SDK
** If--after following the steps in this tutorial--playing a file in code throws an exception about using the wrong version of XACT, try using Xact.exe from a different SDK build
* Open AudioProject.xap file for the Minigame to which you wish to add a sound.
* Expand Wave Banks and double-click Wave Bank in the panel on the left
* Expand Sound Banks and double-click Sound Bank in the panel on the left
* Go to Wave Banks->Insert Wave File(s)...
* Select the file to import i.e."@/MiniGame/Content/Audio/MySound.wav" and click OK.
* Drag the newly-added file to the Cue Name section in the Sound Bank:Sound Bank window
* Assign the audio file to be either a Music or Effect sound
* Go to File->Build
* Save and close XACT
* Open game.sln with Visual Studio
* Browse to the Content\Sounds folder in the Solution Explorer
* Right-click the Sounds folder and select Add->Existing Item...
* Select "MySound.wav" and click OK

=== Load an Audio Project ===
This needs to be done before you play any sound or effect.
SoundManager.LoadAudioProject("AudioProject.xgs");

===Play an Effect===

SoundManager.PlayEffect("Pew"); // No file extension

===Play Music ===

SoundManager.PlayMusic("MyMusic");

==Use the Particle Engine==

Particles are handled by the TACParticleEngine, a separate library that uses the AC_GraphicsEngine that has been modified to better fit the needs of the Autism Game. Features are added to it on an as-needed basis so if a new feature needs to be added and any problems arise in its integration into the current particle engine contact Brian Murphy.

Quick layout of TACParticleEngine:

The ParticleManager contains references to all loaded ParticleEngines.
ParticleEngines contain a series of Emitters.
Emitters contain a heap of Particles, which are the objects that actually get drawn.

Make sure to include these packages so that we can create and access our particle engine objects:

using TACParticleEngine;
using TACParticleEngine.Particles;

Inside the class declaration make these global variables:

ParticleManager mParticleManager;
ParticleEngine mTestEffect;

Since the TACParticleEngine makes use of the Camera class from the AC_GraphicsEngine, we will need to create and initialize an instance of the Camera class if we are to render our particles, so let's get our camera set before we initialize the ParticleManager.

Add the following line to the list of global variables at the beginning of the class:

Camera mActiveCamera;

This will be whatever kind of camera we are currently using for drawing. (We may want other cameras, too, for whatever reason.)

Next we need to initialize the camera to any specific type of camera that derives from class Camera. At the time of this writing (January 2009) these types are limited to FollowCamera, OrthographicCamera, PerspectiveCamera2D, and PerspectiveCamera3D. For now we'll use a PerspectiveCamera3D as our active camera.

mActiveCamera = new Perspective3DCamera(new Vector3(0, 0, -5), Vector3.Zero, Vector3.Up, MathHelper.Pi/5, 1, 1, 100);

If we ever need to change the camera, be certain to update the active camera for the particle manager by calling
mParticleManager.SetActiveCamera(newActiveCamera);
where newActiveCamera is the camera that has just been changed to.

Now that we have a camera, make sure to initialize the particle manager (and optionally, some particle effects) in the class's initialize method:

mParticleManager = new ParticleManager(Game, mActiveCamera); // Initialize the particle manager object with a reference to the current
// game and to the current active camera
mTestEffect = mParticleManager.Load("ParticleEffects/Explosion"); // Load in the given particle effect file by giving the
// location at which it is compiled

Once this has been done, you'll have an effect loaded into the Particle Engine object '''mTestEffect''' via the Particle Manager. However the Particle Engine isn't worth much if it's never called on to do anything, so let's set up the rest of the code that's needed for updating and drawing:

To accomplish this, all we need to do is add the particle manager to the Game's list of components. This is done as follows:

AddComponent(mParticleManager);

Aside from this we need to set the draw order of the effects, at least generally by calling

mParticleManager.DrawOrder = DrawOrder; // The second DrawOrder being whatever draw order is desired

This will draw and update any particles that have been loaded by the Particle Manager and have been set active. However, the particle engine that we just created hasn't yet been set active, so do that now.

This is done by calling the following line whenever you would want drawing of that Particle Engine to occur.

mTestEffect.SetActive(true);

The particle engine instance '''mTestEffect''' is now active. If it were already active, its lifetime would have been reset to 0. (The lifetime of a particle engine starts at zero and increases until its maximum lifetime is reached, in which case the particle engine "dies" and becomes inactive.)

This same method can be used to stop the particle engine from creating any more particles, by supplying '''false''' as its parameter instead:

mTestEffect.SetActive(false);

A series of methods allow us to modify the drawing of the ParticleEngine:

SetSplineScale(float scale) // Given a float, scales the spline around the origin by the given amount every 1/10 of a second. Note that this only
// applies for all spline emitters in the engine.

SetEnginePositions(Vector3[] Positions) // Given an array of 3D vectors, we can change the shape of all spline emitters in the particle engine.

SetEnginePosition(Vector3 Position) // Given a 3D vector, we can move the whole particle engine to the desired position.

SetEngineColor(Vector4 Color) // Given a 4D vector of float values 0-1 in the form of RGBA, we can change the coloring of the whole particle engine
// Keep in mind that this applies that much of the emitters' texture for each value, so a black picture with 1,0,0,1 as
// its value will not be red but still black.

SetEngineSize(Vector2 Size) // Given a 2D vector, we can modify the dimensions of the particle image, this is always 2D since particles in 3D are
// simply billboard sprites.

SetEngineSpeed(float Speed) // Given a float, changes the speed at which particles initially move at.

SetEngineDirection(Vector3 Direction) // Given a 3D vector, changes the direction in which particles move at. This does not apply to point emitters.

SetEngineParticlesPerSec(float NumPerSec) // Given a float, sets the number of particles created in a second. Note that this value times particle
// lifetime should not exceed the amount of particles in order to insure consistent effects.

SetEngineParticleLifetime(float Lifetime) // Given a float, sets how long a particle lives for in seconds. Note that this should never be changed
// while an effect is active, otherwise inconsistencies in the effect will most likely occur.

SetRandomDirection(bool Random) // Given a boolean, sets whether or not to make particles move in a random direction.

Also, if needed you can change the draw order of each engine individually by calling

mTestEffect.DrawOrder = DrawOrder; // The second DrawOrder is whatever draw order desired

Whenever a game object that uses a particle effect is being disposed, make sure to call

mTestEffect.SetActive(false); // Making sure to set the effect to no longer being active

on any effect with infinite life span and make sure to call

mTestEffect.ToDestroy = true; // Making sure to set the effect to no longer being alive

so that the particle manager knows that it can clean up the effect.

===Create a New Particle Effect===

To create a new particle effect, start the TACParticleEditor program. This program presents two windows, one containing a Windows form displaying information about the current particle effect, and the other displaying the particle effect.

There are four main areas of the particle editor form:

List of emitters - The list of all the emitters in the particle effect.

Emitter type - Contains all the different types of emitters that exist in the particle engine.

Row of buttons - Each having a functionality expected from their name:

Add - Adds an emitter of the chosen type from the list of emitter types to the particle effect's emitter list.

Remove - Removes the currently selected emitter in the particle effect's emitter list from the list.

Save - Saves the current particle effect to a specified .particle xml file.

Load - Loads a particle effect from a selected .particle xml file.

Emitter Info Grid - Contains all the information that can be modified for whichever emitter in the list of emitters is currently selected.

The modifiable parameters of the emitters are as follows:

For all emitters:

textureName - The file path name of the texture to render the particles with. In order to load texture names correctly, there
must exist a texture folder in the current project's compiled content folder. The default starting directory is the TACParticleEditor.
Whenever a new particle effect is loaded, the current directory is switched to that project's content directory. Anytime a new
texture is desired, it must be added manually to the appropriate project.

blendEffect - The sprite blend to use when rendering the particles. Can be either None, AlphaBlend, or Additive.
The various blend modes work as follows:

None - every particle draws exactly as how the texture appears and no alpha values are used. Therefore there will be no transparency.
For visual purposes it is highly suggested to not use this mode.

AlphaBlend - Averages all of the particles alpha values up to the max value assigned to any particle. This effect is useful in creating
effects such as dust, smoke, or gas clouds.

Additive - Sums up the colors of all the particles to the maximum value of 1.0 for all values (r,g,b, and a). This effect is useful
in creating effects such as fire, lasers, or shields.

emitLifetime - The duration of time the emitter continues to emit new particles for in seconds. This can be any duration of time. A negative
value denotes that the emitter never dies.

particlesPerSec - The amount of particles that are created every second. This can be any nonzero positive integer.

particleAmount - The total amount of particles that can appear on screen at one time. This can be any nonzero positive integer.

particleLifetime - The amount of time a particle lives for in seconds. This can be any nonzero positive number.

minStartSpeed - The slowest possible speed at which a particle can start moving. This can be any number, since a negative value just means
that the particle will move in the opposite direction.

maxStartSpeed - The fastest possible speed at which a particle can start moving. This can be any number, since a negative value just means
that the particle will move in the opposite direction.

minEndSpeed - The slowest possible speed at which a particle can end moving . This can be any number, since a negative value just means
that the particle will move in the opposite direction.

maxEndSpeed - The fastest possible speed at which a particle can end moving. This can be any number, since a negative value just means
that the particle will move in the opposite direction.

minStartColor - The minimum color values that a particle can start at in r,g,b,a form (i.e. red, green, blue, alpha). These values can be any
number between 0.0 and 1.0.

maxStartColor - The maximum color values that a particle can start at in r,g,b,a form (i.e. red, green, blue, alpha). These values can be any
number between 0.0 and 1.0.

minEndColor - The minimum color values that a particle can end at in r,g,b,a form (i.e. red, green, blue, alpha). These values can be any
number between 0.0 and 1.0.

maxEndColor - The maximum color values that a particle can end at in r,g,b,a form (i.e. red, green, blue, alpha). These values can be any
number between 0.0 and 1.0.

minstartSize - The smallest size that a particle can start at in width,height form. These values can be any nonzero positive number.

maxStartSize - The largest size that a particle can start at in width,height form. These values can be any nonzero positive number.

minEndSize - The smallest size that a particle can end at in width,height form. These values can be any nonzero positive number.

maxEndSize - The largest size that a particle can end at in width,height form. These values can be any nonzero positive number.

isActive - Whether or not the emitter is currently spawning/updating/drawing particles. You can quickly activate all emitters
of the loaded/created particle effect by hitting enter while having focus on the particle effect visualization window.

For directional emitters:

positions - The position in which particles will spawn in x,y,z form (aka a 3-dimensional point). These values can be any number.

minVel - The minimum velocity direction in which particles can move at in x,y,z form (aka a 3-dimensional vector going outward from the
position point). These numbers can range from -1.0 to 1.0.

maxVel - The maximum velocity direction in which particles can move at in x,y,z form (aka a 3-dimensional vector going outward from the
position point). These numbers can range from -1.0 to 1.0.

For point emitters:

positions - The position in which particles will spawn in x,y,z form (aka a 3-dimensional point). These values can be any number.

For spline emitters:

positions - The positions at/between which particles will spawn in x,y,z form (aka list of 3-dimensional points). These values can be
any number.

direction - The velocity direction in which particles will move in x,y,z form (aka a 3-dimensional point). (aka a 3-dimensional vector
going outward from the position point). These numbers can range from -1.0 to 1.0.

scale - The amount of scaling that occurs every time the spline emitter is scaled, that is to say, how much all positions
close in/expand from the origin (0,0,0) before any position offset is applied essentially creating an explosion or implosion
effect. This value can be any nonzero positive number. 1.5 represents 150% current size, 0.5 represents 50% current size, etc.

scaleSpeed - How quickly the scaling occurs in seconds. This can be any nonzero positive number. 1 is a scaling occurs once every second,
0.5 is a scaling occurs every half second, etc.

For spray emitters:

positions - The position in which particles will spawn in x,y,z form (aka a 3-dimensional point). These values can be any number.

direction - The velocity direction in which particles will move in x,y,z form (aka a 3-dimensional point). (aka a 3-dimensional vector
going outward from the position point). These numbers can range from -1.0 to 1.0.

sprayRange - The area in which particles can spawn with the center at the set position in +/-x,+/-y,+/-z form. That is to say a cubic area
with dimensions width, height, and depth and its origin at the given position. These values be any nonzero positive number.

====Quick Reference Table====

'''Parameter''' '''Parameter type''' '''Unit type''' '''Range'''
''For all emitters:''
textureName String N/A Any valid path name works.
blendEffect SpriteBlendMode N/A None, AlphaBlend, or Additive.
emitLifetime floating-point Seconds Any value. Negative value denotes emitter never dies.
particlesPerSec integer Per Second Any nonzero positive number.
particleAmount integer N/A Any nonzero positive number.
particleLifetime floating-point Seconds Any nonzero positive number.
minStartSpeed floating-point Arbitrary Any number. Negative value denotes movement in opposite direction.
maxStartSpeed floating-point Arbitrary Any number. Negative value denotes movement in opposite direction.
minEndSpeed floating-point Arbitrary Any number. Negative value denotes movement in opposite direction.
maxEndSpeed floating-point Arbitrary Any number. Negative value denotes movement in opposite direction.
isActive boolean N/A True or False.
minVel (x,y,z) vector Arbitrary Any number within -1.0 to 1.0.
maxVel (x,y,z) vector Arbitrary Any number within -1.0 to 1.0.
positions (x,y,z) vector Arbitrary Any number.
direction (x,y,z) vector Arbitrary Any number within -1.0 to 1.0.
''For spline emitters:''
scale floating-point % of size Any nonzero positive number. < 1 denotes decrease, > 1 denotes increase.
scaleSpeed floating-point Seconds Any nonzero positive number.
''For spray emitters:''
sprayRange (width,height,depth) Arbitrary Any nonzero positive number.

*Note that all arbitrary values are based on the current camera space.

==Keep Score and Give Resources to the Simulator Mode==

Use the ScoreCard class to keep track of the score from a minigame. It provides easy ways to add and subtract resources, as well as an easy way to display them and pass them along to the Colony Simulator.

MiniGame has a ColonyScoreCard built into it, accessible by the Score property. Here are some examples of how to use it:

class MyGame : MiniGame
{
public override void Update(ContentManager content)
{
Score.Gather(ColonyResources.Money, 500); // Get 500 Monies

MyGameObject mgo = new MyGameObject();
mgo.GiveMyGameCarbon(); // Get 1 Carbon

Score.IncurDamageCost(100); // On CashOut, Money = Max (Money - DamageCosts, 0)

int HowMuchMoneyIHave = Score.QueryResource(ColonyResources.Money);
}

public void DisplayTheScore()
{
bool playerWonTheMinigame = true; // Can be set to false if the player lost
Score.Display(playerWonTheMinigame ); // Displays a copy of the current score and a message for succses/failure
Score.CashOut(); // Transfers resources from MyGame to the Colony Simulator
}

// ...
}

class MyGameObject : Entity
{
public void GiveMyGameCarbon()
{
ColonyBaseApplication.MiniGame.Score.Gather(ColonyResources.Carbon, 1);
}
}

**Note: The code provided here is very subject to change as this section is under development.

==Write to the Experiment Log==

As the game runs, certain actions are recorded and written to a file (My Documents\Autism Collaborative\Users\DefaultUser\LogFiles\ExperimentLog.txt or as specified). In the lab, these codes are also sent through the parallel port to sync the EEG data. Every action that pertains to an experiment must be logged in order to be analyzed. (That's the whole point of this game!)

First define the necessary game codes. This is done to ensure consistency across each mini-game.

* Open EventCodes.cs, or wherever you store the enum for your project.
* Codes in the range 1 - 255 are valid and can be written to the parallel port.
** The name of the code should be chosen at your convenience, and may be included to make the text log file more readable.
* Codes may be assigned outside this range, both positive and negative; these codes may be used in the same way, but will be logged only to the text log file and not to the parallel port.
** Codes in the negative range are considered debugging codes, and can be omitted from the log file by setting the writeDebugEvents property on the logger.

Now those codes are available for logging, thus:

Logger logger = new Logger("ExampleLogFile.txt");
logger.LogCode( (int)Minigame.EventCode.WeaponFiredEvent, "WeaponFired" );

It is also possible to tell the logger to log a code every time a specific key is pressed:

InputHandler inputHandler = new InputHandler(true);
inputHandler.Bind(Keys.A, InputHandler.Trigger.Pressed, (int)Minigame.Eventcode.PressedAEvent);

As these assigned events are local to each InputHandler object, your mini-game's event code assignments will not interact with the event code assignments of other mini-games.

Every mini-game should start with its GameBegin and end with its GameEnd[Success/Failure] codes.

It may be helpful to log events for debugging purposes. These codes should have an identifier such as "DEBUG_" and will not be logged unless writeDebugEvents is set to true on the logger. (writeDebugEvents is true by default only when the game is running in Debug mode.) All new DEBUG tags must be explicitly assigned a value less than 0.

===Event Code Summary===

Event Codes may be any integer value.
* Less than 0 : Debug events, will only be written in Debug Mode.
* 0 : Null, no event.
* 1 - 255 : Experimentation event, will be written to the log and the parallel port.
* Greater then 255 : Cannot be written to the parallel port, will be written to log only.

==Use the Game Script==
*Note: The LUA scripts are not universally compatible and have been known to crash on some machines. It is highly recommended that C# scripts are used.

The tAC_Engine houses a [[http://www.lua.org/ Lua]] Virtual Machine. This can be used to tweak global parameters at runtime, load them from config files, drive cutscenes, or even save and load levels.

Function callbacks are defined in C# and then invoked from a Lua file or the in-game Debug console. In other words, C# tells Lua "you may use these functions: X,Y,..." and then Lua says "do X, do Y, etc."

Here are a couple of ways to leverage this system:

===Make a Cutscene===

* Create a new lua file in the Scripts directory
** That file can call any registered function callbacks
* In the Properties window, set Copy to Output Directory to Copy if Newer
* Call that cutscene with:
GenericBaseApplication.GameManager.PlayCutscene(@"Scripts\MyCutscene.lua");

===To Register a Function Callback===

* Create the function in C# (if the function does not already exist)
** It must be declared public and non-static
** If the need arises to register a static function, declare an instanced function in GenericLuaHelper or ColonyLuaHelper that simply calls the static function.
* Register the function with the Lua Virtual Machine
** Add the special LuaCallback annotation to the function
* Call the RegisterLuaCallbacks function in the class's constructor that contains the function.
* Example:
public MyClass()
{ // Constructor
LuaHelper.RegisterLuaCallbacks(this);
}

[LuaCallback("SetMyVariable")]
public int SetMyVariable(int value)
{
mMyVariable = value;
}

===Tweak Game Parameters===

Exposing a variable to the Lua Virtual Machine allows it to be accessed by a any script (including config files) or changed at runtime in the drop down console (accessible in Debug mode by hitting "~").

* Expose a variable with a global setter/getter with a LuaCallback annotation
** Make sure to call the RegisterLuaCallbacks function in that class's constructor if the getter/setter is not in the Game Manager
* Set the default value for the variable in the config file (optional)
** There are 3 config files for the 3 configurations of the game builds
*** Debug.conf, for development
*** StandardRelease.conf, for public releases of the game
*** LabRelease.conf, for use in the lab

===Create Local Settings===

Programmers may want to change certain properties on their machines without affecting the source-controlled code. They could change the resolution, sound settings, or even have the game bypass the regular startup sequence and launch right into the middle of a MiniGame all with no effect on other developers.

* Create a new file: Autism Collaborative\Game\Game\Scripts\LocalSettings.lua
** The Visual Studio project already has this file included, but VS won't be able to edit it until the file is created manually
* Add Lua commands and save the file
** Visual Studio can now be used to edit the file
* The file is run at the end of the Debug.conf script (if it exists)
** That means that this script is only run in Debug mode
* do '''NOT''' add LocalSettings.lua to source control!

===Creating Scripts in C# Code===

Alternatively, scripts can created using C# code rather than Lua. A C# script either be object oriented or imperative. They are able to both take in objects and return values. The CSharpHelper class can be called to run these scripts using its DoSimpleFile method. This will simply run all the code in the script. The value of this is that commonly edited code, such as configuration files, can be saved in a convenient separate location. The methods for CSharpHelper are well documented within the file itself. An example of a basic call to a C# script is as follows:

CSharpHelper.doSimpleFile(Environment.CurrentDirectory + @"\Configs\DebugConfig.script", this, "game");

This starts a C# file called "DebugConfig.script" which is located in the Configs directory. The second parameter is a Game object. The object passed in can be of any type. The third parameter is the identifier of the object within the script. In this case the identifier is "game". This means that inside the script, lines such as:

game.Update();

will execute the passed-in object's Update function.

==Publish the Installer==

===Create the Installer===

We use InnoSetup to create the installer. Checkout their website (http://www.jrsoftware.org/isinfo.php) if you need to change the script, but simply publishing the game does not require any adjustment to the installer script.

* Install InnoSetup if necessary
* Compile the game
** In the second menu bar (immediately below the top menu bar) within Visual Studio, change "Debug" to "Release". (In the box to the right, leave the default "Mixed Platforms".)
** Select Build->Build Solution
* Compile the installer script
** Open Autism Collaborative\Game\Installer\Installer.iss with InnoSetup
** Select Build->Compile
*** This creates the file Autism Collaborative\Game\Game\Output\AstropolisSetupLite.exe
*** When the compilation is finished, it will ask if you want to test the installer. It is recommended to test it, but not required.
* Repeat the last step with InstallerFull.iss if desired, this will generate AstropolisSetup.exe, which contains the full offline installers for the dependencies. This is necessary for the lab computers which may not have internet access.

===Upload the Installer to the Web===

* Get a username/password for autismcollaborative.org from Matthew.
* To transfer the file, use an SSH client such as WinSCP (for a graphical interface) or PuTTY's PSCP (from the command line)
** Either download it or run Autism Collaborative\Utilities\WinSCP.exe
* Log in to AutismCollaborative.org (port 22)
* Upload AstropolisSetup.exe to your home directory (for example /home/zinsser)
** Do not overwrite the existing installer (/home/belmonte/autismcollaborative.org/downloads/AstropolisSetup.exe) since that would delete the installer from the web site until the new installer finishes uploading
* Once the upload is complete, ssh into a shell and enter the command "mv /home/{$user}/tAC_Installer.exe /home/belmonte/autismcollaborative.org/downloads/AstropolisSetup.exe" (you may have to open a terminal first, depending on your SSH client)
** If there is a permissions problem, contact Matthew to make certain that your user ID has write and search permission for the autismcollaborative.org/downloads directory.

==Using the Mini Game Score Screens==

The Mini Game Score Screens are implemented in a class within the tAC_Engine. This class is utilized to encapsulate the behavior for the displaying the scores of mini games uniformly to players, while also allowing a uniform means of exiting the mini game. All mini games utilize the 2 screen approach (one for the menu for the game, one for the actual game) on top of tyhe stack. Because of this, the mini game score screen allows the direct exiting of a mini game after it has been played, returning back to the Colony Simulation or previous game screen on the stack, before the mini game was selected.

This is done by clicking the Exit button in the score screen, which performs 3 Done() operations on the stack.

To display scores, the game must create a MiniGameScore screen object and call it to display, as follows:

MiniGameScoreScreen scoreScreen = new MiniGameScoreScreen();
scoreScreen.DisplayScores( Title_Of_Game, Scores );

Where the values are as follows:
*Title_Of_Game is a string, which is displayed at the top of the score screen.
*Scores is a Dictionary<string, string> where the first value is the label for the score, and the second value is the string value associated with that score (usually some number written in string form, but it could be textual as well).

==Use the ErrorLog==

When the game encounters an Unhandled Exception (such as when an end user runs into a bug in our code), useful information is dumped to ErrorLog.txt. The user is encouraged to email that file to us so that we can locate the problem. Although the ErrorLog will tell us what function the program died in, it cannot tell us specifically which line was the culprit (although ErrorLogs created when the game is running in Visual Studio will tell us exactly which line).

We do, however, have the ability to log any custom information from a mini-game. This ability may prove invaluable in debugging based on end-user error reports. All that you (the programmer) must do is override the string MiniGame.DebugInfo() function. When ErrorLog.txt is created, it calls that function on the current MiniGame and appends the returned text to the bottom of the file.

==Testing Procedure==

This is a list of recommended tests to be performed on a regular basis to ensure that the major functionality of the program is intact.

Maritime Defender

*Play through tutorial
Things to Note:
**Text does not run off screen
**Dialog boxes wait for the space bar to be pressed before disappearing
**During the navigation-phase tutorial, input is registered correctly

*Play through main game
Things to Note:
**Collision detection is correct
**Phases are in the correct order
**Navigation phase looks correct: Dots are the correct size and dot correlation fits PEST data. Look for any slowdown or loss of frames.
**Boss fight is correct. Boss takes damage and causes the player damage.
**Player Health is displayed correctly on taking damage.

Colony Simulator

*Check GUI
Things to Note:
**Each button is clickable and causes the appropriate event to occur.
**Make sure that you cannot click through things
**Select each type of building and make sure the pop-up information is appropriate

*Check building placement
**Place each type of building
**Connect a mining building to a factory through a tube
**Connect a residential building to a factory through a road
**Once this is done, resources should increase.

**Connect a residential building to a commercial building
**Once this is done, the player's money should start increasing

**Check the building log to make sure that the build order is correct

*Check that mini-games can be accessed
**Attempt to play each mini-game through the colony simulator, executing all of their tests and checkin their appropriate logs

Stellar Prospector

*Play through the tutorial
Things to Note:
*Make sure that event codes are properly logged.
**Tasks match up with the specified text.
**Text does not run off the display.
**Input events still work when the player is prompted for them.
**Automated events such as energy drain and automatic grab still work.
**Tutorial returns to the main screen after ending.
**Make sure all graphical effects work correctly, i.e. tractor beam, explosion, and flickering.
**Player does not get locked in the game; player remains able to exit through the game menu if ESC is pressed.

*Play through the main game
Things to note:
**Make sure event codes are properly logged.
**Make sure input works correctly
**Phase changes occur correctly and at the right times.
**Energy draining and filling works correctly.
**Pause menu works correctly
**Game ends once energy bar is filled, and returns to the main menu
**Make certain that all graphical effects work correctly, i.e tractor beam, explosion, and flickering.

Code How To's

2009-03-03T23:10:32Z

Brb6127:

This page provides tutorials for some of the most common actions a programmer may wish to implement. It may helpful to read the [[Code Overview]] first.

==Submit a Bug or Other Issue==

* Go to http://www.AutismCollaborative.org/bugs/
* Fill out the fields that apply to this issue

'''Type of Bug:'''
* Functional Problem
** Any actual "Bug"
* Suggestion
** A possible change to the game that may improve it
* New Feature
** Something that '''absolutely must''' be implemented
** Use sparingly; make sure it's not actually a Suggestion

'''Severity:'''
* How much this issue affects the game/application

'''Priority:'''
* How soon the issue should be resolved (relative to other issues)
* The majority of issues should be Low priority
* Use High sparingly

==Coding Conventions==

* Place the name of the file, authors, and copyright info at the top of each file
** Any person who makes significant changes to a file should add their name to the list of authors in a file
*** This helps anyone reading the code because they know who to ask if they have a question about something
* All private and protected class member variables are lowerCamelCase
* Private/protected class member variables are preceded with "m" (ie mLocalVariable)
* All functions, properties (sometimes called "smart fields"), and public class variables are UpperCamelCase
* Public variables should only be used with small classes that are used by only one or two other classes
* This code is intended to be viewed by many people who do not have strong programming backgrounds, therefore documentation is '''very''' important
** Document the purpose of each class's member variables, either next to their declarations or as a summary for their property accessor
** Create a summary documentation block for every function unless it is extremely obvious
*** This can be done by placing the cursor above a function definition and typing "///"
*** This block shows up in Intellisense when writing that function in code
** Add a summary to any properties that are possibly confusing or not straightforward
** Document every step of each algorithm (except for very obvious function calls like ResetSettings();)
*** Someone should be able to read only the comments in a function and still understand what it does
** See MeteorMadness.cs for an example of the appropriate level of documentation
* See the Load a Texture section for naming conventions of texture assets

==Create a New Minigame==

For a step by step tutorial with code examples, see [[How_to_Make_a_Mini-Game]]

* Declare the class
** Create a new folder under ColonySimulator
** Create a new file in that folder named NewMinigame.cs where NewMiniame is the name of the new minigame
** Place all new minigame-specific classes in that folder
** Have the class derive from GameScreen
* Implement the Constructor
** Initialize game variables
** Declare a ScoreCard (see Scoring tutorial)
** Log the GameBegin code (see the Logging tutorial)
* Implement Update()
** Do not assume a constant call rate
*** This function will almost always be called 60 times per second, but that rate may vary depending on CPU load
*** At the beginning of each cycle, get the time since the last cycle like this:
**** float dt = gameTime.ElapsedGameTime;
*** Build the time into all movement and timers, for example:
myEntity.LifeSpan -= dt;
myEntity.Position += myEntity.Velocity * dt;
* Implement Draw()
** Be sure to call each entity's Draw and Update methods. Optional: Register all entities with the XNA game object.
This will have XNA automatically call their Draw and Update functions at appropriate times.
** Consider using a generalized render-queue such as GenericWorldSpace '''(not yet implemented as of October 2007)'''
** Use the Raise function to place the minigame gamescreen on the stack based game system.
* End the mini-game using Done function. This will pop the mini-game off the game stack, returning the game to the previous state.
** Flush the particle system (see the particles tutorial) if any emitters were created
** Log the GameEndSuccess/GameEndFailure code
** Show the score

==Use Images==

XNA supports most common types of images, including JPEG, GIF, DDS, etc.

===Load a Texture===

Before you can load a texture in code, though, you must add it to the content pipeline:

* Import the content into the project
** Browse to the appropriate folder in Visual Studio's Solution Explorer
*** For example, Content\MiniGames\MyImage.png
** Right-click on that folder and select Add->Existing Item
** Select the image to import

Once that's done, you can load it memory using the XNA content manager:

Texture2D myTexture = Content.Load(@"General\myTexture");

The XNA content manager defaults to the content folder of the project, so all addresses can be relative from there. Also, the name of the image should be the same as the asset name. This can be set in the properties window.

===Display a Static Image===

Before manually drawing something to screen consider using some type of game object, be it an Entity, HUD element, or even a Ticker (see the tutorials below). Game objects all know how to draw themselves, so it is unlikely that a minigame will need to draw something directly to the screen. Should the need arise, however, here's how it's done:

* Load it in code:
GraphicsDeviceManager gdm = ...; // This is declared in GenericGameManager.cs
ConentManager cm = ...; // Usually a parameter, as in Update(ContentManager content)
SpriteBatch sb = new SpriteBatch(gdm.GraphicsDevice); // Basically a wrapper for a DirectX render target
Texture2D texture = TextureManager.Load(@"Content\General\myTexture");
Rectangle destination = ...; // Display destination
Color tint = Color.White; // Tint the image with this color
float rotation = 0f; // Rotation (in radians)
Vector2 center = new Vector2(texture.Width / 2f, texture.Height / 2f); // Origin of rotation
float zDepth = 1f; // Order to draw sprites within this spritebatch

sb.Begin(SpriteBlendMode.AlphaBlend, SpriteSortMode.BackToFront, SaveStateMode.SaveState);

sb.Draw(
texture,
destination ,
null, // What part of the source image to sample from--null tells it to use the whole image
tint ,
rotation,
center,
SpriteEffects.None, // How to mirror the image
zDepth
);

sb.End();

===Display an Animation===

Animations are created using the AnimatedSprite class. Here's an example:

//Declare Animated Sprite
//Parameters: Game object, SpriteSheet as a Texture2D object, Position as Vector2, FrameSize as Vector2, Number of Frames
AnimatedSprite testAnimation = new AnimatedSprite(this, Content.Load<Texture2D>("TestSpriteSheet"), new Vector2(200, 300), new Vector2(64, 64), 16);
//Pass a reference to the SpriteBatch that the AnimatedSprite will use
testAnimation.SpriteBatch = spriteBatch;
//Turn on the Animation
testAnimation.Animate(true);
//Turn off the Animation
testAnimation.Animate(false);

*Do not forget to call the draw and update methods of the AnimatedSprite explicitly, or to add them to the XNA game.components array so as to allow XNA to call them.

==Create a New Type of Game Object==

All specific game objects (players, enemies, collectibles, projectiles, etc.) should derive from Entity. This gives them easy ways to draw themselves, move, collide with other entities, and be passed to many tAC_Engine functions.

==Get User Input==

'''DO NOT''' use the standard XNA keyboard accessors (Xna.Framework.Input.Keyboard) or mouse accessors (Xna.Framework.Input.Mouse) because tAC_Engine does a lot of caching and logging behind the scenes. Use the InputHandler instead.

===Keyboard Example===

// Bind the 'A' Key to the event 'PressedA'
mInputHandler.Bind(Keys.A, InputHandler.Trigger.Pressed, (int)EventCodes.PressedA);
...
InputEvent inputEvent = mInputHandler.GetNextEvent();
if (inputEvent.EventCode == (int)EventCodes.PressedA)
{
// The A key was pressed
}

===Loading Keybinds from a file===

// Load Bindings from 'keybindings.dat'
mInputHandler.LoadBindings(typeof(EventCodes), RootDirectory + @"\keybindings.dat");

The Bindings file is a plain text, human-editable file that takes the following form:

"Event Name" (tab*) "Key Name" (tab*) (flags*)

====Keybinding Examples====

Quit Escape
* Trigger the Quit event when Escape is pressed.

PlaceBuilding Left mouse
* Trigger the PlaceBuilding event when the Left ''Mouse Button'' is pressed.

ZoomInStop OemPlus released
* Trigger the ZoomInStop event when the Plus Key is ''released''.

==Manage a Heads Up Display==

Use the HUD class for any HUD element (like health bars, menu buttons, etc.). Typically, you'll want to create a class that inherits from Widget2D. See MeteorWidgets.cs for examples.

==Display Text or Icons with the Ticker==

string text = "w00t."; // Text to display (can be "")
Texture2D image = null; // Can also be set to an image
Vector2 imageSize = new Vector2(25f, 25f); // Size of the (optional) icon
Vector2 offset = new Vector2(700f, 50f); // This will display the ticker 700 pixels to the right of the screen's
// center and 50 pixels below the screen's center
Vector2 velocity = new Vector2 (-10f, 0f); // Move left 10 pixels per second
Ticker.Font font = Ticker.Font.Standard; // Regular text
Color color = Color.DeepPink; // The manliest of colors
float opacity = .5f; // 50% transparent
float seconds = 5f; // Disappear after 5 seconds
bool fade = true; // Fade in and fade out

Ticker.Display(text, image, imageSize, offset, velocity, font, color, opacity, seconds, fade);

==Display Text==

First you must import the desired font:

* Create an xml spritefont file for the new font called FontName.spritefont and set the desired values.

Now for the code:

ContentManager cm = ...;
SpriteBatch sb = ...;
SpriteFont = cm.Load<SpriteFont>(@"FontName");

sb.Begin();
sb.DrawString(SpriteFont, "Some Text!", new Vector2(10.0F, 10.0F), Color.Azure);
sb.End();

==Use Sound==

===Import a new Audio File===

** Run the XACT tool from Microsoft DirectX SDK
** If--after following the steps in this tutorial--playing a file in code throws an exception about using the wrong version of XACT, try using Xact.exe from a different SDK build
* Open AudioProject.xap file for the Minigame to which you wish to add a sound.
* Expand Wave Banks and double-click Wave Bank in the panel on the left
* Expand Sound Banks and double-click Sound Bank in the panel on the left
* Go to Wave Banks->Insert Wave File(s)...
* Select the file to import i.e."@/MiniGame/Content/Audio/MySound.wav" and click OK.
* Drag the newly-added file to the Cue Name section in the Sound Bank:Sound Bank window
* Assign the audio file to be either a Music or Effect sound
* Go to File->Build
* Save and close XACT
* Open game.sln with Visual Studio
* Browse to the Content\Sounds folder in the Solution Explorer
* Right-click the Sounds folder and select Add->Existing Item...
* Select "MySound.wav" and click OK

=== Load an Audio Project ===
This needs to be done before you play any sound or effect.
SoundManager.LoadAudioProject("AudioProject.xgs");

===Play an Effect===

SoundManager.PlayEffect("Pew"); // No file extension

===Play Music ===

SoundManager.PlayMusic("MyMusic");

==Use the Particle Engine==

Particles are handled by the TACParticleEngine, a separate library that uses the AC_GraphicsEngine that has been modified to better fit the needs of the Autism Game. Features are added to it on an as-needed basis so if a new feature needs to be added and any problems arise in its integration into the current particle engine contact Brian Murphy.

Quick layout of TACParticleEngine:

The ParticleManager contains references to all loaded ParticleEngines.
ParticleEngines contain a series of Emitters.
Emitters contain a heap of Particles, which are the objects that actually get drawn.

Make sure to include these packages so that we can create and access our particle engine objects:

using TACParticleEngine;
using TACParticleEngine.Particles;

Inside the class declaration make these global variables:

ParticleManager mParticleManager;
ParticleEngine mTestEffect;

Since the TACParticleEngine makes use of the Camera class from the AC_GraphicsEngine, we will need to create and initialize an instance of the Camera class if we are to render our particles, so let's get our camera set before we initialize the ParticleManager.

Add the following line to the list of global variables at the beginning of the class:

Camera mActiveCamera;

This will be whatever kind of camera we are currently using for drawing. (We may want other cameras, too, for whatever reason.)

Next we need to initialize the camera to any specific type of camera that derives from class Camera. At the time of this writing (January 2009) these types are limited to FollowCamera, OrthographicCamera, PerspectiveCamera2D, and PerspectiveCamera3D. For now we'll use a PerspectiveCamera3D as our active camera.

mActiveCamera = new Perspective3DCamera(new Vector3(0, 0, -5), Vector3.Zero, Vector3.Up, MathHelper.Pi/5, 1, 1, 100);

If we ever need to change the camera, be certain to update the active camera for the particle manager by calling
mParticleManager.SetActiveCamera(newActiveCamera);
where newActiveCamera is the camera that has just been changed to.

Now that we have a camera, make sure to initialize the particle manager (and optionally, some particle effects) in the class's initialize method:

mParticleManager = new ParticleManager(Game, mActiveCamera); // Initialize the particle manager object with a reference to the current
// game and to the current active camera
mTestEffect = mParticleManager.Load("ParticleEffects/Explosion"); // Load in the given particle effect file by giving the
// location at which it is compiled

Once this has been done, you'll have an effect loaded into the Particle Engine object '''mTestEffect''' via the Particle Manager. However the Particle Engine isn't worth much if it's never called on to do anything, so let's set up the rest of the code that's needed for updating and drawing:

To accomplish this, all we need to do is add the particle manager to the Game's list of components. This is done as follows:

AddComponent(mParticleManager);

Aside from this we need to set the draw order of the effects, at least generally by calling

mParticleManager.DrawOrder = DrawOrder; // The second DrawOrder being whatever draw order is desired

This will draw and update any particles that have been loaded by the Particle Manager and have been set active. However, the particle engine that we just created hasn't yet been set active, so do that now.

This is done by calling the following line whenever you would want drawing of that Particle Engine to occur.

mTestEffect.SetActive(true);

The particle engine instance '''mTestEffect''' is now active. If it were already active, its lifetime would have been reset to 0. (The lifetime of a particle engine starts at zero and increases until its maximum lifetime is reached, in which case the particle engine "dies" and becomes inactive.)

This same method can be used to stop the particle engine from creating any more particles, by supplying '''false''' as its parameter instead:

mTestEffect.SetActive(false);

A series of methods allow us to modify the drawing of the ParticleEngine:

SetSplineScale(float scale) // Given a float, scales the spline around the origin by the given amount every 1/10 of a second. Note that this only
// applies for all spline emitters in the engine.

SetEnginePositions(Vector3[] Positions) // Given an array of 3D vectors, we can change the shape of all spline emitters in the particle engine.

SetEnginePosition(Vector3 Position) // Given a 3D vector, we can move the whole particle engine to the desired position.

SetEngineColor(Vector4 Color) // Given a 4D vector of float values 0-1 in the form of RGBA, we can change the coloring of the whole particle engine
// Keep in mind that this applies that much of the emitters' texture for each value, so a black picture with 1,0,0,1 as
// its value will not be red but still black.

SetEngineSize(Vector2 Size) // Given a 2D vector, we can modify the dimensions of the particle image, this is always 2D since particles in 3D are
// simply billboard sprites.

SetEngineSpeed(float Speed) // Given a float, changes the speed at which particles initially move at.

SetEngineDirection(Vector3 Direction) // Given a 3D vector, changes the direction in which particles move at. This does not apply to point emitters.

SetEngineParticlesPerSec(float NumPerSec) // Given a float, sets the number of particles created in a second. Note that this value times particle
// lifetime should not exceed the amount of particles in order to insure consistent effects.

SetEngineParticleLifetime(float Lifetime) // Given a float, sets how long a particle lives for in seconds. Note that this should never be changed
// while an effect is active, otherwise inconsistencies in the effect will most likely occur.

SetRandomDirection(bool Random) // Given a boolean, sets whether or not to make particles move in a random direction.

Also, if needed you can change the draw order of each engine individually by calling

mTestEffect.DrawOrder = DrawOrder; // The second DrawOrder is whatever draw order desired

Whenever a game object that uses a particle effect is being disposed, make sure to call

mTestEffect.SetActive(false); // Making sure to set the effect to no longer being active

on any effect with infinite life span and make sure to call

mTestEffect.ToDestroy = true; // Making sure to set the effect to no longer being alive

so that the particle manager knows that it can clean up the effect.

===Create a New Particle Effect===

To create a new particle effect, start the TACParticleEditor program. This program presents two windows, one containing a Windows form displaying information about the current particle effect, and the other displaying the particle effect.

There are four main areas of the particle editor form:

List of emitters - The list of all the emitters in the particle effect.

Emitter type - Contains all the different types of emitters that exist in the particle engine.

Row of buttons - Each having a functionality expected from their name:

Add - Adds an emitter of the chosen type from the list of emitter types to the particle effect's emitter list.

Remove - Removes the currently selected emitter in the particle effect's emitter list from the list.

Save - Saves the current particle effect to a specified .particle xml file.

Load - Loads a particle effect from a selected .particle xml file.

Emitter Info Grid - Contains all the information that can be modified for whichever emitter in the list of emitters is currently selected.

The modifiable parameters of the emitters are as follows:

For all emitters:

textureName - The file path name of the texture to render the particles with. In order to load texture names correctly, there
must exist a texture folder in the current project's compiled content folder. The default starting directory is the TACParticleEditor.
Whenever a new particle effect is loaded, the current directory is switched to that project's content directory. Anytime a new
texture is desired, it must be added manually to the appropriate project.

blendEffect - The sprite blend to use when rendering the particles. Can be either None, AlphaBlend, or Additive.
The various blend modes work as follows:

None - every particle draws exactly as how the texture appears and no alpha values are used. Therefore there will be no transparency.
For visual purposes it is highly suggested to not use this mode.

AlphaBlend - Averages all of the particles alpha values up to the max value assigned to any particle. This effect is useful in creating
effects such as dust, smoke, or gas clouds.

Additive - Sums up the colors of all the particles to the maximum value of 1.0 for all values (r,g,b, and a). This effect is useful
in creating effects such as fire, lasers, or shields.

emitLifetime - The duration of time the emitter continues to emit new particles for in seconds. This can be any duration of time. A negative
value denotes that the emitter never dies.

particlesPerSec - The amount of particles that are created every second. This can be any nonzero positive integer.

particleAmount - The total amount of particles that can appear on screen at one time. This can be any nonzero positive integer.

particleLifetime - The amount of time a particle lives for in seconds. This can be any nonzero positive number.

minStartSpeed - The slowest possible speed at which a particle can start moving. This can be any number, since a negative value just means
that the particle will move in the opposite direction.

maxStartSpeed - The fastest possible speed at which a particle can start moving. This can be any number, since a negative value just means
that the particle will move in the opposite direction.

minEndSpeed - The slowest possible speed at which a particle can end moving . This can be any number, since a negative value just means
that the particle will move in the opposite direction.

maxEndSpeed - The fastest possible speed at which a particle can end moving. This can be any number, since a negative value just means
that the particle will move in the opposite direction.

minStartColor - The minimum color values that a particle can start at in r,g,b,a form (i.e. red, green, blue, alpha). These values can be any
number between 0.0 and 1.0.

maxStartColor - The maximum color values that a particle can start at in r,g,b,a form (i.e. red, green, blue, alpha). These values can be any
number between 0.0 and 1.0.

minEndColor - The minimum color values that a particle can end at in r,g,b,a form (i.e. red, green, blue, alpha). These values can be any
number between 0.0 and 1.0.

maxEndColor - The maximum color values that a particle can end at in r,g,b,a form (i.e. red, green, blue, alpha). These values can be any
number between 0.0 and 1.0.

minstartSize - The smallest size that a particle can start at in width,height form. These values can be any nonzero positive number.

maxStartSize - The largest size that a particle can start at in width,height form. These values can be any nonzero positive number.

minEndSize - The smallest size that a particle can end at in width,height form. These values can be any nonzero positive number.

maxEndSize - The largest size that a particle can end at in width,height form. These values can be any nonzero positive number.

isActive - Whether or not the emitter is currently spawning/updating/drawing particles. You can quickly activate all emitters
of the loaded/created particle effect by hitting enter while having focus on the particle effect visualization window.

For directional emitters:

positions - The position in which particles will spawn in x,y,z form (aka a 3-dimensional point). These values can be any number.

minVel - The minimum velocity direction in which particles can move at in x,y,z form (aka a 3-dimensional vector going outward from the
position point). These numbers can range from -1.0 to 1.0.

maxVel - The maximum velocity direction in which particles can move at in x,y,z form (aka a 3-dimensional vector going outward from the
position point). These numbers can range from -1.0 to 1.0.

For point emitters:

positions - The position in which particles will spawn in x,y,z form (aka a 3-dimensional point). These values can be any number.

For spline emitters:

positions - The positions at/between which particles will spawn in x,y,z form (aka list of 3-dimensional points). These values can be
any number.

direction - The velocity direction in which particles will move in x,y,z form (aka a 3-dimensional point). (aka a 3-dimensional vector
going outward from the position point). These numbers can range from -1.0 to 1.0.

scale - The amount of scaling that occurs every time the spline emitter is scaled, that is to say, how much all positions
close in/expand from the origin (0,0,0) before any position offset is applied essentially creating an explosion or implosion
effect. This value can be any nonzero positive number. 1.5 represents 150% current size, 0.5 represents 50% current size, etc.

scaleSpeed - How quickly the scaling occurs in seconds. This can be any nonzero positive number. 1 is a scaling occurs once every second,
0.5 is a scaling occurs every half second, etc.

For spray emitters:

positions - The position in which particles will spawn in x,y,z form (aka a 3-dimensional point). These values can be any number.

direction - The velocity direction in which particles will move in x,y,z form (aka a 3-dimensional point). (aka a 3-dimensional vector
going outward from the position point). These numbers can range from -1.0 to 1.0.

sprayRange - The area in which particles can spawn with the center at the set position in +/-x,+/-y,+/-z form. That is to say a cubic area
with dimensions width, height, and depth and its origin at the given position. These values be any nonzero positive number.

====Quick Reference Table====

'''Parameter''' '''Parameter type''' '''Unit type''' '''Range'''
''For all emitters:''
textureName String N/A Any valid path name works.
blendEffect SpriteBlendMode N/A None, AlphaBlend, or Additive.
emitLifetime floating-point Seconds Any value. Negative value denotes emitter never dies.
particlesPerSec integer Per Second Any nonzero positive number.
particleAmount integer N/A Any nonzero positive number.
particleLifetime floating-point Seconds Any nonzero positive number.
minStartSpeed floating-point Arbitrary Any number. Negative value denotes movement in opposite direction.
maxStartSpeed floating-point Arbitrary Any number. Negative value denotes movement in opposite direction.
minEndSpeed floating-point Arbitrary Any number. Negative value denotes movement in opposite direction.
maxEndSpeed floating-point Arbitrary Any number. Negative value denotes movement in opposite direction.
isActive boolean N/A True or False.
minVel (x,y,z) vector Arbitrary Any number within -1.0 to 1.0.
maxVel (x,y,z) vector Arbitrary Any number within -1.0 to 1.0.
positions (x,y,z) vector Arbitrary Any number.
direction (x,y,z) vector Arbitrary Any number within -1.0 to 1.0.
''For spline emitters:''
scale floating-point % of size Any nonzero positive number. < 1 denotes decrease, > 1 denotes increase.
scaleSpeed floating-point Seconds Any nonzero positive number.
''For spray emitters:''
sprayRange (width,height,depth) Arbitrary Any nonzero positive number.

*Note that all arbitrary values are based on the current camera space.

==Keep Score and Give Resources to the Simulator Mode==

Use the ScoreCard class to keep track of the score from a minigame. It provides easy ways to add and subtract resources, as well as an easy way to display them and pass them along to the Colony Simulator.

MiniGame has a ColonyScoreCard built into it, accessible by the Score property. Here are some examples of how to use it:

class MyGame : MiniGame
{
public override void Update(ContentManager content)
{
Score.Gather(ColonyResources.Money, 500); // Get 500 Monies

MyGameObject mgo = new MyGameObject();
mgo.GiveMyGameCarbon(); // Get 1 Carbon

Score.IncurDamageCost(100); // On CashOut, Money = Max (Money - DamageCosts, 0)

int HowMuchMoneyIHave = Score.QueryResource(ColonyResources.Money);
}

public void DisplayTheScore()
{
bool playerWonTheMinigame = true; // Can be set to false if the player lost
Score.Display(playerWonTheMinigame ); // Displays a copy of the current score and a message for succses/failure
Score.CashOut(); // Transfers resources from MyGame to the Colony Simulator
}

// ...
}

class MyGameObject : Entity
{
public void GiveMyGameCarbon()
{
ColonyBaseApplication.MiniGame.Score.Gather(ColonyResources.Carbon, 1);
}
}

**Note: The code provided here is very subject to change as this section is under development.

==Write to the Experiment Log==

As the game runs, certain actions are recorded and written to a file (My Documents\Autism Collaborative\Users\DefaultUser\LogFiles\ExperimentLog.txt or as specified). In the lab, these codes are also sent through the parallel port to sync the EEG data. Every action that pertains to an experiment must be logged in order to be analyzed. (That's the whole point of this game!)

First define the necessary game codes. This is done to ensure consistency across each mini-game.

* Open EventCodes.cs, or wherever you store the enum for your project.
* Codes in the range 1 - 255 are valid and can be written to the parallel port.
** The name of the code should be chosen at your convenience, and may be included to make the text log file more readable.
* Codes may be assigned outside this range, both positive and negative; these codes may be used in the same way, but will be logged only to the text log file and not to the parallel port.
** Codes in the negative range are considered debugging codes, and can be omitted from the log file by setting the writeDebugEvents property on the logger.

Now those codes are available for logging, thus:

Logger logger = new Logger("ExampleLogFile.txt");
logger.LogCode( (int)Minigame.EventCode.WeaponFiredEvent, "WeaponFired" );

It is also possible to tell the logger to log a code every time a specific key is pressed:

InputHandler inputHandler = new InputHandler(true);
inputHandler.Bind(Keys.A, InputHandler.Trigger.Pressed, (int)Minigame.Eventcode.PressedAEvent);

As these assigned events are local to each InputHandler object, your mini-game's event code assignments will not interact with the event code assignments of other mini-games.

Every mini-game should start with its GameBegin and end with its GameEnd[Success/Failure] codes.

It may be helpful to log events for debugging purposes. These codes should have an identifier such as "DEBUG_" and will not be logged unless writeDebugEvents is set to true on the logger. (writeDebugEvents is true by default only when the game is running in Debug mode.) All new DEBUG tags must be explicitly assigned a value less than 0.

===Event Code Summary===

Event Codes may be any integer value.
* Less than 0 : Debug events, will only be written in Debug Mode.
* 0 : Null, no event.
* 1 - 255 : Experimentation event, will be written to the log and the parallel port.
* Greater then 255 : Cannot be written to the parallel port, will be written to log only.

==Use the Game Script==
*Note: The LUA scripts are not universally compatible and have been known to crash on some machines. It is highly recommended that C# scripts are used.

The tAC_Engine houses a [[http://www.lua.org/ Lua]] Virtual Machine. This can be used to tweak global parameters at runtime, load them from config files, drive cutscenes, or even save and load levels.

Function callbacks are defined in C# and then invoked from a Lua file or the in-game Debug console. In other words, C# tells Lua "you may use these functions: X,Y,..." and then Lua says "do X, do Y, etc."

Here are a couple of ways to leverage this system:

===Make a Cutscene===

* Create a new lua file in the Scripts directory
** That file can call any registered function callbacks
* In the Properties window, set Copy to Output Directory to Copy if Newer
* Call that cutscene with:
GenericBaseApplication.GameManager.PlayCutscene(@"Scripts\MyCutscene.lua");

===To Register a Function Callback===

* Create the function in C# (if the function does not already exist)
** It must be declared public and non-static
** If the need arises to register a static function, declare an instanced function in GenericLuaHelper or ColonyLuaHelper that simply calls the static function.
* Register the function with the Lua Virtual Machine
** Add the special LuaCallback annotation to the function
* Call the RegisterLuaCallbacks function in the class's constructor that contains the function.
* Example:
public MyClass()
{ // Constructor
LuaHelper.RegisterLuaCallbacks(this);
}

[LuaCallback("SetMyVariable")]
public int SetMyVariable(int value)
{
mMyVariable = value;
}

===Tweak Game Parameters===

Exposing a variable to the Lua Virtual Machine allows it to be accessed by a any script (including config files) or changed at runtime in the drop down console (accessible in Debug mode by hitting "~").

* Expose a variable with a global setter/getter with a LuaCallback annotation
** Make sure to call the RegisterLuaCallbacks function in that class's constructor if the getter/setter is not in the Game Manager
* Set the default value for the variable in the config file (optional)
** There are 3 config files for the 3 configurations of the game builds
*** Debug.conf, for development
*** StandardRelease.conf, for public releases of the game
*** LabRelease.conf, for use in the lab

===Create Local Settings===

Programmers may want to change certain properties on their machines without affecting the source-controlled code. They could change the resolution, sound settings, or even have the game bypass the regular startup sequence and launch right into the middle of a MiniGame all with no effect on other developers.

* Create a new file: Autism Collaborative\Game\Game\Scripts\LocalSettings.lua
** The Visual Studio project already has this file included, but VS won't be able to edit it until the file is created manually
* Add Lua commands and save the file
** Visual Studio can now be used to edit the file
* The file is run at the end of the Debug.conf script (if it exists)
** That means that this script is only run in Debug mode
* do '''NOT''' add LocalSettings.lua to source control!

===Creating Scripts in C# Code===

Alternatively, scripts can created using C# code rather than Lua. A C# script either be object oriented or imperative. They are able to both take in objects and return values. The CSharpHelper class can be called to run these scripts using its DoSimpleFile method. This will simply run all the code in the script. The value of this is that commonly edited code, such as configuration files, can be saved in a convenient separate location. The methods for CSharpHelper are well documented within the file itself. An example of a basic call to a C# script is as follows:

CSharpHelper.doSimpleFile(Environment.CurrentDirectory + @"\Configs\DebugConfig.script", this, "game");

This starts a C# file called "DebugConfig.script" which is located in the Configs directory. The second parameter is a Game object. The object passed in can be of any type. The third parameter is the identifier of the object within the script. In this case the identifier is "game". This means that inside the script, lines such as:

game.Update();

will execute the passed-in object's Update function.

==Publish the Installer==

===Create the Installer===

We use InnoSetup to create the installer. Checkout their website (http://www.jrsoftware.org/isinfo.php) if you need to change the script, but simply publishing the game does not require any adjustment to the installer script.

* Install InnoSetup if necessary
* Compile the game
** In the second menu bar (immediately below the top menu bar) within Visual Studio, change "Debug" to "Release". (In the box to the right, leave the default "Mixed Platforms".)
** Select Build->Build Solution
* Compile the installer script
** Open Autism Collaborative\Game\Installer\Installer.iss with InnoSetup
** Select Build->Compile
*** This creates the file Autism Collaborative\Game\Game\Output\AstropolisSetupLite.exe
*** When the compilation is finished, it will ask if you want to test the installer. It is recommended to test it, but not required.
* Repeat the last step with InstallerFull.iss if desired, this will generate AstropolisSetup.exe, which contains the full offline installers for the dependencies. This is necessary for the lab computers which may not have internet access.

===Upload the Installer to the Web===

* Get a username/password for autismcollaborative.org from Matthew.
* To transfer the file, use an SSH client such as WinSCP (for a graphical interface) or PuTTY's PSCP (from the command line)
** Either download it or run Autism Collaborative\Utilities\WinSCP.exe
* Log in to AutismCollaborative.org (port 22)
* Upload AstropolisSetup.exe to your home directory (for example /home/zinsser)
** Do not overwrite the existing installer (/home/belmonte/autismcollaborative.org/downloads/AstropolisSetup.exe) since that would delete the installer from the web site until the new installer finishes uploading
* Once the upload is complete, ssh into a shell and enter the command "mv /home/{$user}/tAC_Installer.exe /home/belmonte/autismcollaborative.org/downloads/AstropolisSetup.exe" (you may have to open a terminal first, depending on your SSH client)
** If there is a permissions problem, contact Matthew to make certain that your user ID has write and search permission for the autismcollaborative.org/downloads directory.

==Using the Mini Game Score Screens==

The Mini Game Score Screens are implemented in a class within the tAC_Engine. This class is utilized to encapsulate the behavior for the displaying the scores of mini games uniformly to players, while also allowing a uniform means of exiting the mini game. All mini games utilize the 2 screen approach (one for the menu for the game, one for the actual game) on top of tyhe stack. Because of this, the mini game score screen allows the direct exiting of a mini game after it has been played, returning back to the Colony Simulation or previous game screen on the stack, before the mini game was selected.

This is done by clicking the Exit button in the score screen, which performs 3 Done() operations on the stack.

==Use the ErrorLog==

When the game encounters an Unhandled Exception (such as when an end user runs into a bug in our code), useful information is dumped to ErrorLog.txt. The user is encouraged to email that file to us so that we can locate the problem. Although the ErrorLog will tell us what function the program died in, it cannot tell us specifically which line was the culprit (although ErrorLogs created when the game is running in Visual Studio will tell us exactly which line).

We do, however, have the ability to log any custom information from a mini-game. This ability may prove invaluable in debugging based on end-user error reports. All that you (the programmer) must do is override the string MiniGame.DebugInfo() function. When ErrorLog.txt is created, it calls that function on the current MiniGame and appends the returned text to the bottom of the file.

==Testing Procedure==

This is a list of recommended tests to be performed on a regular basis to ensure that the major functionality of the program is intact.

Maritime Defender

*Play through tutorial
Things to Note:
**Text does not run off screen
**Dialog boxes wait for the space bar to be pressed before disappearing
**During the navigation-phase tutorial, input is registered correctly

*Play through main game
Things to Note:
**Collision detection is correct
**Phases are in the correct order
**Navigation phase looks correct: Dots are the correct size and dot correlation fits PEST data. Look for any slowdown or loss of frames.
**Boss fight is correct. Boss takes damage and causes the player damage.
**Player Health is displayed correctly on taking damage.

Colony Simulator

*Check GUI
Things to Note:
**Each button is clickable and causes the appropriate event to occur.
**Make sure that you cannot click through things
**Select each type of building and make sure the pop-up information is appropriate

*Check building placement
**Place each type of building
**Connect a mining building to a factory through a tube
**Connect a residential building to a factory through a road
**Once this is done, resources should increase.

**Connect a residential building to a commercial building
**Once this is done, the player's money should start increasing

**Check the building log to make sure that the build order is correct

*Check that mini-games can be accessed
**Attempt to play each mini-game through the colony simulator, executing all of their tests and checkin their appropriate logs

Stellar Prospector

*Play through the tutorial
Things to Note:
*Make sure that event codes are properly logged.
**Tasks match up with the specified text.
**Text does not run off the display.
**Input events still work when the player is prompted for them.
**Automated events such as energy drain and automatic grab still work.
**Tutorial returns to the main screen after ending.
**Make sure all graphical effects work correctly, i.e. tractor beam, explosion, and flickering.
**Player does not get locked in the game; player remains able to exit through the game menu if ESC is pressed.

*Play through the main game
Things to note:
**Make sure event codes are properly logged.
**Make sure input works correctly
**Phase changes occur correctly and at the right times.
**Energy draining and filling works correctly.
**Pause menu works correctly
**Game ends once energy bar is filled, and returns to the main menu
**Make certain that all graphical effects work correctly, i.e tractor beam, explosion, and flickering.

End-user Setup

2008-12-10T03:24:20Z

Brb6127:

Each Minigame has a variety of settings that can be configured individually.

==Config==

The Config.script file holds general settings. It can be opened with any general text editor, such as notepad. Each line ending with a semicolon (;) indicates a command for the game to follow. Lines beginning with two forward slashes (//) are considered comments, and will not be processed. A block comment is a section beginning with (/*) and ending at (*/).

===Location===

[Installation Directory]\Configs\Config.script

The Global Config.script can be found in the Configs folder under the Autism Collaborative folder -- typically C:\Program Files\Autism Collaborative\Configs\Config.script. This holds global settings that will be applied automatically when the game starts. Individual minigames may have individual configurations specific to those minigames. This individual config file is also call Config.script, and can be found in the Configs folder under the minigame's folder -- typically C:\Program Files\Autism Collaborative\Minigames\[MiniGameName]\Configs\Config.script.

===Global===

Util.Settings.SetResolution([horizontal],[vertical]);
* Set the screen resolution this game will be played at, for example, Util.Settings.SetResolution(1024,768);

Util.Settings.FullScreen = [true/false];
* Set whether the game window will be fullscreen, for example, Util.Settings.FullScreen = true;

Util.Settings.ParallelPortEnabled = [true/false];
* Set whether codes should be written out the Parallel Port, for example, Util.Settings.ParallelEnabled = true; If not specified, this will default to False.

Util.Settings.ParallelPort = ParallelPort.Port1;
* Set which Parallel Port codes should be written to, if enabled. Valid values are Port1, Port2, and Port3. Defaults to Port1.

Util.Settings.SetScreenDimensions([Width], [Height], [Distance]);
* Width is the width of the display, in centimeters. Height is as height of the display, in centimeters. Distance is the distance between the display and the viewer's eyes, in centimeters. For the dot coherence phase of Maritime Defender, the dots are based on the size of the visual display as it appears to the player. For example, Util.Settings.SetScreenDimensions(8.5, 6.25, 24.0);

===Maritime Defender===

MaritimeDefender.Settings.DotsPerSquareRadian = [Number];
MaritimeDefender.Settings.DotsPerSquareDegree = [Number];
* For the dot coherence phase, the dots are based on the size of the visual display as it appears to the player. This sets the density of the dots as they appear on the screen. Either measure, radians or degrees, may be used. For example, MaritimeDefender.Settings.DotsPerSquareRadian = 10000.0;

MaritimeDefender.Settings.DotsPerRadian = [Number];
MaritimeDefender.Settings.DotsPerDegree = [Number];
* Specify the dot density as the number of dots within a circular patch of screen space with a diameter of one radian or degree of visual angle as it appears to the user.

MaritimeDefender.Settings.NumberDots = [Number];
* Override the above settings, specifying exactly the number of dots that should be drawn on the screen. This setting is optional.

MaritimeDefender.Settings.DotDiameter = System.Math.PI / 1028;
* Affects the average size of the coherence dots in terms of radians.

MaritimeDefender.Settings.DotSpeed = System.Math.PI / 16;
* Affects how fast the coherence dots appear to move across the screen in terms of radians per second.

MaritimeDefender.Settings.DotLifeSpan = 4 / 60.0;
* How long each dot exists on the screen. 4 / 60.0 reflects 4 frames on a 60 hertz display.

MaritimeDefender.Settings.DotRefreshDelay = 1;
* Additional Delay in seconds between each dot test, for the EEG readings. This is in addition to a random jitter of, by default, between 0 and 150ms; this jitter is controlled by the DotRefreshDelayJitter.

MaritimeDefender.Settings.DotRefreshDelayJitter = 0.15;
* A random amount of jitter between 0 and [value] seconds will added to the DotRefreshDelay so that the time between two successive coherence trials is not constant. The default is 0.15 of a second, or 150 milliseconds.

MaritimeDefender.Settings.DotResponseWait = 0.5;
* The duration of time in seconds immediately after a trial with no response in which late responses can be excepted.

MaritimeDefender.Settings.DotTrialLength = 2;
* The average duration of a dot test trial in seconds.

MaritimeDefender.Settings.SetPhaseQueue(2, "IdentityTest, 1, Shooter, 3, DotTest, 140, Shooter, 3, DotTest, 140, Shooter, 3, DotTest, 140, Shooter, 1, Boss, 0");
* The game phases for Maritime Defender. A list of pairs, a name and a value. Currently, the Game must start with an IdentityTest phase. The Shooter value is how many wormholes must be opened and ships identified in order to move on to the next Phase. The DotTest value is how many dot trials will take place during that phase, where a trial may be a motion of dots, or an absence of motion.

MaritimeDefender.Settings.HaveNonCoherentTrials = false;
* Whether NonCoherentTrials should be included. If false, there will be coherent motion to the left or right for every trial.

===Stellar Prospector===

StellarProspector.Settings.StimulusWaitMax = 1500f;
* The maximum amount of time in milliseconds before a stimulus must appear after the offset of the previous stimulus.

StellarProspector.Settings.StimulusWaitMin = 500f;
* The minimum amount of time in milliseconds before a stimulus can appear after the offset of the previous stimulus.

StellarProspector.Settings.DistractorWaitMax = 10000f;
* The maximum amount of time in milliseconds before a distractor must appear after the offset of the previous distractor.

StellarProspector.Settings.DistractorWaitMin = 2000f;
* The minimum amount of time in milliseconds before a distractor can appear after the offset of the previous distractor.

StellarProspector.Settings.DistractorLifeMax = 10000f;
* The maximum amount of time in milliseconds that a distractor can live for after it has been created.

StellarProspector.Settings.DistractorLifeMin = 2000f;
* The minimum amount of time in milliseconds that a distactor must live for after it has been created.

StellarProspector.Settings.StimulusLifeMax = 6000f;
* The maximum time in milliseconds that a stimulus can be displayed.

StellarProspector.Settings.StimuliPerCueMin = 1;
* The minimum number of stimuli that must appear before the cued sector can change.

StellarProspector.Settings.StimuliPerCueMax = 1;
* The maximum number of stimuli that can appear before the cued sector must change.

StellarProspector.Settings.MaxProgress = 100;
* The amount of progress needed to completely finish the game. This is in arbitrary units.

StellarProspector.Settings.PeripheralProgress = 5;
* The maximum amount of progress the player can receive from correctly responding to peripheral stimuli. In the same arbitrary units as max progress.

StellarProspector.Settings.ProgressLostPerMiss = 1;
* The amount of progress lost anytime an incorrect response is given

StellarProspector.Settings.CentralStimulusProgressDrain = 1;
* Amount of progress drained every 2 seconds during a central stimulus

StellarProspector.Settings.CenterHertz = 10f;
* The rate a which the center flickers in Hertz

StellarProspector.Settings.Sector1Hertz = 12f;
* The rate a which sector 1 flickers in Hertz

StellarProspector.Settings.Sector2Hertz = 15f;
* The rate a which sector 2 flickers in Hertz

StellarProspector.Settings.Sector3Hertz = 20f;
* The rate a which sector 3 flickers in Hertz

StellarProspector.Settings.Sector4Hertz = 30f;
* The rate a which sector 4 flickers in Hertz

==Keyboard Configuration==

Keyboard bindings are stored in a separate file, also specific to each minigame. It is stored as a list of in-game events, each followed by the action that triggers it.

Quit Escape
* Trigger the Quit event when Escape is pressed.

PlaceBuilding Left mouse
* Trigger the PlaceBuilding event when the Left ''Mouse Button'' is pressed.

ZoomInStop OemPlus released
* Trigger the ZoomInStop event when the Plus Key is ''released''.

==Logging==

The current default path for the log file is in the Application Data folder. The exact location will vary depending on the operating system installed.

Vista: C:\Users\[WindowsLoginName]\Documents\Roaming\Autism Collaborative\

XP: C:\Documents and Settings\[WindowsLoginName]\My Documents\Autism Collaborative\

The documentation for the building placement log for the Colony Simulation can be found here -> [[Building_Placement_Log_Specification]].

Building Placement Log Specification

2008-12-10T03:20:58Z

Brb6127:

The building placement log follows the following specification:

Game/Time System Time Event Code Message

<br />
Game/Time - This defines at what time during the game the current building action occurred.
<br />
System Time - The current system time for the Operating System.
<br />
Event Code - This option is not utilized for the logging of buildings.
<br />
Message - This is the message for the placement or deletion of a structure from the colony Simulation.
<br />
<br />
The format is one of the following:

<br />
Add Structure: Structure_Name - This is for a structure added to the Colony Simulation.
<br />
Structure Removed: Structure_Name - This is for a structure removed from the Colony.

<br />
The log is ended by End Log in the message section.

Building Placement Log Specification

2008-12-03T00:47:16Z

Brb6127: New page: The building placement log follows the following specification: Game/Time System Time Event Code Message Game/Time - This defines at what time during the game the curr...

The building placement log follows the following specification:

Game/Time System Time Event Code Message

Game/Time - This defines at what time during the game the current building action occurred.
System Time - The current system time for the Operating System.
Event Code - This option is not utilized for the logging of buildings.
Message - This is the message for the placement or deletion of a structure from the colony Simulation.
The format is one of the following:

Add Structure: Structure_Name - This is for a structure added to the Colony Simulation.
Structure Removed: Structure_Name - This is for a structure removed from the Colony.

The log is ended by End Log in the message section.

Art Assets and Tracking

2008-10-10T18:07:51Z

Brb6127: /* Models */

== Look and Feel ==

We're going for a Sci-Fi look where the feel is somewhere between World of Warcraft and Starcraft, a bright upbeat mood.
For the color pallet something like Age of Empires III, bright base colors with tasteful splashes of color that highlight buildings and units.
Our buildings should represent free floating entities in space that are connected via a transportation system. This is similar to how Bio Shock represents Rapture, underwater buildings connected via tubes, but ours will be in space and not in the 1920's.

[http://empireearth.free.fr/aoe-iii/age-of-empires-iii.jpg Example Age of Empires III with Tasteful Color Splashes]

== Requirements==

===Models===
Models should follow the look and feel specifications. Models should be able to be placed or combined as in a tile based system.

===Complexity===
Models should be complex, but still keep a low polygon count. Model complexity and polygon limits will be further defined as we do more extensive testing of our 3D Engine.

===Textures===
All textures should be included in the model file. If they can't be extracted form the SketchUp file then they will also need to be included as *.png files. Textures file dimension should in power of twos( 2x2,4x4,16x16,32x32,64x64, etc) and should be kept as small as reasonably possible.

===Submission===
Models will be uploaded to the Google Warehouse. Depending on our needs we may also need to have the models uploaded to a folder on our SVN repository.

== Colony Simulation ==

=== Models ===

{| border="1" cellpadding="6"
|-
! Asset Name
! Description
! Scale (World Units)
! Artist Assigned
! Status
! Priority
|-
| Command Center
| This is the building that will begin the construction of the colony. It is the first thing that the player is required to place.
| 3 x 3
|
| Concept Art Needed
| High
|-
| Low Quality Residential Building
| This is the low quality living quarters of the colony. As opposed to the high quality residential building, the focus on its design is to efficiently fit as many of the populace inside as possible. It could be equated to the "projects" of the space colony. There are tier 1 and tier 2 version.
| 2 x 2
|
| Concept Art needed
| High
|-
| High Quality Residential Building
| This is the high quality living quarters of the colony. It's focus on the comfort the populace who live in it. Less people live here, but they are happier and live in luxury. There are tier 1 and tier 2 versions.
| 2 x 2
|
| Concept Art Needed
| High
|-
| Mining Building
| This building is placed on top of a resource square in order to harvest it. This is not tiered, meaning there is only one version.
| 1 x 1
|
| Concept Art Needed
| High
|-
| Resource Models
| These are going to be used to represent the three different resources available to harvest on the map. What they are exactly, and how they look has been undecided. Things such as small gas nebulae, small chunks of rock, or small chunks of ice would all work. The only thing necessary is that there are three different kinds.
| 1 x 1
|
| Google Model in use, though a lower polygon model would be helpful.
| Low
|-
| Commercial Buildings
| These are buildings that the populace will travel to in order to buy goods and services. This category includes things such as shops, malls, and places for the populace to buy food, such as farms. These will take in resources to create their goods. If that could be worked into the designs, that would be good, but it does not need to be. There exists three of these buildings in tier 1 and three of these buildings in tier 2.
| 2 x 2
|
| Concept Art Needed
| High
|-
| Factory Buildings
| These buildings refine the resources into higher tier levels. For example a tier 0 (raw) resource would be refined into a tier 1 (basic) resource. Ideas for this were refinery and industrial type buildings. There is one of these resources at tier 1 and one of these at tier 2.
| 2 x 2
|
| Concept Art Needed
| High
|-
| Entertainment Building
| The purpose of this building is to increase the happiness of the populace. These buildings include things like arcades and amusement parks. There are two of these in tier 1 and two of these in tier 2, though a texture swap in between tiers would be fine.
| 2 x 2
|
| Concept Art Needed
| High
|-
| Resource Transport Rings
| A series of rings which the transport ships will pass through. These ships will move the resources throughout the colony. Models will be needed for straight sections, elbow joints, T joints, and four way intersections.
| 1 x 1
|
| Google Model in use at the moment
| High
|-
| Resource Transport Ship
| The ship which carries resources from one building to another through the tubes. Different models for each resource would be nice, though a simple color swap would be just as effective.
| 1 x 1
|
| Google Model in use at the moment
| Medium
|-
| Space "Roads"
| This is the transport system for the populace. This transports people around the colony. The term road is used loosely since a system of transparent tubes would work just as well. Models would be needed straight sections, elbow joints, T joints, and four way intersections. Even something as simple as a new texture on the Resource Transport Rings would work.
| 1 x 1
|
| Concept Art Needed
| Medium
|-
| Space "Road" Transport Unit
| This is what carries the populace throughout the transport tubes. This could be things like a ship, "space cars", or even people moving with jetpacks. This is purely a visual thing for the player so any of these would work. If need be, a texture swap could be done on the Resource Ships to make this model.
| 1 x 1
|
| Concept Art Needed
| Medium
|-
| Reward Buildings
| These buildings are rewards given to players to give them a sense of achievement and advancement. They are purely visual rewards, and at the moment, none of them have been decided. The can be anything that is interesting and fun, though they should be unique so that the player feels that they are something special when they are unlocked.
| Variable (1 x 1, 2 x 2, 3 x 3, etc)
|
| Concept Art Needed
| Low
|}

=== Textures ===

=== Sounds ===

== Meteor Madness ==

=== Models ===

=== Textures ===

=== Sounds ===

== Hacker Havoc ==

=== Models ===

=== Textures ===

=== Sounds ===

== Stellar Prospector ==

=== Models ===

=== Textures ===

=== Sounds ===

Colony Sim Milestones

2008-10-08T17:24:11Z

Brb6127: New page: ==Purpose== This page delineates the milestones for the Colony Sim. These are attributed by date and the tasks that are to bee completed. For current milestones, the people who are assign...

==Purpose==

This page delineates the milestones for the Colony Sim. These are attributed by date and the tasks that are to bee completed. For current milestones, the people who are assigned the task will also be noted.

==Milestones==

===October 15, 2008===

# Implementation of Tiers and Mini-Game Rewards (Brad)
# Residential and Resource Graph Implementation (Adam)
# Build Area Mechanics Implemented (Mike)
# Beginning the Design of the Save and Load Protocols for the Colony Sim (Mike)

===October 22, 2008===

# Polished Camera Controls: Zoom Limitations, Movement Limits, Panning
# Design and Implementation of the Save and Load Protocols.

===October 25, 2008===

# GUI Redesign.

===October 29, 2008===

# GUI Implementation.

===November 1, 2008===

At this point, the game may not be polished, but it should be completely stable for play and use.

Colony Mode

2008-10-08T17:13:12Z

Brb6127:

This mode refers to the bulk of the game which is spent managing the traffic of resources throughout various planets and outposts.

==Premise==

In the future, new resources have been discovered which will greatly increase the productivity and quality of life for people. These resources however, are scattered throughout the galaxy. You have been given the responsibility of managing the flow of these resources.

==Objective==

The player's objective is to build the most efficient path between areas of resource production and consumption. Further complicating this will be obstacles that the player will have to navigate around, thus sometimes the best path will not always be the clearest.

==Gameplay==

The player is first presented with a grid where resources, planets, and space outposts have been randomly placed. The size of this grid will vary based on difficulty and customization settings that the player is able to choose before hand.

Each planet and outpost will have a need for a specific amount of a resource. In order to get this resource to the outpost or planet, the player must set up a gathering facility on a tile which contains the desired resource. For example, if a planet requires ore, the player must set up a mining facility on a tile which contains an asteroid. Then this ore can be moved from the mining facility to the planet by setting up a shipping pathway between them.

Furthermore, pathway "Hubs" can be set up to help direct the flow of resources. When two or more pathways are connected to the Hub, the player will be able to manually set the amount of resources that are sent in each direction. For example, if there 4 tubes connected to a Hub, one going in each direction (up, down, left and right), and the resources are coming from the up direction, the player can have 20% go left, 20% go right, and 60% go down. This will allow the player to maximize the efficiency of their resource pathways by keeping unneeded, and thus, wasted resources, from going to outpost and planets.

When the resources arrive at a planet or outpost, the player will be paid in credits based on the amount of tiles that the resources had to travel to reach it's destination. The farther the resources had to travel, the less the player will receive from the delivery of them.

The game will run in a semi-turn based fashion, where the speed of resources are measured in tiles per tick. One tick will last several seconds, making the movement very slow. From the user's perspective, the movement will look continuous, since the resources will move at the appropriate rate.

==User Interface==

The screen is divided into two major sections. The main area displays the map (with approximately 20x20 tiles visible). A menu bar sits on the right of the screen, approximately 2 inches wide. The menu bar contains buttons that are labeled graphically. When the user hovers over them, the name will appear over the cursor. The buttons are as follows: Build Structure, Build Line, Build Path, Place Reward, Budget, Sell, and Options. If a button is clicked, then a submenu pops out to the left of the main menu bar. This submenu contains a scrollable list of all placeable buildings within the selected category. Clicking on one of these brings up the building information in the bottom area of the main menu. With a specific building selected, the cursor is replaced by a transparent image of the building if the user mouses over the main city area. Clicking on a suitable location places that building in the colony.

When no building is selected in the submenu, the user can click on any placed structure to display its information in the bottom of the main menu. This information contains a picture of the building, and displays (with words and symbols) the build costs, operational costs, output, and units.

==Scoring==

Since there is no explicit victory, a player's score is essentially the happiness of the planets and outposts along with the amount of money they are generating each turn.

==Under the Bonnet==

This section outlines the algorithms/systems used in the colony mode. Part of the fun of this game is learning the interactions between all the game's systems and figuring out how to use them to get the kind of colony the user desires.

===Time===

The time is measured in ticks. During each tick, each resource will move one tile through the pathways and then all buildings will be updated. The player will also be able to pause the game at any time. Once the game is paused, the player can make changes and this changes will be reflected when the game resumes.

====Paths====

Resources simply move based on the paths placed by the user and split up and directed appropriately when the they reach Hubs.

====Hubs====

Hubs are intersections between pathways where the user is able to manually set the break up and flow of the resources. At a hub, the player can choose the percentage of resources that will be sent in each direction, thus enabling them to maximize the efficiency of each pathway and keep unneeded resource from going to buildings.

====Development Controls====

Note: These Controls are strictly for testing and debugging and are no reflection of what the controls will be in the final game.

C Key: Switch Between CONSTRUCT and SELECT mode

Numpad 0: Select Outpost to be built (must be in CONSTRUCT mode to place)

Numpad 1: Select Planet to be built (must be in CONSTRUCT mode to place)

Numpad 2: Select Pathway to be built (must be in CONSTRUCT mode to place)
Note: Each pathway piece currently only flows in one direction, thus resources will only be seen moving if it is placed facing
the appropriate way.

Numpad 3: Select Hub to be built (must be in CONSTRUCT mode to place)

Right Click: Rotate the currently selected structure.

+ and - (non-numpad): zoom the camera in and out

[ and ] : rotate the camera

<nowiki>; and ' : tilt the camera</nowiki>

The camera will scroll when the mouse cursor is moved to the edges of the screen.

Spacebar: Recenter camera on build area

==Development==

[[Colony Sim Milestones]]

Art Assets and Tracking

2008-08-05T17:22:54Z

Brb6127:

Art Assets and Tracking

2008-08-05T17:21:21Z

Brb6127:

System Specifications and Testing

2008-08-04T21:27:21Z

Brb6127:

== System Requirements ==
=== Windows XP or Vista ===

Hardware:
o A graphics card that supports DirectX 9.0c and Shader Model 1.1 or newer.

Software:
o DirectX End-User Runtime or newer.
o Microsoft .NET Framework Version 2.0 or newer.
o Microsoft XNA Framework Redistributable 2.0

=== Development ===

Software:
o Microsoft XNA Game Studio 2.0
o Tortoise SVN or other Subversion Client

== Tested Hardware ==

The game has been tested on the following systems without error, slowdown, and/or artifacts:

Development System, Dell Inspiron 1720
o Operating System: Windows XP SP2
o Processor: Intel Core 2 Duo @ 2.00GHz, 2.00GHz
o Graphics Card: NVIDIA GeForce 8600M GT
o RAM: 2.00 GB

Development System, Dell Inspiron 1720
o Operating System: Windows Vista Ultimate
o Processor: Intel Core 2 Duo @ 2.00GHz, 2.00GHz
o Graphics Card: NVIDIA GeForce 8600M GT
o RAM: 2.00 GB

The game has been tested on the following systems with error, slowdown, and/or artifacts:

Development System, Dell Inspiron e1505
o Operating System: Windows XP SP2
o Processor: Intel Core 2 Duo @ 1.83GHz, 1.83GHz
o Graphics Card: ATI Mobility Radeon X1400
o RAM: 2.00 GB

MacBook Air 1,1
o Operating System: Windows XP SP2
o Processor: Intel Core 2 Duo @ 1.6 GHz, 1.6GHz
o Graphics Card: Intel GMA X3100, Integrated Graphics
o RAM: 2.00 GB

Art Assets and Tracking

2008-08-04T21:01:04Z

Brb6127:

== Look and Feel ==
For the game, the look and feel is best described as "TODO".

== Colony Simulation ==

=== Models ===

<table cellpadding="6" cellspacing="6">
<tr>
<th>Asset Name</th>
<th>Description</th>
<th>Artist Assigned</th>
<th>Status</th>
</tr>
<tr>
<td>Asset 1</td>
<td>This is a demo asset, just used to show that the table can be made this way. I can technically type as much text in here as I want and the browser should hopefully resize this. I guess we'll see :P</td>
<td>John Doe</td>
<td>Assigned</td>
</tr>
</table>

=== Textures ===

=== Sounds ===

== Meteor Madness ==

=== Models ===

=== Textures ===

=== Sounds ===

== Hacker Havoc ==

=== Models ===

=== Textures ===

=== Sounds ===

== Stellar Prospector ==

=== Models ===

=== Textures ===

=== Sounds ===

Functional specifications

2008-08-04T19:55:40Z

Brb6127:

Welcome to this game's functional spec table of contents. There are two major parts: the colony simulator and the minigames.

[[Important Neuroscientific Considerations in Game Design for Autism]]

'''Colony Simulator'''

[[Colony Mode]]

[[Factions]]

[[Structures]]

[[Consumables]]

[[Tasks]]

'''Minigames'''

[[Meteor Madness]]

[[Factory Frenzy]]

[[Hacker Havoc]]

[[Spaceship Shenanigans]]

[[Mini Game Rewards]]

[[Mini Game Scenarios]]

Main Page

2008-08-04T19:55:08Z

Brb6127:

<big>'''Welcome to the Autism Game wiki'''</big>

This page is used by the developers working on Astropolis, a video game that collects scientific research. Here at the Autism Collaborative, we want to share both our findings and our processes with the public because we believe that is the most beneficial for everyone. As such, this wiki is a tool used by the Astropolis developers, but we encourage anyone interested in the project to explore and gain insight into our process for making the game.

==The Motivation==
'''Integrative studies of perception, attention, and social cognition in autism'''

Although much progress has been made identifying structural and functional profiles in autism, this work has resulted in a multiplicity of hypotheses targeted at particular brain or cognitive subsystems or levels of analysis; our most vexing problem often is not identifying the observational details, but assembling these details into a coherent theory. The division between social and non-social studies of autism is a case in point. Competing theories have construed autism variously as an exclusively social deficit in "theory of mind," an abnormality of attention and executive function with social and non-social consequences, an atypical weakness in "central coherence," or an enhancement of perceptual function. Although each of these views seems to capture a piece of the truth, a synthesis of all of them will not be possible as long as they continue to be approached as competing rather than synergistic views, as long as their psychological descriptions remain incompletely connected to neurobiological explanations and to clinical impairments, and as long as individual experiments continue to collect data germane to only one theory in isolation.

==The Strategy==
'''Embed a suite of psychological experiments within a video game that's fun to play'''

Perhaps the single most important obstacle to integrative studies of autism is the practical limit on the amount of time that a single experimental subject can reasonably be expected to perform before becoming fatigued. Unfortunately, often the more controlled a stimulus is from the scientist's point of view, the more repetitive and tedious the experiment can seem from the subject's point of view. Behavioural research on autism in recent years has highlighted the importance of motivation, behavioural set, and task instruction in establishing cognitive strategy and determining performance (e.g. Plaisted et al. 1999; Dalton et al. 2005). In light of these considerations, we propose to embed experimental stimuli in the context of a video game that captures and maintains subjects' interest, transparently collecting behavioural data and synchronising with physiological recording as the subject plays the game. The practical advantages of such an engaging and ecologically valid format over the usual repetitive blocks of trials are legion. Indeed, varying levels and demands of attentional shifting and multimodal integration are natural in the context of video game play, and psychophysical measures such as dot motion coherence and embedded figures are easily implemented as, for example, the movement of a star field on a view screen and the detection of an adversary in a cluttered environment. In addition, the strategic and adversarial nature of a video game carries natural opportunities to explore higher-level cognitive measures such as comprehension of game-related narratives and social attribution to a computer-generated adversary. The video game format is increasingly being used to acquire simultaneous behavioural and EEG observations in ecologically valid contexts, for example in visuomotor tracking (Smith et al. 1999), air traffic control (Brookings et al. 1996), and military command and control simulations (St John et al. 2002, 2004; Berka et al. 2004). Recent results in human-computer interaction (von Ahn 2006) also point to the power of the game context to establish and to maintain motivation in tasks that otherwise might not seem engaging, and to teach persons with developmental disorders (Golan & Baron-Cohen 2006). Also along these lines, the video game format affords subjects more of a chance to become comfortable with the task before entering the laboratory, minimising the potential confound of state anxiety associated with performance of an unfamiliar task in a testing situation.

==Major Sections==

[[Plot]]

[[Functional specifications]]

[[Meetings]]

[[Dev Setup]]

[[Code How To's]]

[[TODO List]]

[[Concept Art]]

[[Art Assets and Tracking]]

[[System Specifications and Testing]]

Main Page

2008-08-04T19:54:49Z

Brb6127:

<big>'''Welcome to the Autism Game wiki'''</big>

This page is used by the developers working on Astropolis, a video game that collects scientific research. Here at the Autism Collaborative, we want to share both our findings and our processes with the public because we believe that is the most beneficial for everyone. As such, this wiki is a tool used by the Astropolis developers, but we encourage anyone interested in the project to explore and gain insight into our process for making the game.

==The Motivation==
'''Integrative studies of perception, attention, and social cognition in autism'''

Although much progress has been made identifying structural and functional profiles in autism, this work has resulted in a multiplicity of hypotheses targeted at particular brain or cognitive subsystems or levels of analysis; our most vexing problem often is not identifying the observational details, but assembling these details into a coherent theory. The division between social and non-social studies of autism is a case in point. Competing theories have construed autism variously as an exclusively social deficit in "theory of mind," an abnormality of attention and executive function with social and non-social consequences, an atypical weakness in "central coherence," or an enhancement of perceptual function. Although each of these views seems to capture a piece of the truth, a synthesis of all of them will not be possible as long as they continue to be approached as competing rather than synergistic views, as long as their psychological descriptions remain incompletely connected to neurobiological explanations and to clinical impairments, and as long as individual experiments continue to collect data germane to only one theory in isolation.

==The Strategy==
'''Embed a suite of psychological experiments within a video game that's fun to play'''

Perhaps the single most important obstacle to integrative studies of autism is the practical limit on the amount of time that a single experimental subject can reasonably be expected to perform before becoming fatigued. Unfortunately, often the more controlled a stimulus is from the scientist's point of view, the more repetitive and tedious the experiment can seem from the subject's point of view. Behavioural research on autism in recent years has highlighted the importance of motivation, behavioural set, and task instruction in establishing cognitive strategy and determining performance (e.g. Plaisted et al. 1999; Dalton et al. 2005). In light of these considerations, we propose to embed experimental stimuli in the context of a video game that captures and maintains subjects' interest, transparently collecting behavioural data and synchronising with physiological recording as the subject plays the game. The practical advantages of such an engaging and ecologically valid format over the usual repetitive blocks of trials are legion. Indeed, varying levels and demands of attentional shifting and multimodal integration are natural in the context of video game play, and psychophysical measures such as dot motion coherence and embedded figures are easily implemented as, for example, the movement of a star field on a view screen and the detection of an adversary in a cluttered environment. In addition, the strategic and adversarial nature of a video game carries natural opportunities to explore higher-level cognitive measures such as comprehension of game-related narratives and social attribution to a computer-generated adversary. The video game format is increasingly being used to acquire simultaneous behavioural and EEG observations in ecologically valid contexts, for example in visuomotor tracking (Smith et al. 1999), air traffic control (Brookings et al. 1996), and military command and control simulations (St John et al. 2002, 2004; Berka et al. 2004). Recent results in human-computer interaction (von Ahn 2006) also point to the power of the game context to establish and to maintain motivation in tasks that otherwise might not seem engaging, and to teach persons with developmental disorders (Golan & Baron-Cohen 2006). Also along these lines, the video game format affords subjects more of a chance to become comfortable with the task before entering the laboratory, minimising the potential confound of state anxiety associated with performance of an unfamiliar task in a testing situation.

==Major Sections==

[[Plot]]

[[Functional specifications]]

[[Meetings]]

[[Dev Setup]]

[[Code How To's]]

[[TODO List]]

[[Concept Art]]

[[Arts Assets and Tracking]]

[[System Specifications and Testing]]

Art Assets and Tracking

2008-08-04T19:48:06Z

Brb6127: New page: == Look and Feel == For the game, the look and feel is best described as "TODO". == Colony Simulation == === Models === === Textures === === Sounds === == Meteor Madness == === Model...

== Look and Feel ==
For the game, the look and feel is best described as "TODO".

== Colony Simulation ==

=== Models ===

=== Textures ===

=== Sounds ===

== Meteor Madness ==

=== Models ===

=== Textures ===

=== Sounds ===

== Hacker Havoc ==

=== Models ===

=== Textures ===

=== Sounds ===

== Stellar Prospector ==

=== Models ===

=== Textures ===

=== Sounds ===

Functional specifications

2008-08-04T19:34:04Z

Brb6127:

Welcome to this game's functional spec table of contents. There are two major parts: the colony simulator and the minigames.

[[Important Neuroscientific Considerations in Game Design for Autism]]

'''Colony Simulator'''

[[Colony Mode]]

[[Factions]]

[[Structures]]

[[Consumables]]

[[Tasks]]

[[Art Assets and Tracking]]

'''Minigames'''

[[Meteor Madness]]

[[Factory Frenzy]]

[[Hacker Havoc]]

[[Spaceship Shenanigans]]

[[Mini Game Rewards]]

[[Mini Game Scenarios]]

Structures

2008-08-04T19:22:23Z

Brb6127:

Below is the list of features that have been currently decided on for the Colony Simulation.
== Building Types ==
The Colony Simulation will use a set of Building types for which the different Buildings that can be built in game can be categorized. Each of the Building types has special attributes which make them unique. Aside, each Building will also have a unique look and feel, allowing for aesthetically pleasing choices for the user.
The basic Building attributes which all Buildings share are the following:

• Name – A unique name for each building

• Model / Texture Names– Names for the 3D graphics and textures which will be associated.

• Required Workers – The workers required for the Building to run properly. These workers are classes as Unskilled Workers, Skilled Workers, and Scientists.

• Costs – The cost in Resources to build the Building.

• Upkeep – The amount of Resources the Building consumes per turn.

• Passive Storage – A storage that all Buildings possess for shuffling resources between other Buildings, using the Tube system.

• Upgrade Info – The information about the costs to Upgrade the Building to the next tier or level

All upgrades to Buildings should be such that they increased the extra attributes each possesses, increasing their efficiency and potential, as well as making them more aesthetically pleasing or flamboyant, matching the nature of the Building.

'''''Note About the Building Look: The Buildings as we are calling them should look like pods of some sort. The Colony is a collections of pods that are connected by tubes, floating around in space. Hence, each Building, based on their own aesthetic specifications, should look pod like.'''''
=== Entertainment Building Type ===
The Entertainment Building Type offers Buildings which are specialized in raising the Happiness of the Colony’s population. These buildings are meant to look aesthetically pleasing and fun, like futuristic arcades, parks, and the like. These should look flashy or very distinguished, looking like futuristic Las Vegas styles buildings for digital entertainment or well preserved, restful, and contained natural wonders for more natural entertainment.
The extra attributes of this type are:

• Happiness Modifier – This is a numeric modifier which augments the Happiness of the Colony based on a certain amount.
=== Gatherer Building Type ===
The Gatherer Building Type offers Buildings which are specialized in gathering specific Resources, allowing the player to build more Buildings, fulfill upkeep requirements, and enhance their Colony. These Buildings take advantage of robot mining units which affect the speed and amount that can be gathered at any given time, at any given Gatherer. In order to gather, the Building must first be attached to an Asteroid. These Buildings should look very constrained, very mechanical like, as they are used to drill into Asteroids for raw Resources.
The extra attributes of this type are:

• List of Gatherable Resources – This is the list of resources that the Gatherer can gather at any given time.

• Number of Units and Tools – This is the list of mining units and tools that the Gatherer has. Each Gatherer will have a maximum number of them and will start with a minimum number.
=== Industrial Building Type ===
The Industrial Building Type offers Buildings which are specialized in developing new units or tools for many of the other Buildings in the Colony. These Buildings are meant to look very mechanical as well, looking more towards the assembly and production end of the spectrum for aesthetic qualities.
The extra attributes of this type are:

• List of Artifacts – This is a list of Artifacts that the Building can create. These can be either units or tools that are used by other Buildings within the Colony.
=== Refiner Building Type ===
The Refiner Building Type offers Buildings which are specialized in taking the raw Resources from Gatherer Buildings and processing it, sending it along to Storage Building to be stored. These Buildings are futuristic foundries, emitting light and other attributes similar to foundries, but each being unique for the Resources it handles. At this time, it is being considered that these may also end up being coupled as the Storage Buildings as well.
Extra attributes of this type are:

• List of Refinable Resources – A list of resources that this Building can refine.

• Storage – If this Building is made the Storage Building as well, then it will have the list of Resources it can store and the maximum amount that can be stored. This may be coupled with Refinable Resources then.

• Number of Units and Tools – The Number of Units and Tools available to the Refiner, which affect the speed and amount of Resources that can be refined.
=== Residential Building Type ===
The Residential Building Type offers Buildings which are specialized as housing for the inhabitants of the Colony. These Buildings offer various qualities of housing and different amounts of housing for the population. These Buildings should look like self contained pods which have various windows and residential qualities, similar to futuristic houses and apartment Buildings.
Extra attributes of this type are:

• Recommended / Maximum Populations – A number of the recommended population and maximum population a Building can hold. If the number of the of residents increases passed the recommended number, the Happiness of the residents will decrease.

• Quality of Housing – This is an overall quality of housing attribute, which affects the Happiness of the residents. The higher the number, the happier the residents will be.
=== Science Building Type ===
The Science Building Type offers Buildings which are specialized in research Technologies for the Colony. These Technologies globally affect the Buildings and population of the Colony, modifying various attributes of various Buildings, increasing the prosperity of the Colony. These Buildings should look like futuristic universities or research facilities. Examples could include Research Domes, Research Satellites, etc.
Extra attributes of this type are:

• List of Research Technologies – This is a list of all the Technologies that this Building can be used to research. More technologies can become available to research as new Technologies are learned.
=== Storage Building Type ===
The Storage Building Type offers Buildings which are specialized to store the Resources of the Colony. These Building should look very functional, looking like pods, spheres, or boxes which are very self contained, as they are meant to store resources. Currently, the function these Buildings provide may end up being shifted to the Refiner Building.
Extra attributes of this type are:

• List of Storable Resources – This is a list of the resources and the maximum value that can be stored for each of them.

System Specifications and Testing

2008-08-04T16:14:52Z

Brb6127:

== System Requirements ==
=== Windows XP or Vista ===

Hardware:
o A graphics card that supports DirectX 9.0c and Shader Model 1.1 or newer.

Software:
o DirectX End-User Runtime or newer.
o Microsoft .NET Framework Version 2.0 or newer.
o Microsoft XNA Framework Redistributable 2.0

=== Development ===

Software:
o Microsoft XNA Game Studio 2.0
o Tortoise SVN or other Subversion Client

== Tested Hardware ==

The game has been tested on the following systems without error, slowdown, and/or artifacts:

Development System, Dell Inspiron 1720
o Operating System: Windows XP
o Processor: Intel Core 2 Duo @ 2.00GHz, 2.00GHz
o Graphics Card: NVIDIA GeForce 8600M GT
o RAM: 2.00 GB

Development System, Dell Inspiron 1720
o Operating System: Windows Vista
o Processor: Intel Core 2 Duo @ 2.00GHz, 2.00GHz
o Graphics Card: NVIDIA GeForce 8600M GT
o RAM: 2.00 GB

The game has been tested on the following systems with error, slowdown, and/or artifacts:

Development System, Dell Inspiron e1505
o Operating System: Windows XP
o Processor: Intel Core 2 Duo @ 1.83GHz, 1.83GHz
o Graphics Card: ATI Mobility Radeon X1400
o RAM: 2.00 GB

System Specifications and Testing

2008-08-04T16:07:29Z

Brb6127:

== System Requirements ==
=== Windows XP or Vista ===

Hardware:
o A graphics card that supports DirectX 9.0c and Shader Model 1.1 or newer.

Software:
o DirectX End-User Runtime or newer.
o Microsoft .NET Framework Version 2.0 or newer.
o Microsoft XNA Framework Redistributable 2.0

=== Development ===

Software:
o Microsoft XNA Game Studio 2.0
o Tortoise SVN or other Subversion Client

=== Tested Hardware ===

The game has been tested on the following systems without error, slowdown, and/or artifacts:

Development System, Dell Inspiron 1720
o Operating System: Windows XP
o Processor: Intel Core 2 Duo @ 2.00GHz, 2.00GHz
o Graphics Card: NVIDIA GeForce 8600M GT
o RAM: 2.00 GB

Development System, Dell Inspiron 1720
o Operating System: Windows Vista
o Processor: Intel Core 2 Duo @ 2.00GHz, 2.00GHz
o Graphics Card: NVIDIA GeForce 8600M GT
o RAM: 2.00 GB

The game has been tested on the following systems with error, slowdown, and/or artifacts:

Development System, Dell Inspiron e1505
o Operating System: Windows XP
o Processor: Intel Core 2 Duo @ 1.83GHz, 1.83GHz
o Graphics Card: ATI Mobility Radeon X1400
o RAM: 2.00 GB

System Specifications and Testing

2008-08-04T15:58:12Z

Brb6127: New page: == System Requirements == === Windows XP or Vista === * Hardware: o A graphics card that supports DirectX 9.0c and Shader Model 1.1 or newer. * Software: o D...

== System Requirements ==
=== Windows XP or Vista ===

* Hardware:
o A graphics card that supports DirectX 9.0c and Shader Model 1.1 or newer.

* Software:
o DirectX End-User Runtime or newer.
o Microsoft .NET Framework Version 2.0 or newer.
o Microsoft XNA Framework Redistributable 2.0

=== Development ===

* Software:
o Microsoft XNA Game Studio 2.0
o Tortoise SVN or other Subversion Client

Main Page

2008-08-04T15:55:59Z

Brb6127:

Event Codes

2008-07-08T16:30:27Z

Brb6127:

Event codes are used by the game to identify events specific to certain criterion for actions the player performs in game. These criterion include information for many of the scientific experiments handled in game, as well as basic event identification for input handling.

The Event codes are grouped into two distinct groups. The first group identifies codes which are universal throughout the game. The second group is defined on a game by game basis, meaning that each internal mini game or the main game itself identify what these codes mean. The universal codes cannot be changed.

Due to the limitations of the parallel port that is used to print out this data in a lab setting, the codes can only range from 0-255, taking up only an 8 bit space.

== Universal Codes ==

'''-2''' - Debugging Test Code. Negative codes are assumed by the logger to be debug information only. This can be toggled within the logger whether these are recorded or not.

'''-1''' - Debugging Enabled. This code signifies that debugging is enabled to the logger.

'''0''' - The clear code. This is used by the parallel port to sense the data correctly, by monitoring high-to-low and low-to-high measurements. This cannot be changed.

'''254''' - The start game code for Metoer Madness.

'''255''' - End Current Game.

'''256''' - ERROR.

== Game Specific Codes ==
Game specific codes can be in the range from 1 to the last given start game code. This allows for having the largest number of codes per game as well as optimizing the code specification, as the codes are specified from the beginning of the enum to whatever the last valid enumeration is.

File:Current Project Tasks.png

2008-06-24T23:52:06Z

Brb6127:

File:Current Project Tasks.PNG

2008-06-24T23:51:26Z

Brb6127:

Code Overview

2008-06-18T19:05:27Z

Brb6127:

This page contains a high-level overview of the code for the Autism Game.

==XNA==

This game is built on XNA, which is suite of classes written by Microsoft. It provides methods for importing and playing content, a basic program flow (detailed below), portability, and has a good online community of home brew game developers and hobbyists.

==Layout==

The code is divided into three categories: the engine code, utility code, and the game code.

The engine code is contained in a self contained XNA project, AC_GraphicsEngine. This code encompasses all of the basic engine fundamentals. It includes lighting support, sprite and model entity support, sound management, game management, and game screens for use with basic applications. For more information, please see the [[tAC_Engine]] page.

The utility code is contained in another self contained XNA project called Util. This project defines input handlers, a logger for logging events for experimental data, and event related information. For more information, please see the [[Util]] page.

The game code is stored in individual game projects. These individual game projects each represent either the main game (the Colony Simulator) or one of the various mini games. The Content folders of each of these contain any and all content used by the games, respectively. These are usually divided further into different sets: Fonts, Textures, Models, Shaders, and Audio. A sample breakdown of a game project and its related hierarchy can be seen on the [[Sample Game]] page.

==Program Flow==

An XNA game has 2 main cycles, Draw and Update. Both are called up to 60 times per second (usually). If the CPU load is high, XNA will automatically skip Draw cycles in an attempt to keep up with the Update cycles. This game has special requirements, so the Update cycle is actually called every ms and a new "Logic Update" cycle is called if 16.7 ms have passed since the last cycle. This is transparent to the minigames, so they can call Update and Draw as if they were part of a standard XNA game.

Below is the intended program flow for the game. As of this writing (Oct 2007), some steps have yet to be implemented.

* The entry point for the game is Program.Main() (located in ColonySimulator\Program.cs)
** Main instantiates all the major components used in this game and assigns them to the ColonyBaseApplication
** The game mode is set to the startup sequence
* mainGame.Run() is called
** This calls several initialization functions (Engine\GenericGameManager.cs)
** The Update and Draw cycles start (GenericGameManager.Update()/.Draw())
* GenericGameManager.Update() calls the appropriate main game or minigame's update based on the current mode (initially the startup sequence)
* GenericGameManager.Draw() works the same way
* There is a persistent game (the colony simulator) and also a "current" game
** When the game mode is set to a minigame, the current game is that minigame
** When the game mode is set to the colony simulator, the current game is the colony simulator
** The startup sequence mode and main menu mode are candidates for the current game
** The colony simulator always exists
*** This allows minigames to interact with the simulator mode
*** Colony Simulator's Update and Draw cycles are only called while it is the current game
* When a game is finished, it must set the appropriate mode by calling ColonyBaseApplication.switchMode(...)
* The game is ended by setting the mode to the shutdown sequence
** Only the main menu or the pause menu should do this
** This gives the user a last chance to save
** Sends experimental data to the server or archives it if the server cannot be reached

==Object Interactions==

* Each game is responsible for running and drawing itself (that is, a game must implement Update() and Draw())
** This responsibility can be delegated to helper classes
* Games should be independent
** The main game (the colony simulator) should only switch to the "mode selector" mode, not a minigame directly
** Minigames can give the main game resources, but should only indirectly through the ScoreCard classes
** With the exception of resources, any one game should not have any impact on any other game
* Every game object should derive from Entity
* Except for extremely specific circumstances, ALL objects or classes used in a game should derive from some class in the tAC_Engine namespace
** If there is no suitable generic class, it may be necessary to create one and add it to the engine code
* Use ColonyBaseApplication to communicate with windows forms and exchange global data
** See [[Code How To's]] for several examples of this, including checking time, screen dimensions, and setting game parameters

Event Codes

2008-06-18T18:47:34Z

Brb6127:

Event codes are used by the game to identify events specific to certain criterion for actions the player performs in game. These criterion include information for many of the scientific experiments handled in game, as well as basic event identification for input handling.

The Event codes are grouped into two distinct groups. The first group identifies codes which are universal throughout the game. The second group is defined on a game by game basis, meaning that each internal mini game or the main game itself identify what these codes mean. The universal codes cannot be changed.

Due to the limitations of the parallel port that is used to print out this data in a lab setting, the codes can only range from 0-255, taking up only an 8 bit space.

== Universal Codes ==

'''0''' - The clear code. This is used by the parallel port to sense the data correctly, by monitoring high-to-low and low-to-high measurements. This cannot be changed.

'''1''' - The switch code. This code is used to signify a change of state in the application, from one game to another. The related event must have information pertaining to the new state of the application (aka, what game are we entering). As such, following event codes will correspond to that new state until 1 is called again.

== Game Specific Codes ==

Starting from 2-255, all codes and related events are determined and specified by the current game which is running. This allows for the largest number of events and codes for each game possible.

Event Codes

2008-06-18T18:46:07Z

Brb6127: New page: Event codes are used by the game to identify events specific to certain criterion for actions the player performs in game. These criterion include information for many of the scientific ex...

Event codes are used by the game to identify events specific to certain criterion for actions the player performs in game. These criterion include information for many of the scientific experiments handled in game, as well as basic event identification for input handling.

The Event codes are grouped into two distinct groups. The first group identifies codes which are universal throughout the game. The second group is defined on a game by game basis, meaning that each internal mini game or the main game itself identify what these codes mean. The universal codes cannot be changed.

Due to the limitations of the parallel port that is used to print out this data in a lab setting, the codes can only range from 0-255, taking up only an 8 bit space.

== Universal Codes ==

'''0''' - The clear code. This is used by the parallel port to sense the data correctly, by monitoring high-to-low and low-to-high measurements. This cannot be changed.

'''1''' - The start code. This code is used to signify a change of state in the application, from one game to another. The related event must have information pertaining to the new state of the application (aka, what game are we entering). As such, following event codes will correspond to that new state until 1 is called again.

== Game Specific Codes ==

Starting from 2-255, all codes and related events are determined and specified by the current game which is running. This allows for the largest number of events and codes for each game possible.