TACWiki - New pages [en]

Data analysis - auditory stimuli

2011-06-13T17:35:21Z

Belmonte: New page: '''Auditory Stimuli''' This is not a game, but rather a passive stimulation paradigm comprising a 50 ms tone (consisting of several frequency components) played at various dB SPL intensit...

'''Auditory Stimuli'''

This is not a game, but rather a passive stimulation paradigm comprising a 50 ms tone (consisting of several frequency components) played at various dB SPL intensities, at intervals of 1000 ms plus a random jitter uniformly distributed over [0, 500 ms]. The paradigm begins with AS_Start (1). A tone is signalled by AS_TONE_PLAYED Volume=n. The paradigm ends with AS_END.

Postprocessing is straightforward and no event code translation is needed, other than the usual removal of events numbered 255 or greater, and renumbering of events into a unqique range specific to this paradigm.

ERPs and ERSPs to each intensity can be computed, and component amplitudes (both in sensor space and in ICA source space) can be used to construct a response curve of ERP component amplitude as a function of stimulus amplitude that classifies each subject as an augmenter, a reducer, or a flat responder.

Data analysis - Stellar Prospector

2011-06-13T17:33:59Z

Belmonte: New page: '''Stellar Prospector''' The game begins with SP_Phase1Begin (9) and comprises three phases, in this order: Phase 1: Visual cue-change signal. Targets only, no distractors. Phase...

'''Stellar Prospector'''

The game begins with SP_Phase1Begin (9) and comprises three phases, in this order: 
Phase 1: Visual cue-change signal. Targets only, no distractors. 
Phase 2: Visual cue-change signal. Targets and distractors. 
Phase 3: Auditory-visual cue-change signal. Targets and distractors.

The task is to respond with a down-arrow key-press to high-value targets at fixation, whilst simultaneously monitoring for lower-value targets in the four sectors surrounding fixation in the upper visual hemifield, and responding with an up-arrow key-press to these. At any given time, exactly one of the four sectors is the cued sector, in which 80% of targets will appear.

Depending on the numbers of trials available, data can be pooled across Phases 2 and 3, or even across all three phases. (However, this matter of data pooling is for the experimenters to decide; the processing software should keep the phase-marker events intact.) For translation of context-sensitive to context-free event codes:

<table BORDER="1">
<tr><th> Original Event </th><th> following event </th><th> classification </th></tr>
<tr><td ROWSPAN="3"> SP_CentralStimulusSpawn </td><td> SP_CentralStimulusResponsePressed CentralStimulus=active </td><td> hit </td></tr>
<tr> <td> SP_PeripheralStimulusResponsePressed CentralStimulus=active</td><td> response error </td></tr>
<tr> <td> SP_MissedCentralStimulus </td><td> miss </td></tr>
<tr><td ROWSPAN="3"> SP_PeripheralStimulusSpawn</td><td> SP_CentralStimulusResponsePressed CentralStimulus=inactive</td><td> response error </td></tr>
<tr> <td> SP_PeripheralStimulusResponsePressed PeripheralStimulus=active</td><td> hit </td></tr>
<tr> <td> SP_MissedPeripheralStimulus </td><td> miss </td></tr>
<tr><td ROWSPAN="2"> SP_DistractorSpawn </td><td> SP_PeripheralStimulusResponsePressed PeripheralStimulus=inactive</td><td>false alarm </td></tr>
<tr> <td> SP_DistractorDisappear </td><td> correct rejection</td></tr>
</table>

Also re-code the associated response into a hit, a response error, or a miss based on the re-coding of the stimulus. Response events that are not associated with any stimulus by the above rules and occur with PeripheralStimulus=inactive should be re-coded as false alarms. (These will be quite rare in Phase 1, but more common in Phases 2 and 3 which involve distractors.)

For each of the three phases separately, and also for phases 2 and 3 pooled without phase 1, compute the following: 
Trial-by-trial values, mean, and standard deviation of: 
Reaction times to central stimuli 
Reaction times to validly cued peripheral stimuli (where the value of the Sector parameter for the SP_PeripheralStimulusSpawn event is the same as the value of the Sector parameter for the most recent SP_CueChange) 
Reaction times to all invalidly cued peripheral stimuli

When listing out the trial-by-trial values for the peripheral stimuli, also list the stimulus's polar coordinates (r, θ), the number of the sector in which the stimulus appeared, and the number of the currently cued sector (from the most recent SP_CueChange). Use this information to compute multiple regression coefficients of reaction time against the stimulus's r (its distance from fixation) and against the absolute value of the difference between the stimulus's θ and the θ that runs along the centre of the cued sector (-3π/8, -π/8, pi;/8, 3pi;/8; in general the formula is Sector×π/4 - 3π/8). Also compute statistical significances for these regression coefficients.

For the peripheral stimluli only (not the central stimuli), in Phases 2 and 3 only (exlcuding Phase 1), in two separate computations one for the currently cued sector and the other for the currently uncued sectors, complute d' ("d prime") using the tallies of hits, correct rejections, false alarms and misses. (If any of these tallies is zero, estimate d' by increasing it to 1.)

<table BORDER="1">
<tr><td> 1
</td><td> SP_PeripheralStimulusResponsePressed     PeripheralStimulus={inactive, active}     CentralStimulus={inactive, active}     Gather={inactive, active}
</td><td> The up-arrow key has been pressed, indicating a response to a peripheral stimulus (as this response might be a false alarm, a peripheral stimulus may or may not actually have been active); the parameters indicate the current activity of the central and any peripheral stimuli, and whether the game will be responsive to this key press or whether it's temporarily inactive as a penalty for a previous, incorrect key press.
</td></tr>

<tr><td> 2
</td><td> SP_CentralStimulusResponsePressed     PeripheralStimulus={inactive, active}     CentralStimulus={inactive, active}     Gather={inactive, active}
</td><td> The down-arrow key has been pressed, indicating a response to the central (fixation) stimulus (as this response might be a false alarm, the central stimulus may or may not actually have been active); the parameters indicate the current activity of the central and any peripheral stimuli, and whether the game will be responsive to this key press or whether it's temporarily inactive as a penalty for a previous, incorrect key press.
</td></tr>

<tr><td> 5, 6
</td><td> SP_Start_Menu_Action
</td><td> At the beginning of the game, a selection has been made from the menu. (These codes should not be being transcribed onto the parallel port and thus should not be appearing in the EEG log.)
</td></tr>

<tr><td> 7
</td><td> SP_MenuSelectButtonPressed
</td><td> The player has pressed the space bar in response to an instruction prompt
</td></tr>

<tr><td> 9
</td><td> SP_Phase1Begin
</td><td> Phase 1 of the game has begun: visual cues only (no simultaneous auditory cue), targets only (no distractors)
</td></tr>

<tr><td> 10
</td><td> SP_Phase2Begin
</td><td> Phase 2 of the game has begun: visual cues only (no simultaneous auditory cue), 50% targets and 50% distractors
</td></tr>

<tr><td> 11
</td><td> SP_Phase3Begin
</td><td> Phase 3 of the game has begun: simultaneous visual and auditory cues, 50% targets and 50% distractors
</td></tr>

<tr><td> 12
</td><td> SP_End
</td><td> The game has ended; the player has collected enough peripheral stimuli (and ejected enough central stimuli) to fill the power bar
</td></tr>

<tr><td> 13
</td><td> SP_PeripheralStimulusSpawn Sector={0, 1, 2, 3}     {X, Y}=screen coordinates     ThetaRadians=angle from fixation in polar coordinates [—&pi/2;, &pi/2;]     RadialDistanceInPixels=display-coordinates distance from fixation     ScreenDistanceInCm=linear distance from fixation (cm)     RhoRadians=anglular distance from fixation (radians)     AzimuthPhiRadians=azimuth from fixation (radians)     ElevationLambdaRadians=elevation from fixation (radians)
</td><td> A lower-value stimulus in one of the four peripheral sectors, away from fixation, has appeared; the parameters give distance from the fixation point in several redundant coordinate systems
</td></tr>

<tr><td> 14
</td><td> SP_CentralStimulusSpawn
</td><td> The high-value stimulus at the fixation point has activated
</td></tr>

<tr><td> 15
</td><td> SP_DistractorSpawn     Sector={0, 1, 2, 3}     {X, Y}=screen coordinates     ThetaRadians=angle from fixation in polar coordinates [—&pi/2;, &pi/2;]     RadialDistanceInPixels=display-coordinates distance from fixation     ScreenDistanceInCm=linear distance from fixation (cm)     RhoRadians=anglular distance from fixation (radians)     AzimuthPhiRadians=azimuth from fixation (radians)     ElevationLambdaRadians=elevation from fixation (radians)
</td><td> A distractor in one of the four peripheral sectors, away from fixation, has appeared; the parameters give distance from the fixation point in several redundant coordinate systems
</td></tr>

<tr><td> 16
</td><td> SP_CueChange     Sector={0, 1, 2, 3}     Sound={true, false}
</td><td> The visual cue has changed to the designated sector; it is accompanied by an auditory cue iff Sound=true
</td></tr>

<tr><td> 17
</td><td> SP_MissedPeripheralStimulus
</td><td> The currently active peripheral (low-value) stimulus has timed out and disappeared without a response
</td></tr>

<tr><td> 18
</td><td> SP_MissedCentralStimulus
</td><td> The currently active central (high-value) stimulus has timed out and disappeared without a response
</td></tr>

<tr><td> 19
</td><td> SP_DistractorDisappear
</td><td> The currently active distractor has disappeared
</td></tr>
</table>

Data can be epoched by the stimulus events SP_CueChange, SP_CentralStimulusSpawn, SP_PeripheralStimulusSpawn, SP_DistractorSpawn. ICA can be run either separately on each of these classes of epochs, or on all pooled, or on grouped subsets (for example pooling SP_PeripheralStimulusSpawn with SP_DistractorSpawn). Epochs should be long enough to include the associated behavioural response events.

ERPs and ERSPs can be computed to each of these stimulus events. Difference waves between SP_PeripheralStimulusSpawn and SP_DistractorSpawn may also be of interest. In addition, response errors (see above for definitions) can be analysed for the error-related negativity.

(Originally the intent was to flicker the backgrounds in the four sectors at different fundamental frequencies, so that covert attention to a particular sector would be encoded in the EEG frequency spectrum via a slight increase in SSVEP amplitude at that fundamental frequency. However, many subjects found the flickering distracting, and in addition some autism-spectrum subjects found it painful. The flickering therefore was disabled for most subjects.)

Data analysis - StarJack

2011-06-07T10:57:00Z

Belmonte: Added a link to Brefczynski-Lewis et al. (2011) on ERP responses to others' blinks

The game begins with unparameterised SJ_START (1) and ends with SJ_END (19) followed by SJ_ENDSCREEN_CONTINUE (7). The game also is considered to have ended if the begin code for any other mini-game occurs. The game comprises multiple iterations of three phases: the maze task (which can be used as a measure of executive function), the Embedded Figures Test (where reaction times measure perceptual disembedding), and the "Sally-Anne" test of theory-of-mind.

Each level of the maze task begins with parameterised SJ_START (2) and ends with parameterised SJ_END (19). Each level of the maze task is interrupted by invocations of the Embedded Figures Test, and punctuated by an invocation of the Sally-Anne test. These latter two tests also can be invoked directly from the menu, without going through the maze test.

The Embedded Figures Test begins with SJ_EFT_START (49) and ends with SJ_EFT_END_FAIL (44) or SJ_EFT_END_SUCCESS (50).

The Sally-Anne test begins with SJ_SAT_START (52) and ends with SJ_SAT_END (53).

Following is a list of all the event codes, then a summary of the relevant behavioural and electrophysiological derived measures to extract:

<table BORDER="1">
<caption>Event codes (see <tt>autism_collaborative/Game/StarJack/EventCode.cs</tt>, <tt>autism_collaborative/Game/StarJack/Screen/SallyAnneScreen.cs</tt>), <tt>autism_collaborative/Game/StarJack/HackingPhase/HackingPhaseScreen.cs</tt>, <tt>autism_collaborative/Game/StarJack/Dungeon/DungeonScreen.cs</tt></caption>
<tr><td> 1
</td><td> SJ_START
</td><td> The game has begun.
</td></tr>

<tr><td> 2
</td><td> SJ_START     Level=Level_M|tutorialLevel Room=Room_N
</td><td> The player has entered a new maze level.
 Note that distinct numeric event codes (1 and 2) but one and the same string event descriptor (SJ_START) is used to denote the start of the game as a whole and to denote the start of an individual level of the maze within the game. The difference is the presence or absence of the parameters.
</td></tr>

<tr><td> 7
</td><td> SJ_MENU_INPUT_MouseClick
</td><td> The player has clicked the mouse to select a sub-portion of the game.
</td></tr>

<tr><td> 7
</td><td> SJ_ENDSCREEN_CONTINUE
</td><td> The player has clicked the mouse to continue past the game end screen, exiting the game.
 (Note same numeric code as SJ_MENU_INPUT_MouseClick above.)

</td></tr>

<tr><td COLSPAN="3">Maze Task Events</td></tr>

<tr><td> 9
</td><td> SJ_Cloak_Start
</td><td> In the maze, the player's avatar has activated the invisibility cloak.
</td></tr>

<tr><td> 10
</td><td> SJ_Cloak_End

</td><td> In the maze, the player's invisibility cloak has deactivated on reaching the end of its allowed time.
</td></tr>

<tr><td> 11
</td><td> SJ_TrapPlaced
</td><td> In the maze, the player's avatar has set a trap for the guards.
</td></tr>

<tr><td> 12
</td><td> SJ_GuardTrapped     (X, Y)=display coordinates

</td><td> A trap previously set by the player has captured a guard.
</td></tr>

<tr><td> 13
</td><td> SJ_Caught_TeleportToStart
</td><td> The player has been seen and caught by a guard or a camera, and teleports back to the starting position.
</td></tr>

<tr><td> 14
</td><td> SJ_INPUT_Esc
</td><td> The player has pressed the ESCAPE key to pause the game.

</td></tr>

<tr><td> 15
</td><td> SJ_MENU_INPUT_Enter
</td><td> The player has pressed the enter key to select a sub-portion of the game.
</td></tr>

<tr><td> 19
</td><td> SJ_END     Level=LevelN

</td><td> In the maze, the player has reached the end of the current level.
</td></tr>

<tr><td> 23
</td><td> SJ_INPUT_Move_Up
</td><td> In the maze, the player has pressed the up-arrow to move up.
</td></tr>

<tr><td> 24
</td><td> SJ_INPUT_Move_Down
</td><td> In the maze, the player has pressed the down-arrow to move down.

</td></tr>

<tr><td> 25
</td><td> SJ_INPUT_Move_Right
</td><td> In the maze, the player has pressed the right-arrow to move right.
</td></tr>

<tr><td> 26
</td><td> SJ_INPUT_Move_Left
</td><td> In the maze, the player has pressed the left-arrow to move left.
</td></tr>

<tr><td> 33
</td><td> SJ_INPUT_Interact
</td><td> In the maze, the player is interacting with an object or entity.
</td></tr>

<tr><td> 34
</td><td> SJ_INPUT_LeftClick     (X, Y)=display coordinates
</td><td> The player has clicked the left mouse button at the given display coordinates.

</td></tr>

<tr><td COLSPAN="3">Embedded Figures Test Events</td></tr>

<tr><td> 38
</td><td> SJ_EFT_Stimulus_Presented     Key=KeyN Figure=FigureM
</td><td> In the Embedded Figures Test, the player has been presented with a pair comprising a complex search figure and a smaller search target.

</td></tr>

<tr><td> 39
</td><td> SJ_EFT_HIT
</td><td> In the Embedded Figures Test, the SJ_EFT_INPUT_Match event immediately preceding was a correct response.
</td></tr>

<tr><td> 40
</td><td> SJ_EFT_REJECT
</td><td> In the Embedded Figures Test, the SJ_EFT_INPUT_NoMatch event immediately preceding was a correct response.
</td></tr>

<tr><td> 41
</td><td> SJ_EFT_FALSE_ALARM
</td><td> In the Embedded Figures Test, the SJ_EFT_INPUT_Match event immediately preceding was an incorrect response.
</td></tr>

<tr><td> 42
</td><td> SJ_EFT_MISS
</td><td> In the Embedded Figures Test, the SJ_EFT_INPUT_NoMatch event immediately preceding was an incorrect response.
</td></tr>

<tr><td> 44
</td><td> SJ_EFT_END_FAIL
</td><td> The player has given incorrect responses on three trials, ending the Embedded Figures Test.
</td></tr>

<tr><td> 46
</td><td> SJ_EFT_INPUT_NoMatch
</td><td> In the Embedded Figures Test, the player has indicated that the target does not occur within the given figure.
</td></tr>

<tr><td> 47

</td><td> SJ_EFT_INPUT_Match
</td><td> In the Embedded Figures Test, the player has indicated that the target occurs within the given figure.
</td></tr>

<tr><td> 48
</td><td> SJ_EFT_INPUT_Proceed
</td><td> The player has started a trial within the Embedded Figures Test.
</td></tr>

<tr><td> 49
</td><td> SJ_EFT_START

</td><td> The Embedded Figures Test has begun.
</td></tr>

<tr><td> 50
</td><td> SJ_EFT_END_SUCCESS
</td><td> The player has completed the Embedded Figures Test with fewer than three incorrect responses.
</td></tr>

<tr><td COLSPAN="3">Theory-of-Mind Task Events</td></tr>

<tr><td> 52

</td><td> SJ_SAT_START
</td><td> The theory-of-mind test (a.k.a. the "Sally-Anne test") has begun.
</td></tr>

<tr><td> 53
</td><td> SJ_SAT_END
</td><td> The theory-of-mind test (a.k.a. the "Sally-Anne test") has ended, after feedback has been given to the player.
</td></tr>

<tr><td> 55
</td><td> SJ_SAT_Video_Stop

</td><td> The currently active video has ended, and the player is being prompted to have it repeated or to continue.
 See details of the <A HREF="http://www.AutismCollaborative.org/wiki_aux/SJ_SAT_video_timecodes.txt">video event timings.
</td></tr>

<tr><td> 56
</td><td> IGNORE (VideoReplay)
</td><td> (This code should not be being transcribed onto the parallel port and thus should not be appearing in the EEG log.)
</td></tr>

<tr><td> 58

</td><td> SJ_SAT_INPUT_Continue
</td><td> The player has pressed the space bar, signalling readiness to view the next video stimulus. (This same numeric code also can appear with the notation "IGNORE" in which case it should not be being transcribed to the parallel port and this should not be appearing in the EEG log.)
</td></tr>

<tr><td> 59
</td><td> SJ_SAT_VideoStart_CargoDrop     Planet={TOP, RIGHT, BOTTOM, LEFT}
</td><td> The video showing the friendly space captain depositing the cargo on one of the planets has started.

</td></tr>

<tr><td> 60
</td><td> SJ_SAT_VideoStart_Pirate_Drop     Planet={TOP, RIGHT, BOTTOM, LEFT}
</td><td> The video showing the pirate depositing the cargo on another planet has started. The PLANET parameter will always differ from that of the previous SJ_SAT_VideoStart_Pirate_Theft.
</td></tr>

<tr><td> 61

</td><td> SJ_SAT_VideoStart_Pirate_Theft     Planet={TOP, RIGHT, BOTTOM, LEFT}
</td><td> The video showing the pirate's theft of the cargo has started. The PLANET parameter will always be the same as that of the previous SJ_SAT_VideoStart_CargoDrop.
</td></tr>

<tr><td> 62
</td><td> SJ_SAT_VideoStart_Pirate_NoTheft     Planet={TOP, RIGHT, BOTTOM, LEFT}

</td><td> The video showing the pirate's scan (but no theft) of the cargo has started. The PLANET parameter will always be the same as that of the previous SJ_SAT_VideoStart_CargoDrop.
</td></tr>

<tr><td> 64
</td><td> SJ_SAT_INPUT_Response_Top
</td><td> In response to a request to plot an intercept course, the player has pressed the up-arrow key, indicating a course to the TOP planet.
</td></tr>

<tr><td> 65

</td><td> SJ_SAT_INPUT_Response_Bottom
</td><td> In response to a request to plot an intercept course, the player has pressed the down-arrow key, indicating a course to the BOTTOM planet.
</td></tr>

<tr><td> 66
</td><td> SJ_SAT_INPUT_Response_Left
</td><td> In response to a request to plot an intercept course, the player has pressed the left-arrow key, indicating a course to the LEFT planet.
</td></tr>

<tr><td> 67
</td><td> SJ_SAT_INPUT_Response_Right

</td><td> In response to a request to plot an intercept course, the player has pressed the right-arrow key, indicating a course to the RIGHT planet.
</td></tr>

<tr><td> 68
</td><td> SJ_SAT_FirstOrder_NoTheft_Correct
</td><td> In the control condition in which no theft has occurred (probability 1/3), the player's response to the first-order question ("Where will you send a ship to meet up with the captain?") has correctly indicated the planet on which the cargo was originally cached by the captain (and on which it remains cached).
 Note that the numeric event code associated correctly with this event, 68, also is used by SJ_SAT_FirstOrder_NoTheft_Incorrect below. This error is the result of a bug in SallyAnneScreen.cs.
</td></tr>

<tr><td> 68
</td><td> SJ_SAT_FirstOrder_NoTheft_Incorrect

</td><td> In the control condition in which no theft has occurred, the player's response to the first-order question ("Where will you send a ship to meet up with the captain?") has indicated a planet other than that on which the cargo was originally cached by the captain (and on which it remains cached).
 Note that the numeric event code associated with this event, 68, is incorrect and ought to be 69. This error is the result of a bug in SallyAnneScreen.cs.
</td></tr>

<tr><td> 70
</td><td> SJ_SAT_FirstOrder_Scan_Correct
</td><td> In the scenario in which the admiral scans the pirate stealing and re-caching the cargo (probability 1/3), and reports this information to the captain, the player's correct response to the first-order question ("Where will you send a ship to meet up with the captain?") actually indicates higher-order theory-of-mind: the captain believes that the pirate believes that the captain believes that the cargo remains in the planet where the captain had originally cached it, thus the player's answer indicating the same PLANET as in the preceding SJ_SAT_VideoStart_CargoDrop and SJ_SAT_VideoStart_Cruiser_View_Theft is correct.
 Note that the numeric event code associated with this event, 70, is incorrect and ought to be 73. This error is the result of a bug in SallyAnneScreen.cs.

</td></tr>

<tr><td> 70
</td><td> SJ_SAT_FirstOrder_Theft_Correct
</td><td> In the scenario in which the pirate steals and re-caches the cargo (and the admiral cannot scan this activity and thus can't report anything to the captain) (probability 1/3), the player has correctly responded to the first-order question ("Where will you send a ship to meet up with the captain?") by indicating that the captain will go to the planet on which she originally cached the cargo — that is, the same PLANET as in the preceding SJ_SAT_VideoStart_CargoDrop.
 Note that the numeric event code associated correctly with this event, 70, also is used by SJ_SAT_FirstOrder_Scan_Correct above. This error is the result of a bug in SallyAnneScreen.cs.
</td></tr>

<tr><td> 71
</td><td> SJ_SAT_FirstOrder_Theft_IncorrectTrueLocation
</td><td> In the scenario in which the pirate steals and re-caches the cargo (and the admiral cannot scan this activity and thus can't report anything to the captain), the player has responded incorrectly to the first-order question ("Where will you send a ship to meet up with the captain?") by indicating the true location of the cargo rather than the location believed by the captain.
</td></tr>

<tr><td> 72
</td><td> SJ_SAT_FirstOrder_Theft_IncorrectOtherLocation
</td><td> In the scenario in which the pirate steals and re-caches the cargo (and the admiral cannot scan this activity and thus can't report anything to the captain), the player has responded incorrectly to the first-order question ("Where will you send a ship to meet up with the captain?") by indicating one of the two planets that harbours neither the captain's original cache nor the pirate's subsequent cache. (This should hardly ever happen, and when it does happen it's as likely to be a consequence of keypress error as any other factor.)
</td></tr>

<tr><td> 74

</td><td> SJ_SAT_FirstOrder_Scan_IncorrectFakeLocation
</td><td> In the scenario in which the admiral scans the pirate stealing and re-caching the cargo, and reports this information to the captain, the player has responded incorrectly to the first-order question ("Where will you send a ship to meet up with the captain?") by indicating the captain's original hiding place (as though the admiral had not reported to the captain the pirate's new hiding place).
</td></tr>

<tr><td> 75
</td><td> SJ_SAT_FirstOrder_Scan_IncorrectOtherLocation
</td><td> In the scenario in which the admiral scans the pirate stealing and re-caching the cargo, and reports this information to the captain, the player has responded incorrectly to the first-order question ("Where will you send a ship to meet up with the captain?") by indicating one of the two planets that harbours neither the captain's original cache nor the pirate's subsequent cache. (This should hardly ever happen, and when it does happen it's as likely to be a consequence of keypress error as any other factor.)
</td></tr>

<tr><td> 76
</td><td> SJ_SAT_SecondOrder_NoTheft_Correct

</td><td> In the control condition in which the pirate scans but does not steal the cargo, the player has responded correctly to the first-order question ("Where will you send a ship to meet up with the captain?") by indicating the planet on which the captain cached the cargo.
 Note that the numeric event code associated correctly with this event, 76, also is used by SJ_SAT_SecondOrder_NoTheft_Incorrect below. This error is the result of a bug in SallyAnneScreen.cs.
</td></tr>

<tr><td> 76
</td><td> SJ_SAT_SecondOrder_NoTheft_Incorrect
</td><td> In the control condition in which the pirate scans but does not steal the cargo, the player has responded incorrectly to the first-order question ("Where will you send a ship to meet up with the captain?") by indicating one of the three planets that did not harbour the cargo.

 Note that the numeric event code associated with this event, 76, is incorrect and ought to be 77. This error is the result of a bug in SallyAnneScreen.cs.
</td></tr>

<tr><td> 78
</td><td> SJ_SAT_SecondOrder_Scan_Correct
</td><td> In the scenario in which the admiral scans the pirate stealing and re-caching the cargo, and reports this information to the captain, the player has responded correctly to the second-order question ("Where will you send a ship to intercept the pirate?") by indicating the planet on which the captain had originally cached the cargo. Because the pirate wants to find the captain, and the pirate believes (incorrectly) that the captain believes that the cargo remains where the captain originally cached it, the pirate will indeed go to the planet where the cargo was originally cached.
 Note that the numeric event code associated with this event, 78, is incorrect and ought to be 81. This error is the result of a bug in SallyAnneScreen.cs.
</td></tr>

<tr><td> 78
</td><td> SJ_SAT_SecondOrder_Theft_Correct

</td><td> In the scenario in which the pirate steals and re-caches the cargo (and the admiral cannot scan this activity and thus can't report anything to the captain), the player has responded correctly to the second-order question ("Where will you send a ship to intercept the pirate?") by indicating the planet on which the captain had originally cached the cargo. Because the pirate wants to find the captain, and the pirate believes (correctly) that the captain believes that the cargo remains where the captain originally cached it, the pirate will indeed go to the planet where the cargo was originally cached.
 Note that the numeric event code associated correctly with this event, 78, also is used by SJ_SAT_SecondOrder_Scan_Correct above. This error is the result of a bug in SallyAnneScreen.cs.
</td></tr>

<tr><td> 79
</td><td> SJ_SAT_SecondOrder_Theft_IncorrectTrueLocation
</td><td> In the scenario in which the pirate steals and re-caches the cargo (and the admiral cannot scan this activity and thus can't report anything to the captain), the player's response to the second-order question ("Where will you send a ship to intercept the pirate?") incorrectly reports the planet to which the cargo was moved by the pirate, instead of the planet on which the captain originally cached the cargo. Although the captain wants to find the cargo, the pirate wants to find the captain. Thus the pirate will move not to the planet on which he cached the cargo, but to the planet that he (correctly) believes that the captain believes the cargo is on, that is, the planet on which the captain originally cached the cargo.

<tr><td> 82

</td><td> SJ_SAT_SecondOrder_Scan_IncorrectTrueLocation
</td><td> In the scenario in which the admiral scans the pirate stealing and re-caching the cargo, and reports this information to the captain, the player's response to the second-order question ("Where will you send a ship to intercept the pirate?") incorrectly reports the planet to which the cargo was moved by the pirate, instead of the planet on which the captain originally cached the cargo. Although the captain wants to find the cargo, the pirate wants to find the captain. Thus the pirate will move not to the planet on which he cached the cargo, but to the planet that he (incorrectly) believes that the captain believes the cargo is on, that is, the planet on which the captain originally cached the cargo.
</td></tr>

<tr><td> 83
</td><td> SJ_SAT_SecondOrder_Scan_IncorrectOtherLocation
</td><td> n the scenario in which the admiral scans the pirate stealing and re-caching the cargo, and reports this information to the captain, the player's response to the second-order question ("Where will you send a ship to intercept the pirate?") incorrectly reports one of the two planets that harbours neither the captain's original cache nor the pirate's subsequent cache. (This should hardly ever happen, and when it does happen it's as likely to be a consequence of keypress error as any other factor.)
</td></tr>

<tr><td> 84
</td><td> SJ_SAT_FirstOrder_Question_Presented SJ_SAT_SecondOrder_Question_Presented
</td><td> After the explanatory text ("The captain wants to pick up the cargo. She will steer her ship to the planet where she thinks the cargo is. The pirate wants to find the captain. He will steer his ship to wherever he thinks the captain will go."), the first-order question ("Where will you send a ship to meet up with the captain?") or the second-order question ("Where will you send a ship to intercept the pirate?") has just been asked.
 Note that the same numeric event code, 84, is used for both SJ_SAT_FirstOrder_Question_Presented and SJ_SAT_SecondOrder_Question_Presented.
</td></tr>

<tr><td> 85
</td><td> SJ_SAT_VideoStart_Cruiser_View_Theft     Planet={TOP, RIGHT, BOTTOM, LEFT}

</td><td> The video showing the admiral's viewing of the theft has started. The PLANET parameter will always be the same as that of the previous SJ_SAT_VideoStart_CargoDrop.
 Note that the numeric event code associated with this event, 85, is incorrect and ought to be 86. This error is the result of a bug in SallyAnneScreen.cs.
</td></tr>

<tr><td> 85
</td><td> SJ_SAT_VideoStart_Cruiser_NoScan
</td><td> In the scenario in which the pirate has stolen and re-cached the cargo, and the admiral cannot scan this activity and thus can't report anything to the captain, the video showing only noise and interference on the admiral's viewscreen has started.
 Note that the numeric event code associated correctly with this event, 85, also is used by SJ_SAT_VideoStart_Cruiser_View_Theft above. This error is the result of a bug in SallyAnneScreen.cs.

</td></tr>

<tr><td> 87
</td><td> SJ_SAT_VideoStart_Cruiser_View_NoTheft     Planet={TOP, RIGHT, BOTTOM, LEFT}
</td><td> In the control condition in which no theft has occurred, the video showing the admiral's view of the pirate's scanning but not stealing the cargo has started.
</td></tr>

</table>

After deletion of codes 255 and greater, and alignment of the behavioural and EEG event sequences just as was done for Maritime Defender, processing should continue by correcting (both in the behavioural log file and in the EEG log file) the numeric event codes that are associated with the following string event descriptors in the behavioural log file (see notes in the table above):
 SJ_SAT_FirstOrder_NoTheft_Incorrect
 SJ_SAT_FirstOrder_Scan_Correct
 SJ_SAT_SecondOrder_NoTheft_Incorrect
 SJ_SAT_SecondOrder_Scan_Correct
 SJ_SAT_SecondOrder_Question_Presented
 SJ_SAT_VideoStart_Cruiser_View_Theft

SJ_EFT_INPUT_Match and SJ_EFT_INPUT_NoMatch events should be re-coded as context-free events based on the success flags (SJ_EFT_HIT, SJ_EFT_REJECT, SJ_EFT_FALSE_ALARM, SJ_EFT_MISS) that follow each of them. The success flags themselves then can be deleted, as they do not mark any actual events distinct from the SJ_EFT_INPUT_Match SJ_EFT_INPUT_NoMatch that they follow.

Similarly, SJ_SAT_INPUT_Response_{Top, Bottom, Left, Right} events should be re-coded as context-free events based on the success flags (SJ_SAT_FirstOrder_{*} and SJ_SAT_SecondOrder_{*}). In the re-coded events, both the four possible locations of the response (Top, Bottom, Left, Right) and the four possible correctness conditions of the response (Correct, IncorrectTrueLocation, IncorrectFakeLocation, IncorrectOtherLocation) should be preserved, thus there will be 4x4 = 16 possible codes. The success flags themselves then can be deleted, as they do not mark any actual events distinct from the SJ_SAT_INPUT_Response_{*} events that they follow.

''Behavioural measures related to executive function''

As simple behavioural measures of executive function, the software can compute - for each level separately and for all levels cumulatively - the total number of moves, the total time elapsed from start to finish (excluding time spent in EFT and SAT subtests), and the mean and standard deviation of the time between successive moves. Other measures are possible; if you think of one, try it!

''Behavioural measures related to perceptual disembedding''

d' ("d prime") should be computed from tallies of EFT hits, misses, false alarms and correct rejections. If the tally for any one of these four categories of responses is zero, that tally can be changed to 1 so as to estimate d'.

Mean and standard deviation of EFT reaction time, for correct responses only, should be computed. Also list out the single-trial reaction times.

''Behavioural measures related to theory-of-mind''

Single-trial data should be extracted and listed out for first-order and second-order questions in all trials. Three types of trials exist: the first-order control condition in which the pirate scans but does not steal the cargo (probability 1/3, and note that in this case it doesn't matter whether or not the admiral observes the pirate; the observed and unobserved cases can be collapsed into a single bin), the first-order theory-of-mind conditions in which the pirate steals the cargo but is not observed by the admiral (probability 1/3), and the second-order theory-of-mind condition in which the pirate steals the cargo but the admiral observes this theft and tells the captain (probability 1/3). The single-trial data should be listed first for the no-theft condition, then separately for the unobserved theft condition, then separately for the observed theft condition. The data for each trial comprise three timings and two correctness values: the time taken for the whole trial (SJ_SAT_END minus SJ_SAT_START), the reaction time for response to the first-order question (SJ_SAT_INPUT_Response_{*} minus SJ_SAT_FirstOrder_Question_Presented) and the correctness condition (Correct, IncorrectTrueLocation, IncorrectFakeLocation, IncorrectOtherLocation) of that response, and the reaction time for response to the second-order question (SJ_SAT_INPUT_Response_{*} minus SJ_SAT_SecondOrder_Question_Presented) and the correctness condition of that response.

Summaries of correctness conditions for each of the two question types (first order, second order) for each of the three theft conditions (no theft, unobserved theft, observed theft) should be given both as tallies and as percentages.

For correct responses only, means and standard deviations (where computable) should be given for the following reaction-time differences:

''First-order question:''
 Unobserved Theft minus No Theft
 Unobserved Theft minus Observed Theft
 Unobserved Theft minus (No Theft or Observed Theft, pooled)

''Second-order question:''
 Observed Theft minus Unobserved Theft
 Observed Theft minus No Theft
 Observed Theft minus (Unobserved Theft or No Theft, pooled)

''Independent Components Analysis''

ICA can be applied separately to epochs from the Embedded Figures Test, epochs from the Sally-Anne test, and perhaps continuous EEG for the maze task.

Remember not to include the skin-conductance channel (the greatest-numbered channel) in the ICA!

''Physiological measures related to perceptual disembedding''

Standard ERP and ERSP analyses can be constructed round the SJ_EFT_Stimulus_Presented event and corresponding SJ_EFT_INPUT_{*} response events.

''Physiological measures related to theory-of-mind''

Some possible fMRI-based contrasts:

Gaze perception (blink events or gaze aversion intervals versus direct gaze intervals) 
See the timecodes file linked from the SAT_SJ_Video_Stop event in the table above. See also <A HREF="http://dx.doi.org/10.3389/fnhum.2011.00068">Brefczynski-Lewis et al. on ERP response to a social partner's blinks</A>.

Facial expression perception (scowl intervals versus neutral intervals)

Scene perception (egocentric view of person's face, versus allocentric view of person's hands on console, versus external view of spaceships)

Perception of body movements (hands) or gestures (nods)

Also note that, because these stimuli are cinematic, useful information can be gleaned from applying Uri Hasson's approach of correlating individual subjects' voxelwise activation time series against the group mean. This model-free procedure can identidy consistent activations, localised temporally and anatomically, across subjects. The timings of such consistent activities then can be correlated with the video timecodes (see link in the table above).

It may be useful to contrast fMRI time series during the video stimuli analogous to the behavioural (reaction-time) contrasts detailed above - that is, Unobserved Theft minus No Theft, Unobserved Theft minus Observed Theft, and so forth. (For a list of specific contrasts, see the behavioural section above.)

For EEG analyses, given the temporally extended nature of these stimuli spectral and other quantitative-EEG methods may be more appropriate than ERP's.

For background on cognitive electrophysiology of theory-of-mind, see <A HREF="http://dx.doi.org/10.1523/JNEUROSCI.1392-11.2011">McCleery et al., "The Neural and Cognitive Time Course of Theory of Mind", Journal of Neuroscience, 7 September 2011, 31(36):12849-12854</A>.

''Physiological measures related to executive function''

Here again, quantitative-EEG methods may be most appropriate. In addition, specific time-locked events may generate specific ERP's of interest, for example error-related negativity on SJ_INPUT_Move_{*} events that immediately precede SJ_Caught_TeleportToStart events.

Data analysis - Maritime Defender

2011-03-19T16:27:39Z

Belmonte: added details on extracting the motion coherence threshold from the behavioural log file

'''Maritime Defender'''

The game begins with MD_MaritimeDefenderGameBegin (41) and ends with MD_DotCoherenceEstimate (6). The game also is considered to have ended if the begin code for any other mini-game occurs. The game comprises multiple iterations of two phases, the shooter phase (testing go/no-go inhibition) and the navigation phase (testing motion coherence perception). The shooter phase begins with MD_ShooterPhaseBegin (13) and ends with either MD_DotPhaseBegin (1) or MD_BossPhaseBegin (32). The navigation phase begins with MD_DotPhaseBegin (1) and ends with either MD_ShooterPhaseBegin (13) or MD_BossPhaseBegin (32). Any phase also can be terminated with an End_of_log (0) code, which appears in the behavioural log file but not in the EEG log file. Following is a list of all the event codes, then a summary of the relevant behavioural and electrophysiological derived measures to extract:

<table BORDER="1">
<tr><td> 1
</td><td> MD_DotPhaseBegin
</td><td> The navigation phase (comprising many motion coherence trials) of the game has begun
</td></tr>

<tr><td> 2
</td><td> MD_DotTrialBegin
</td><td> One individual motion coherence trial (within the navigation phase) has begun
</td></tr>

<tr><td> 3
</td><td> MD_DotTrialExpire
</td><td> A motion coherence trial has timed out without any behavioural response
</td></tr>

<tr><td> 4
</td><td> MD_DotTrialUserRespondLeft
</td><td> The player has pressed the left arrow during a motion coherence trial
</td></tr>

<tr><td> 5

</td><td> MD_DotTrialUserRespondRight
</td><td> The player has pressed the right arrow during a motion coherence trial
</td></tr>

<tr><td> 6
</td><td> MD_DotCoherenceEstimate
</td><td> At the end of a navigation phase, the maximum-likelihood estimator has recalculated the psychophysical perceptual threshold for motion coherence
</td></tr>

<tr><td> 7
</td><td> MD_ShipIdentifierTestBegin

</td><td> At the beginning of the game, the friend-or-foe ship identifier dialogue has begun
</td></tr>

<tr><td> 8
</td><td> MD_ShipIdentifierSelectLeft
</td><td> During the friend-or-foe ship identifier dialogue, the player has pressed the left arrow
</td></tr>

<tr><td> 9
</td><td> MD_ShipIdentifierSelectRight
</td><td> During the friend-or-foe ship identifier dialogue, the player has pressed the right arrow

</td></tr>

<tr><td> 10
</td><td> MD_ShipIdentifierConfirmSelection
</td><td> During the friend-or-foe ship identifier dialogue, the player has pressed the return key to confirm their selection
</td></tr>

<tr><td> 11
</td><td> MD_ShipIdentifierTestEndSuccess
</td><td> The player's response in the friend-or-foe ship identifier dialogue is correct
</td></tr>

<tr><td> 12
</td><td> MD_ShipIdentifierTestEndFailure
</td><td> The player's response in the friend-or-foe ship identifier dialogue is incorrect
</td></tr>

<tr><td> 13
</td><td> MD_ShooterPhaseBegin
</td><td> The shooter phase (comprising many go/no-go trials) of the game has begun
</td></tr>

<tr><td> 14
</td><td> MD_ShooterActivateOpenWormholeBeam
</td><td> During the shooter phase, the player has depressed the up-arrow to activate the wormhole-opener beam
</td></tr>

<tr><td> 15
</td><td> MD_ShooterCeaseOpenWormholeBeam
</td><td> During the shooter phase, the player has released the up-arrow to cease the wormhole-opener beam
</td></tr>

<tr><td> 16

</td><td> MD_ShooterOpenWormholeSuccess
</td><td> During the shooter phase, the wormhole-opener beam has opened the wormhole
</td></tr>

<tr><td> 17
</td><td> MD_ShooterActivateMovePort
</td><td> During the shooter phase, the player has depressed the left-arrow to begin moving clockwise
</td></tr>

<tr><td> 18
</td><td> MD_ShooterCeaseMovePort

</td><td> During the shooter phase, the player has released the left-arrow to cease moving clockwise
</td></tr>

<tr><td> 19
</td><td> MD_ShooterActivateMoveStarboard
</td><td> During the shooter phase, the player has depressed the right-arrow key to begin moving anticlockwise
</td></tr>

<tr><td> 20
</td><td> MD_ShooterCeaseMoveStarboard
</td><td> During the shooter phase, the player has released the right-arrow key to cease moving anticlockwise

</td></tr>

<tr><td> 21
</td><td> MD_ShooterPresentFriendly
</td><td> During the shooter phase, a friendly ship has emerged from an opened wormhole
</td></tr>

<tr><td> 22
</td><td> MD_ShooterPresentEnemy
</td><td> During the shooter phase, a hostile ship has emerged from an opened wormhole
</td></tr>

<tr><td> 23
</td><td> MD_ShooterPresentWormhole
</td><td> During the shooter phase, a wormhole has appeared
</td></tr>

<tr><td> 24
</td><td> MD_ShooterActivateFireWeapon
</td><td> During the shooter phase, the player has depressed the space bar to begin firing
</td></tr>

<tr><td> 25
</td><td> MD_ShooterCeaseFireWeapon
</td><td> During the shooter phase, the player has released the space bar to cease firing
</td></tr>

<tr><td> 26
</td><td> MD_ShooterPlayerWeaponFired
</td><td> During the shooter phase, the weapon has fired (Multiple WeaponFired events can occur between an ActivateFireWeapon and a CeaseFireWeapon, as the space bar is held down for continuous fire)
</td></tr>

<tr><td> 27

</td><td> MD_ShooterEnemyWeaponFired
</td><td> During the shooter phase, a hostile ship has fired at the player
</td></tr>

<tr><td> 28
</td><td> MD_ShooterCollectibleSpawned
</td><td> During the shooter phase, a collectible has emerged from a destroyed asteroid or from a friendly ship
</td></tr>

<tr><td> 29
</td><td> MD_ShooterPlayerCollectibleCollision

</td><td> During the shooter phase, the player's ship has picked up a collectible
</td></tr>

<tr><td> 30
</td><td> MD_ShooterMeteorExplosion
</td><td> During the shooter phase, an asteroid has exploded
</td></tr>

<tr><td> 31
</td><td> MD_ShooterPlayerGetsHit
</td><td> During the shooter phase, the player's ship has been hit by hostile fire or by an asteroid

</td></tr>

<tr><td> 32
</td><td> MD_BossPhaseBegin
</td><td> The 'boss phase' has begun - no scientifically important events here, just entertainment and reward for completing the level
</td></tr>

<tr><td> 33
</td><td> MD_GameSuccess
</td><td> The player has successfully completed the boss phase, beating the game

</td></tr>

<tr><td> 34
</td><td> MD_GameFailure
</td><td> During any game phase (shooter, navigation, or boss), the player's last of three ships has been destroyed, losing the game
</td></tr>

<tr><td> 35
</td><td> MD_DialogSkip
</td><td> The player has skipped a dialogue

</td></tr>

<tr><td> 36
</td><td> MD_MenuSelect
</td><td> The player has selected an item in the menu
</td></tr>

<tr><td> 37
</td><td> MD_MenuCancel
</td><td> The player has cancelled the menu
</td></tr>

<tr><td> 38
</td><td> MD_Pause
</td><td> The player has paused the game
</td></tr>

<tr><td> 39
</td><td> MD_Unpause
</td><td> The player has unpaused the game
</td></tr>

<tr><td> 40
</td><td> MD_OpenConsole
</td><td> The player has opened the console
</td></tr>

<tr><td> 41
</td><td> MD_MaritimeDefenderGameBegin
</td><td> The game has begun
</td></tr>

<tr><td> 42
</td><td> MD_CockpitDamageFeedback
</td><td> During the navigation phase, the cockpit shakes, indicating damage and loss of energy, following a non-response or an incorrect response
</td></tr>

<tr><td> 43
</td><td> MD_TutorialStart
</td><td> The optional tutorial has begun
</td></tr>

<tr><td> 44
</td><td> MD_Section1
</td><td> This and the next several codes define the times of entry into the tutorial's several successive sections:
</td></tr>

<tr><td> 45
</td><td> MD_Section2
</td><td></td></tr>

<tr><td> 46
</td><td> MD_Section3

</td><td></td></tr>

<tr><td> 47
</td><td> MD_Section4
</td><td></td></tr>

<tr><td> 48
</td><td> MD_Section5
</td><td></td></tr>

<tr><td> 49
</td><td> MD_Section6

</td><td></td></tr>

<tr><td> 50
</td><td> MD_Section7
</td><td></td></tr>

<tr><td> 51
</td><td> MD_Section8
</td><td></td></tr>

<tr><td> 52
</td><td> MD_Section9

</td><td></td></tr>

<tr><td> 53
</td><td> MD_Section10
</td><td></td></tr>

<tr><td> 54
</td><td> MD_Section11
</td><td></td></tr>

<tr><td> 55
</td><td> MD_Section12

</td><td></td></tr>

<tr><td> 56
</td><td> MD_Section13
</td><td></td></tr>

<tr><td> 57
</td><td> MD_Section14
</td><td></td></tr>

<tr><td> 58
</td><td> MD_Section15

</td><td></td></tr>

<tr><td> 59
</td><td> MD_Section16
</td><td></td></tr>

<tr><td> 60
</td><td> MD_TutorialEnd
</td><td> The tutorial has ended
</td></tr>
</table>

The processing software should delete all existing event codes greater than or equal to 255. These codes are inserted by the BioSemi EEG recording hardware and are not needed.

The processing software then must align (both by sequence and by specific temporal offset) the event codes in the EEG record with the event codes in the game log. The game log is the master copy of the event codes; codes transmitted to the EEG recorder can sometimes be erroneously dropped or, more rarely, erroneously replicated.

Note that because of the rapid play in Maritime Defender in particular, events may occur in bursts. This is particularly true of events MD_ShooterCollectibleCollision (29) and MD_ShooterMeteorExplosion (30). These bursts may overwhelm the parallel port's ability to transmit event codes, as each tranmission takes 5ms plus reset time. In case alignment is not possible during these rapid bursts (series of N events all of which occur within N*5ms of each other), the first event in the series can be preserved and the subsequent events deleted, or given some alternative event code that would flag that these events are uncertain in their temporal localisation and therefore not to be used to time-lock ERPs. This is a fine strategy, as stimuli occurring closer together than 5ms are, for all intents and purposes, a single stimulus anyway. So by preserving only the first event in the rapid series, we mark the onset time of this single, aggregate stimulus.

Lastly, the processing software must translate context-sensitive event codes (for example, a stimulus, contextualised by either an incorrect behavioural response or a correct behavioural response following) into context-free event codes as detailed below. Events that already are context-free should simply be transcribed as is. All events - both those that are being translated and those that are being transcribed - should be renumbered so that their codes are greater than 255 and in a range dedicated to each mini-game separately. This constraint could be implemented, for example, by adding 1000 to the transcribed event codes for Maritime Defender, adding 2000 to those for Stellar Prospector, and so on, creating a separate, non-overlapping range of event codes for each mini-game.

These event code translations, and all derived behavioural data as detailed below, should be integrated into Keith Yoder's Astropolis Processing Toolkit so that they are fully automated and can be performed at the touch of a button by a user who knows nothing of computer programming.

''Independent Components Analysis''

For the shooter phase, ICA can be applied to epochs beginning with MD_ShooterOpenWormholeSuccess and ending with MD_ShooterActivateFireWeapon, MD_ShooterEnemyWeaponFired, or MD_ShooterCollectibleSpawned, whichever comes first.

For the navigation phase, ICA can be applied to the entire continuous EEG record from the first MD_DotTrialBegin after the MD_DotPhaseBegin, up till the first event that is NOT any of MD_DotTrialBegin (2), MD_DotTrialExpire (3), MD_UserRespondLeft (4), MD_UserRespondRight (5), or MD_CockpitDamageFeedback (42).

Remember not to include the skin-conductance channel (the greatest-numbered channel) in the ICA!

''Potentials related to behavioural inhibition''

Go trials and no-go trials each can be successful or unsuccessful; there are therefore four categories of events each beginning with an MD_ShooterPresentFriendly (21) which signals a no-go trial or an MD_ShooterPresentEnemy (22) which signals a go trial. The analysis software should use the context provided by subsequent events to translate these two codes into four codes as follows:

At an MD_ShooterPresentFriendly (21), if there is no MD_ShooterActivateFireWeapon (24) until the next MD_ShooterCollectibleSpawned (28) or until 5 seconds have elapsed, whichever is sooner, then code this event as MD_ShooterNoGoSUCCEED. Otherwise code MD_ShooterNoGoFAIL. This new event code replaces the originally logged MD_ShooterPresentFriendly, and is inserted into the data at the time time stamp as the originally logged event.

At an MD_ShooterPresentEnemy (22), if there is no MD_ShooterActivateFireWeapon (24) until the next MD_ShooterEnemyWeaponFired (27) or until 5 seconds have elapsed, whichever is sooner, then code this event as MD_ShooterGoFAIL. Otherwise code MD_ShooterGoSUCCEED. This new event code replaces the originally logged MD_ShooterPresentFriendly, and is inserted into the data at the time time stamp as the originally logged event.

MD_ShooterActivateFireWeapon events within MD_ShooterNoGoFAIL sequences should be re-coded as MD_ShooterWeaponFALSE_ALARM. MD_ShooterActivateFireWeapon events within MD_ShooterGoSUCCEED sequences should be re-coded as MD_ShooterWeaponHIT.

The following behavioural measures can be computed: 
1. Reaction time: The mean and standard deviation of reaction time for MD_ShooterGoSUCCEED can be calculated from the intervals between the relevant MD_ShooterPresentEnemy and MD_ShooterActivateFireWeapon events. 
2. Accuracy: d' can be calculated where hits are MD_ShooterGoSUCCEED, misses are MD_ShooterGoFAIL, false alarms are MD_ShooterNoGoFAIL, and correct rejections are MD_ShooterNoGoSUCCEED.

''Motor and preparatory potentials''

For the events MD_ShooterActivateMovePort (17), MD_ShooterActivateMoveStarboard (19), and MD_ShooterActivateOpenWormholeBeam (14), both the bereitschaftspotential (readiness potential, from supplementary motor area) ERP and the event-related desynchronisation of the mu rhythm near the hand area (lateral central electrodes) can be computed.

The interval between MD_ShooterOpenWormholeSuccess (16) and MD_ShooterGoSUCCEED will evoke a Contingent Negative Variation at frontocentral electrodes which resolves into a motor execution. The interval between MD_ShooterOpenWormholeSuccess (16) and MD_ShooterNoGoSUCCEED will evoke the same Contingent Negative Variation, followed by a further inhibition-related negativity instead of by motor execution. Both the CNV beginning at the time of MD_ShooterOpenWormholeSuccess and the response-related activities time-locked to MD_ShooterGoSUCCEED and MD_ShooterNoGoSUCCEED are of interest.

The following behavioural measures can be computed:
1. Between each pair of MD_ShooterPresentWormhole (23) and MD_ShooterOpenWormholeSuccess (16): 
1A. Elapsed time (mean and SD) 
1B. Number of distinct movement commands (MD_ShooterActivateMovePort (17) or MD_ShooterActivateMoveStarboard (19)), and also the mean and SD of this quantity after Anscombe transformation or other Poisson-to-normal transformation. 
2. A detailed curve, with a sequence number (1, 2, 3, ...) of the wormhole event on the x axis and the number of movement commands on the y axis; does the player improve as time goes on?

''Potentials related to attention and context updating''

P3 on MD_ShooterNoGoSUCCEED, and separately on MD_ShooterGoSUCCEED: mean half-integral amplitude and latency.

Frontal negativity following MD_ShooterNoGoSUCCEED (contrast to the same following MD_ShooterGoSUCCEED).

P1 on MD_ShooterNoGoSUCCEED and MD_ShooterGoSUCCEED pooled.

''Potentials related to motion perception''

Leftward-drifting trials and rightward-drifting trials each can be successful or unsuccessful; there are therefore four categories of events each beginning with an MD_DotTrialBegin (2). The analysis software should use the context provided by subsequent events to translate this code into six codes as follows:

At an MD_DotTrialBegin Direction=Left followed by MD_UserRespondLeft as the very next event, code MD_DotLeftHIT, and similarly at an MD_DotTrialBegin Direction=Right followed by MD_UserRespondRight as the very next event, code MD_DotRightHIT.

At an MD_DotTrialBegin Direction=Left followed by MD_UserRespondRight as the very next event, code MD_DotLeftFALSE_ALARM, and similarly at an MD_DotTrialBegin Direction=Right followed by MD_UserRespondLeft as the very next event, code MD_DotRightFALSE_ALARM.

At an MD_DotTrialBegin Direction=Left whose next event is neither MD_UserRespondLeft nor MD_UserRespondRight is an MD_DotLeftMISS, and similarly an MD_DotTrialBegin Direction=Right whose next event is neither MD_UserRespondLeft nor MD_UserRespondRight is an MD_DotRightMISS.

MD_UserRespondLeft events following MD_DotLeftHIT, and MD_UserRespondRight events following MD_DotRightHIT, should be re-coded as MD_DotResponseHIT.

MD_UserRespondRight events following MD_DotLeftFALSE_ALARM, and MD_UserRespondLeft events following MD_DotRightFALSE_ALARM, should be re-coded as MD_DotResponseFALSE_ALARM.

MD_CockpitDamageFeedback events immediately following MD_DotResponseFALSE_ALARM events should be re-coded as MD_DotFeedbackFALSE_ALARM. MD_CockpitDamageFeedback events immediately following MD_DotTrialBegin events should be re-coded as MD_DotFeedbackMISS.

ERPs and ERSPs time-locked to each of the six MD_Dot stimulus onset events can be compared; pilot data indicate that the ERSPs would show event-related desynchronisations in occipital generators. (There might not be sufficient FALSE_ALARM events for reliable averaging, in which case just the HIT and MISS events can be compared.) Likewise, ERPs and ERSPs time-locked to each of the three (or two, if there are insufficient numbers of false alarms) MD_DotResponse events can be compared.

The following behavioural measure can be computed: 
1. The latest of the several coherence perceptual threshold estimates can be extracted from the last MD_DotCoherenceEstimate (6) in the behavioural log file. In case this event is missing because of a crashed game or otherwise corrupted log file, the coherence parameter from the latest (last in the file) MD_DotTrialBegin (2) can be used.

''Potentials related to reward''

MD_ShooterCollectibleCollision (29) and MD_ShooterMeteorExplosion (30) both can be examined for a cingulate negativity related to reward value which occurs between 250 and 350 ms post-stimulus; see Yeung et al. http://dx.doi.org/10.1093/cercor/bhh153

Skin conductance response (recorded on the highest-numbered channel) may also be of particular interest during these events.

''Potentials related to error processing''

MD_ShooterWeaponFALSE_ALARM events should generate a cingulate error-related negativity; this error-related negativity can be most straightforwardly visualised by computing a difference wave: subtract the ERP associated with MD_ShooterWeaponHIT events from the ERP associated with MD_ShooterWeaponFALSE_ALARM events.

During the navigation phase, a couple of strategies might be applied to discern the error-related negativity associated with erroneous responses: The right way to do it, if there were enough MD_DotResponseFALSE_ALARM events available for reliable ERP averaging, would be to subtract the ERP associated with MD_DotResponseHIT events from the ERP associated with MD_DotResponseFALSE_ALARM events. But there probably won't be sufficient numbers of false-alarm responses for that. Instead of false alarms, subjects who are unable to discern the motion direction probably will generate misses - that is, no overt behavioural response at all. So we can look at the ERP associated with MD_DotFeedbackMISS (without any subtraction).

Skin conductance response (recorded on the highest-numbered channel) may also be of particular interest during these events.

Face Off

2010-04-13T16:32:32Z

Mcd8604: /* Event Code Semantics */

==Event Code Semantics==

'''EventCode'''
// Input Events
FO_INPUT_KEY_ENTER - User has pressed the Enter key.
FO_INPUT_KEY_SPACE - User has pressed the SpaceBar key.
FO_INPUT_KEY_LEFT - User has pressed the Left key.
FO_INPUT_KEY_RIGHT - User has pressed the Right key.
FO_INPUT_MOUSE_LEFT_DOWN - User has pressed the left mouse button.
FO_INPUT_MOUSE_LEFT_UP - User has released the left mouse button.

// Game Events
FO_START - The main menu has been initialized.
FO_START_BOARD - A new board (round) has been started.
FO_STARTFACELOAD - A face on the tray has begun to load.
FO_FACELOADED - A face on the tray has finished loading.
FO_FACEDRAG - The user has begun to drag a face from the tray.
FO_BOARDFILL- The user has dropped a face from the tray onto an empty board cell.
FO_BOARDUNDO - A filled cell on the board was clicked, sending the face back to the tray and emptying the filled cell.
FO_CORRECT_GROUP - A group was determined correct during validation.
FO_INCORRECT_GROUP - A group was determined incorrect during validation.
FO_END - The user has finished the game and exited.
FO_END_BOARD - The user has finished a board (round).
FO_MENU_QUIT - User has exited Face Off via main menu.

==How to substitute new face stimuli==

# Make the file system changes following the guidelines below.
# [[Code_How_To's#Use_Images|Update content]] for Face Off in the game solution for the corresponding file system changes.
# Compile the game and test.
# [[Code_How_To's#Publish_the_Installer|Build The Installer]].

===File System Guidelines===

Face stimuli are organized into emotion categories. To add a new emotion category, simply create a new directory under Game\FaceOff\Content\Texture\Faces. Each image added to the directory must follow the proper naming convention, else the image will not be loaded.

====Image Naming Convention====

[EmotionCategory]_[ImageNumber].[Extension]

The EmotionCategory must be exactly the same as containing directory name. ImageNumber must start at 1 and increment by 1 for each image without skipping an integer. Extension can be any valid XNA supported format type.

'''Example'''
Directory:
Game\FaceOff\Content\Texture\Faces\Angry

Images:
Game\FaceOff\Content\Texture\Faces\Angry\Angry_1.png
Game\FaceOff\Content\Texture\Faces\Angry\Angry_2.png
Game\FaceOff\Content\Texture\Faces\Angry\Angry_3.png

Current images may also be replaced, so long as the naming convention is maintained.

[[Category:Mini Games]]

Troubleshooting

2009-08-29T22:08:56Z

Zinsser:

This page contains some common problems and solutions that people may run into when starting to use/develop for Astropolis.

==Common Problems for Developers==

===Build Errors===

====Project Util====
'''Example Error:'''
Error 1 The command "copy /Y "C:\Users\Arthas\Documents\Astropolis\Game\Util\SVNRes.resx" "C:\Users\Arthas\Documents\Astropolis\Game\Util\libs\temp.resx"
"SubWCRev.exe" "C:\Users\Arthas\Documents\Astropolis\Game\\" "C:\Users\Arthas\Documents\Astropolis\Game\Util\SVNRes.resx" "C:\Users\Arthas\Documents\Astropolis\Game\Util\SVNRes.resx"
" exited with code 9009.

'''Solution'''
Ensure that the SubWCRev.exe program (which should be installed alongside the TortoiseSVN clien) is included in your Path Environment Variable.

Differences in Home vs Lab Configuration

2009-01-27T20:51:53Z

Adn1646: New page: There are currently no differences between Home and Lab configurations. Any changes will be added to this page.

There are currently no differences between Home and Lab configurations.

Any changes will be added to this page.

How to Make a Mini-Game

2008-12-31T01:40:00Z

Adn1646: /* Example Source Code */

The purpose of this tutorial is to help a new developer get started with their own mini-game addition to the project.

It's expected that reader will have some knowledge of programming, preferably C# and XNA.

==Your Project==

It's not necessary for your mini-game to be integrated into the main code base. To get started, create a new XNA Project using either the Windows Game or Windows Game Library template. Next, your project needs to reference the main code. Right-click on References in your project and select 'Add Reference', Navigate to the main code base, either via SVN or from an installed copy, and select Util.dll. Util.dll is a shared library that contains many common elements between the existing mini-games.

==Your Game==

Next, we need to modify the XNA code to work with the mini-game system.

===Game.cs===

First, open the Game.cs file that came with the XNA template. Instead of being a subclass of Game, change it to be a subclass of GameScreen. GameScreen is a DrawableGameComponent that contains common functionality for mini-games to use, and is run by the main system for your game to be played.

public class Game : Gamescreen

====Constructor====

Because your mini-game object may be constructed at any time, your constructor should contain as little as possible, and need not exist.

====Initialize====

The Initialize method should contain all of your mini-game's start-up logic. In particular, you should do the following, if needed:
* Call GetLogger(); and initialize your logger object.
* Call GetInputHandler(); and initialize your input handler object.
* Bind the inputs your mini-game needs in your InputHandler. (see information on event codes)

mLogger = GetLogger();
mLogger.Initialize();

inputHandler = GetInputHandler();
inputHandler.Initialize();
inputHandler.Bind(Keys.A, Trigger.Pressed, EventCodes.UserPressedA);
inputHandler.Bind(Keys.B, Trigger.Pressed, EventCodes.UserPressedB);
inputHandler.Bind(Keys.C, Trigger.Pressed, EventCodes.UserPressedC);

====Update====

The Update method should contain all of your mini-game's runtime game logic. In particular, you must handle input, if set up in your initialization.

while (inputHandler.HasEvent())
{
InputEvent inputEvent = inputHandler.GetNextEvent();
switch ((EventCodes)inputEvent.EventCode)
{
case EventCodes.UserPressedA:
inputEvent.WriteToLog(mLogger, "A was pressed. Correct!");
break;
case EventCodes.UserPressedA:
inputEvent.WriteToLog(mLogger, "B was pressed. Try Again.");
break;
case EventCodes.UserPressedA:
inputEvent.WriteToLog(mLogger, "C was pressed. See you later.");
break;
}
}

Note that you must call WriteToLog for each input event, and provide any context information you can, even if the event was ignored. The Logging information is very important for the experimental value.

===Game Info===

In order for the main system to find and display your mini-game correctly, you need to provide some additional information. For this purpose, you will need to create a new class in your project. The class will be a subclass of MiniGameInfo, which is also from Util.dll. MiniGameInfo specifies a number of abstract methods, which must be overridden.
* GetDisplayName() - Return a string that will be used by the main system for display of your mini-game in menus and the like.
* GetGameScreen() - Return a constructed instance of your main Game, in this case, a new Game() from the code we edited above.

==Playing==

For the main system to find your mini-game, the built exe or dll and any required content must be placed in a subdirectory of the main project. It's recommended to follow the pattern of /minigames/"minigamename"/ currently used, to prevent conflicts. That's all.

==Example Source Code==

using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Input;
using Util;

namespace ExampleGame
{
public enum EventCodes
{
UserPressedA = 1,
UserPressedB = 2,
UserPressedC = 3,
}

public class Game : GameScreen
{
Logger mLogger;
InputHandler inputHandler;

Color backgroundcolor = Color.CornflowerBlue;

public override void Initialize()
{
mLogger = GetLogger();
mLogger.Initialize();

inputHandler = GetInputHandler();
inputHandler.Initialize();
inputHandler.Bind(Keys.A, Trigger.Pressed, (int)EventCodes.UserPressedA);
inputHandler.Bind(Keys.B, Trigger.Pressed, (int)EventCodes.UserPressedB);
inputHandler.Bind(Keys.C, Trigger.Pressed, (int)EventCodes.UserPressedC);

base.Initialize();
}

public override void Update(GameTime gameTime)
{
while (inputHandler.HasEvent())
{
InputEvent inputEvent = inputHandler.GetNextEvent();
switch ((EventCodes)inputEvent.EventCode)
{
case EventCodes.UserPressedA:
inputEvent.WriteToLog(mLogger, "A was pressed. Correct!");
backgroundcolor = Color.Green;
break;
case EventCodes.UserPressedB:
inputEvent.WriteToLog(mLogger, "B was pressed. Try Again.");
backgroundcolor = Color.Red;
break;
case EventCodes.UserPressedC:
inputEvent.WriteToLog(mLogger, "C was pressed. See you later.");
Done();
break;
}
}

base.Update(gameTime);
}

public override void Draw(GameTime gameTime)
{
GraphicsDevice.Clear(backgroundcolor);

base.Draw(gameTime);
}
}

public class Info : MiniGameInfo
{
protected override string GetDisplayName()
{
return "Example Mini-Game";
}
protected override GameScreen GetGameScreen()
{
return new Game();
}
}
}

Building Placement Log Specification

2008-12-03T00:47:16Z

Brb6127:

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.

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.

Star Jack

2008-10-07T23:55:01Z

Belmonte:

==Summary==

This minigame tests theory of mind and visual perceptual disembedding.

The mini-game's theory-of-mind component is an adaptation of the classic “Sally Anne” test of theory-of-mind. In the “Sally Anne” test one character, Sally, places a marble in a safe place, and then whilst Sally is out of the room another character, Anne, moves the marble to a new hiding place. The subject is asked “Where will Sally look for her marble?” or “Where does Sally think the marble is?” Many autistic children, like normal children under four years of age, answer this question erroneously in terms of what they themselves know about where Anne moved the marble, instead of what Sally knows. Those who correctly answer this first-order theory-of-mind question may still respond incorrectly to a second-order question: if, unbeknownst to Anne, Sally was peering through the keyhole and saw Anne move the marble, “Where does Anne think Sally will look for the marble?”

The player is infiltrating a subspace communications satellite. The player will have to navigate to and hack comm stations to steal Pirate communication messages.

==Premise==

You are a covert operative for the World Space Initiative. The Order of Orion is attacking merchants carrying WSI payloads, stealing their cargo, and stashing the goods at various planets or locations. Your mission is to infiltrate their communication satellites and to discover the location of the stolen cargo.

==Objective==

Recover as many communication logs about stolen Cargo as possible and determine where the merchants and cargo are.

==Characters==

[[Image:ComingSoon.png]]

Player: An elite reconisaince operative trained in stealth and sabotage. These agents have access to a personal cloaking device, a molecular copier, hacking tools and many other items. They excel in non-lethal force, and avoid direct confrontation whenever possible.

Bobcat B-3 Interceptor: A small ship outfitted with the best cloaking and stealth technology available. This ship is used to get the operative to and from the satellite undetected.

Satellite Security: The satellite is garrisoned with security guards and security devices. These guards are tasked with keeping the satelite safe and uncompromised.

//These Characters will be shown in the cut scenes.
Merchants: Various merchants that ferry goods throughout the solar system. Those carrying WSI goods are targets of OoO raiders.

Raiders: Various OoO pirates target merchants under WSI contracts. Pirates can be found stealing from all across the galaxy and transporting any valuable cargo to different locations.

Cargo: The OoO is stealing WSI payloads and hiding them on planets to be picked up by other OoO operatives at a later date. Finding these are the objectives of the game. All cargoes will bear an Icon symbolizing the type of material inside.

Planets and Buildings: Pirates and merchants will move cargo from one planet to another, or one building to another.

==Gameplay==

The game is divided into 3 different phases:

Puzzle Phase
Players will explore floors of the satellite to find comm stations. They will have to avoid guards and move from room to room until they find that floor's comm station. Players will have to use their abilities to deactivate traps and guards.

Hacking Phase
Players will have to complete an Embedded Figures Test trial whenever they use their hacking tool.

Sally Anne Phase
Players will be shown an animation depicting the message the player has found. Players will then be asked the theory-of-mind questions. Game play will then switch back to the Puzzle Phase.

==Phases==

''Puzzle Phase''

Objective

The player will explore the different floors of the satellite. Before a player can move to the next floor the player must explore all the rooms of the floor and hack the communication panel. To do so, players will have to avoid detection by utilizing their various stealth abilities.

The game will be turn-based. The game state will not change until the player performs an action. This will allow players to take as much time as needed to plan their moves. Guards and other interactive objects will not do anything until after the player has done an action. Players will always complete their action before the world takes its turn.

When the player enters the facility, the security system is unaware of them. When a player is caught or fails an event, such as hacking a terminal, the security system will become more aware of them. This awareness is represented by a meter. Once them meter is filled the Security System is fully aware of the player and will send guards to capture the infiltrator. Once this occurs sirens will sound and the player will have to teleport to their ship and escape the station. The awareness level will effectively act as the player's "lives" or attempts. After an interval of turns of not being detected, the awareness level will begin to decrease.

Actions

Move - The player will be able to move in 4 unique directions.
Wait - This action represents the player's skipping a turn.
Cloak - This action will make the player invisible for a specific number of turns.
Hack - This action will start the Hacking Phase. If a player is unsuccessful in hacking the object then they will be teleported back to the beginning of the level.
Set Trap - Players will be able to set traps for guards
Use - Players will be able to interact with their environment using this action.

Enemies

Guard - Guards will patrol the halls of the facility. A patrolling guard will be able to catch any player in their line of sight. Guards will have predictable paths that they follow. Guards can be avoided by using the cloak ability, or deactivated by placing a trap. A deactivated guard will either disappear or fall to the floor. If guards do not dissappear then the player will have to move them to prevent other guards from finding the unconscious guard.

Sentry Camera - A sentry camera will detect the player if they enter its line of sight. Sentry cameras will not move, but will rotate in place. To disable a sentry camera the player must find its control panel and hack it. Each camera and control panel will have matching colors. Cloaking can be used to avoid the camera.

Espionage PDA

Every infiltrator has their own personal Espionage PDA. This PDA can communicate with the player's ship and provide them with useful information. This will be where the player can see their mission objectives and current mission progress, and can view or retry any tutorial sections or end the game.

'''Hacking Phase'''

Encrypted communications are represented by shapes that flow from the left to the right of the screen, somewhat akin to ''the Matrix.'' The bottom of the game screen houses the display of ''the Snifftron ST3,'' a device that hackers use to decrypt data.

In a manner very similar to the traditional Embedded Figures Test, the ST3 generates an abstract shape and displays it on its screen. As the data stream flows across the top of the game screen, random shapes pop out and appear in the centre of the data stream. If this large shape contains the simpler shape displayed on the ST3, then the player should press the right-arrow before the trial expires. If the large shape does not contain the simpler shape then the player should press the left-arrow. When one of these choices is made correctly, the player successfully "filters" the data stream. The player can fail this process (either by not responding, or by responding incorrectly) only 3 times before the connection is lost and the message become irretrievable. Some objects will be more difficult to hack and will require a greater number of sucessful matches.

[[Image:ComingSoon.png]]

If the player filters the data successfully enough times, then the comm is decrypted. Diffrent results will occur depending on the item hacked. If a comm terminal is hacked, a short cut-scene plays before returning to the navigation screen. If the player is unsuccessful, then they return to the navigation screen and their detection level will increase.

The large shapes are generated according the figure below. Generating smaller shapes that are embedded in the large shapes can easily be done by connecting the dots along edge connections.

[[Image:ComingSoon.png]]

==Sally Anne Phase==

Once a player successfully hacks the comm station they will be shown a brief series of animations depicting the message that they've intercepted. There will be many different messages, but each will follow the same principles. In animation #1, a friendly ship deposits a resource (e.g. fuel or materials) in a depot on one of several available planets. (Planets are readily distinguishable by their location on the star map and by their surface appearance.) In animation #2, an opponent ship appears and either steals the resource and deposits it on another planet (THEFT, 2/3 probability) or simply scans the resource (¬THEFT, 1/3 probability). Animation #3 is a picture of the friendly ship's control centre including its captain and its viewscreen, which shows either a sensor scan of the opponent's actions (SCAN, ½ probability) or noise representing sensor jamming (¬SCAN, ½ probability). Thus by the end of animation #3, one of three equiprobable situations exists: (1) the friend believes correctly that the resource is in its original location, and the opponent believes correctly that the friend will look for the resource in this location (¬THEFT); (2) the friend believes incorrectly that the resource is in its original location, and the opponent believes correctly that the friend will look for the resource in its original location (THEFT∧¬SCAN); (3) the friend believes correctly that the resource is in its new location, and the opponent believes incorrectly that the friend will look for the resource in its original location (THEFT∧SCAN). Animation #4 reminds the player that the friend will always set course to retrieve the resource, and that the opponent will always set course to intercept the friend. After this fourth animation, the player is prompted pictorially to lay in two intercept courses (by moving the mouse to the appropriate planet), one to rendez-vous with the friend and one to engage the opponent. In order to set these courses the player must infer where the friend thinks the resource is and where the opponent thinks the friend will look for the resource, respectively. Accuracy and response time in these tasks measure first-order and second-order theory-of-mind processing.

These animations will be still shots depicting the cut scene. Animations are planned for future releases.

===Sally Anne Video Specification===

====Artistic Considerations====
------------------------------------------------------------
3 different planets or more.
Multiple ethnicities.
Textures for all major actors in the animations (ships, cargo, people); it would be useful to have these in case we want to reuse them later.

====Technical Considerations====
-------------------------------------------------------------

XNA does not support movie playback. There are some workarounds but it will only display a still picture. Currently the Sally-Anne animations are implmented as a series of still frames, but these end up being to large for the scope we are looking at.

One option is to use a Flash swf video. There is a content importer called fluix for XNA that can display Flash movies in XNA. This would allow us to harness the vector-based graphics processing of Flash and its ActionScript language. C# will be able to read and to write to variables in in the Flash file, possibly changing the animation as needed. This will also allow the Flash file to send events to the C# code to be handled. Sadly fluix does not support sound for Flash files. However, we could work around it by having the Flash movie send messages to C#, letting C# know when Flash needs a sound played. Protocols for sending events would need to be determined for this scheme.

One benefit of this method would be that to change the Sally-Anne animations, all the animator would need to do would be to change the Flash file; (s)he wouldn't have to touch the C# code. Also the swf format would drastically reduce the file sizes of our videos, as we may be able to do the entire video in one file.

The other way to do this would be to have a video file playing and to create a sound cue file that plays sounds at specific time intervals. I'm not a big fan of this but it's a decent fallback.

====Scenes====
The Sally-Anne phase video will be broken up into a couple different sections.
This is to accomodate varying scenarios in the video.

The sections will be:

Cargo drop
Pirate scan
Pirate steals cargo
Pirate can't find cargo
Allied ship sees static
Allied ship sees pirate steal cargo

=====Cargo drop=====
-------------------------------------------
This section will set up the following scenes for the player. It should give all the basic information that the player needs to make sense of the scenes that will follow. The scene should identify the cargo ship and its crew as allies, and indicate a reason as to why they need to drop off their cargo. This reason could be that they need to lighten the load to escape from the pirates following them. The explanation could be delivered via the ship's captain, as this should make it obvious that it is humans and not a machine who are in control of the ships. The cargo ship will then deposit its cargo at a visually distinct planet, and then leave the area.

=====Pirate scan=====
-------------------------------------------
After the cargo ship deposits its cargo, pirates ships will appear on the scene, possibly warping in. The pirate ships could be a group of ships with a distinct lead ship or a just singular ship, whichever looks and feels cooler. There will then be a view of the pirate ship's bridge, and the pirate captain will command to scan the planet for any signs of their prey. The view will change to a shot of the ship scanning over the surface of the planet.

=====Pirate ship steals cargo=====
------------------------------------------
If the pirate ship locates cargo, the view will change to show the bridge of the pirate ship. The captain will be notified that they've found something and the image of the cargo will come on screen. The captain will say something along the lines of "Arrrr me mateys! We've found some booty." The view will then change to the pirate ship getting the cargo, possibly by tractor beam, and transporting it to a different planet, which needs to be visually distinct from the first planet.

=====Pirate ship doesn't find cargo=====
-------------------------------------------
If the pirate ship fails to detect the cargo, the view will show the bridge and a crew member will inform the captain they haven't found any sign of the cargo ship; the viewport could show a ":(" or a "?". The captain will say something along the lines of "Well they must be farther on." The pirates will then leave the area.

=====Allied cargo ship watches the pirate steal=====
--------------------------------------------------
A shot of the bridge of the allied ship. Maybe some text indicating that they can't be seen by the pirates, or are out of their sensor range. A crew member will let the captain know they are intercepting a signal and will display the pirate ship moving the cargo to the other planet.

=====Allied ship sees static=====

A shot of the bridge of the allied ship. Maybe some text indicating that they can't be seen by the pirates, or are out of their sensor range. A crew member will let the captain know they are intercepting a signal and will display static. Someone will complain that the comm is encrypted and they can't make it out.

==Scoring==

Players will be given a score based on how many messages they steal and how many bonus items they find. This score will determine how much money they get. A player's score will be reduced based on the number of times they were caught.
Players will also be given resources and trade goods for each correct Sally-Anne response.
Players will be given a ranking of sorts, based on their score and responses, that will determine the number of tokens they receive.
Players will always receive at least one of the tokens.

==Development==

[[Milestones]]

Lab Technician How To's

2008-08-25T23:28:30Z

Orosz:

Templates for now. Will add more soon!

=General=
== Change Key Bindings ==

=Maritime Defender=
== Adjust DOT Coherence Test Variables ==

=Stellar Prospector=

=Starjack=

=Colony Sim=

End-user Setup

2008-08-19T20:09:53Z

Belmonte: added details on where to find individual users' experiment logs

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 or Vim. 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 (*/).

===Lab, Home and Debug configurations===

The only difference between the lab and the home versions of the game is the config file that is used. The program will automatically use the LabConfig.script file if it exists; otherwise it will use Config.script. To run the program in the lab, simply make certain that the LabConfig.script file is present.

(When the game is being run from within the debugger, a third configuration script, DebugConfig.script, is used.)

These config files will be found in "[Game Install Directory]\Configs\" (Default: "C:\Program Files\Autism Collaborative\Configs\")

See also: [[Differences in Home vs Lab Configuration]]

===Location===

[Installation Directory]\Configs\Config.script (Default: "C:\Program Files\Autism Collaborative\Configs\")

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 called 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.UseFlickering = true;
* Determines whether or not to use flickering

StellarProspector.Settings.AutoCalculateFlickering = true;
* Whether the frames on/off and intensities of the flickering effect are automatically calculated by the frequency or are just taken from the manually set values.

StellarProspector.Settings.CenterHertz = 6.67;
* The rate at which the center sector flickers per second

StellarProspector.Settings.CenterOnFrames = 4;
* How many frames (out of 60 frames per second) in a row does the center sector remain flickered on

StellarProspector.Settings.CenterOffFrames = 5;
* How many frames (out of 60 frames per second) in a row does the center sector remain flickered off

StellarProspector.Settings.CenterIntensity = 1.25;
* The percentage of intensity of the center sector when it is flickered on. 1.0 denotes 100% intensity.

StellarProspector.Settings.Sector1Hertz = 8.57;
* The rate at which sector one flickers per second

StellarProspector.Settings.Sector1OnFrames = 3;
* How many frames (out of 60 frames per second) in a row does sector one remain flickered on

StellarProspector.Settings.Sector1OffFrames = 4;
* How many frames (out of 60 frames per second) in a row does sector one remain flickered off

StellarProspector.Settings.Sector1Intensity = 1.33;
* The percentage of intensity of sector one when it is flickered on. 1.0 denotes 100% intensity.

StellarProspector.Settings.Sector2Hertz = 10;
* The rate at which sector two flickers per second

StellarProspector.Settings.Sector2OnFrames = 3;
* How many frames (out of 60 frames per second) in a row does sector two remain flickered on

StellarProspector.Settings.Sector2OffFrames = 3;
* How many frames (out of 60 frames per second) in a row does sector two remain flickered off

StellarProspector.Settings.Sector2Intensity = 1.0;
* The percentage of intensity of sector two when it is flickered on. 1.0 denotes 100% intensity.

StellarProspector.Settings.Sector3Hertz = 12;
* The rate at which sector three flickers per second

StellarProspector.Settings.Sector3OnFrames = 2;
* How many frames (out of 60 frames per second) in a row does sector three remain flickered on

StellarProspector.Settings.Sector3OffFrames = 3;
* How many frames (out of 60 frames per second) in a row does sector three remain flickered off

StellarProspector.Settings.Sector3Intensity = 1.5;
* The percentage of intensity of sector three when it is flickered on. 1.0 denotes 100% intensity.

StellarProspector.Settings.Sector4Hertz = 15;
* The rate at which sector four flickers per second

StellarProspector.Settings.Sector4OnFrames = 2;
* How many frames (out of 60 frames per second) in a row does sector four remain flickered on

StellarProspector.Settings.Sector4OffFrames = 2;
* How many frames (out of 60 frames per second) in a row does sector four remain flickered off

StellarProspector.Settings.Sector4Intensity = 1.0;
* The percentage of intensity of sector four when it is flickered on. 1.0 denotes 100% intensity.

===Audio Stimuli Experiment===

Tones will played at intervals based on the sound delay (AS_SOUND_DELAY) and max jitter (AS_MAX_JITTER) as specified in the config file, in floating-point units of seconds. The stimulus onset asynchrony between tones is calculated by adding AS_SOUND_DELAY to a random number in the range of 0 to AS_MAX_JITTER. The tone is the same each time, but the volume is chosen at random from the volumes specifiend in the config file.

Volumes are in arbitrary units on a linear (not dB) scale between 0 and 1.0. Experimenters should calibrate these units using a sound level meter to measure actual volumes in dB SPL produced by their sound card and speaker system, and modify AS_VOLUME1, AS_VOLUME2, AS_VOLUME3 and AS_VOLUME4 so that they produce the desired levels.

Each time a tone is played, an event is written to the log. See the next section for all possible event codes and formats.

Event Codes

AS_START

AS_TONE_PLAYED Volume=[volume] Tone=[tone # refers to the number n in the AS_VOLUMEn parameter]

AS_END

Config File Format

AS_SOUND_DELAY = [stimulus onset asynchrony, in seconds]

AS_MAX_JITTER = [maximum range of random jitter added AS_SOUND_DELAY]

AS_MAX_PLAYS = [total number of times that each tones is played]

AS_VOLUME1 = [volume]

AS_VOLUME2 = [volume]

AS_VOLUME3 = [volume]

AS_VOLUME4 = [volume]

AS_SOUND = [80dBl_Right or 80dBlLeft]

Important Notes:

- All spaces in the config file are necessary for the program to parse

- Make sure there is no white space after the final line

- all volumes must be expressed in double format (must include decimal, ex. 1.0 is correct, 1 is not)

==Keyboard Configuration==

Keyboard bindings are stored in a separate file, also specific to each minigame. For example, the keyboard bindings for the ColonySim could be found at [Installation Directory]\testkeybindings.txt (Default: "C:\Program Files\Autism Collaborative\testkeybindings.txt"). 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\

Although it may seem natural to look in the "LogFiles" directory, the user-specific log file containing each individual's log data is instead found in each individual user's subdirectory within the "Users" directory:

Users\[AstropolisUserName]\LogFiles\ExperimentLog.txt

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

If the computer has a parallel port, the 8-bit numeric event codes in the log file are also placed on the parallel port as 5ms pulses (bounded by 5ms of zeroes on all eight data lines). Codes then can be read from a physiological or behavioural data recorder such as an EEG recorder, an MRI scanner, or a gaze tracker, and the full record from the log file can be synchronised to the event-code sequence in the data recorder, allowing examination of physiological or behavioural events as a function of stimuli and responses that occur during game play. The parallel port is used in compatibility mode only; enhanced mode is not used.

Stellar Prospector

2008-08-13T15:53:14Z

Belmonte: updated this description to reflect design changes and specifications made during implementation of Stellar Prospector

==Summary==

Tests focus on the Posner paradigm, distribution and shifting of attention, and the effect of multimodal (auditory and visual) stimuli.

==Premise==

The colony is in need of raw material resources. You are in control of the colony's Resource Gatherer. Use its tractor beam to collect as many resources as possible.

==Objective==

Collect as many resources as possible. Discard bad resources when they are detected.

==Characters==

Resource (Target Peripheral Stimulus):

[[Image:ComingSoon.png]]

(Various Peripheral Distractor Stimuli):

[[Image:ComingSoon.png]]

==Specifications==

The game screen is a semi-circle divided into a central (d1) sector, an intermediate (d2) arc, and 4 peripheral (d3) sectors.

[[Image:diagram.png|600 px]]

===Central Stimulus===

Sector d1 fills the player's visual field (1.78 degrees at a 50 cm viewing distance is 15.5 mm). This sector corresponds to all of the resources that have been gathered. It flickers at a rate of 10 frames per second. Every so often (about 20%), rather than having a peripheral stimulus appear, described further down, this central stimulus will turn from green to red. This will cue the player to press a key that correspond to the central stimulus to "fix the system" by getting rid of the bad iron, turning the central stimulus back to green.

===Energy Indicator===

The d2 region displays the current energy level of the resource gatherer. When the energy reaches the indicator's maximum level, the mini-game is complete.

===Resource Detection System===

One of the d3 sectors will always be outlined in red to signify an approaching resource. This resource detection system is fallible: 20% of the time, it cues an incorrect sector.

This aspect of the task implements a variation of the Posner attention paradigm (testing effects of cue validity and cue-target onset asynchrony) (Posner et al. 1987).

===Peripheral Stimulus===

The d3 sectors are monitors of outer space.
(The diameter of sector d3 is currently equal to the width of the game screen - 800 pixels in the demo.)

Following the resource detection cue, a resource will appear in one of the d3 sectors.

The resource will slowly lose point value over time, disappearing over the duration of 6000 ms. A subtle particle effect will convey the resource as disintegrating.

===Flashing===

Each of the four sectors and the centre flash at one of five distinct frequencies. This flashing drives the visual system in the brain to resonance, just as any RC or LC electrical system can be driven to resonance by a periodic impulse at or near its resonant frequency. So flashing these five distinct areas of the display at five distinct frequencies will give five peaks in the spectrogram of the EEG recording. Attention modulates the amplitudes of these resonances - so for example if region A is flashing at 12 hz and region B is at 8.57 hz, when attention shifts from A to B we'll see the 12 hz spectral peak decrease and the 8.57 hz peak increase.

Different flash rates can be implemented by drawing and clearing the flashing stimulus for various numbers of frames when the display is operating at a known, constant frame rate. Differences in overall luminance integrated over time will arise from slightly unequal duty cycles when the number of frames is odd; these luminance differences can be compensated for by altering the intensity of the stimulus. For example, a frame rate of 60 hz would allow the following flicker frequencies:

{| class="wikitable" cellpadding="2"
|-
! frequency
! total frames
! frames on
! frames off
! intensity
|-
| 15 hz
| 4
| 2
| 2
| 100%
|-
| 12 hz
| 5
| 2
| 3
| 150%
|-
| 10 hz
| 6
| 3
| 3
| 100%
|-
| 8.57 hz
| 7
| 3
| 4
| 133%
|-
| 6.67 hz
| 9
| 4
| 5
| 125%
|}

These frequencies should be in the range 7 to 18 hz, approximately, and should be far enough away from each other to give distinct peaks in the spectrogram. (Notice that in the example above I've skipped the 8-frame cycle since its 7.5 hz frequency gets a bit too close to the neighbouring 8.57 hz and 6.67 hz frequencies.) In order to avoid contamination of one measurement with another, it is crucial that these flash frequencies not be harmonics of each other.

==Gameplay==

The player is inside the control room of the colony's resource gatherer.

There are two main tasks for the player:

1 - The player must respond, by pressing the Down arrow, when a bad resource is detected and displayed by the control panel.

2 - The player must respond, by pressing the Up arrow, when ore appears in any of the d3 sectors.

==Phases==

The peripheral task runs in three phases:

Phase 1: 100% of the stimuli appearing in the sectors are targets.

Phase 2: The same targets appear, but they are interspersed in time and
space with many distractors (however many make the game feel right).
Distractors are equally salient as targets, but distinguishable.

Phase 3: Same as Phase 2 but targets are paired with an alerting sound that is played whenever the detection cue in the d2 sector changes.

==Scoring==

Cash is awarded for each resource collected. (The cash values will be determined along with the Colony Simulator design)

[[Category:Mini Games]]

Art Assets and Tracking

2008-08-04T19:48:06Z

Belmonte:

== 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 u pallet something like Age of Empires III, bright base colours with tasteful splashes of colour 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 from the SketchUp file then they will also need to be included as *.png files. Textures' dimensions should be powers of two (2x2,4x4,16x16,32x32,64x64, etc.) and should be kept as small as reasonably possible.

===Submission===
Models will be uploaded to the Google 3D 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 Centre
| 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
| Brendan - Complete
|
| 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
| Brendan - Complete
| Tier 1 Complete
| High
|-
| High Quality Residential Building
| This is the high quality living quarters of the colony. Its focus is the comfort the people 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
| Brendan - Complete
| Tier 1 Complete
| 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
| Jordan - Complete
|
| 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
| Brendan / bMurph (Particles)
| All Three Complete
| Low
|-
| Commercial Buildings
| These are buildings to which the populace will travel 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 exist three of these buildings in tier 1 and three of these buildings in tier 2.
| 2 x 2
| Project Spectrum
| Preparing Concept Art
| 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
| Brendan (Refinery) - Complete
| One remaining tier 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
| Jordan
| del 12/16
| High
|-
| Resource Transport Rings
| A series of rings through which the transport ships will pass. These ships will move resources throughout the colony. Models will be needed for straight sections, elbow joints, T joints, and four-way intersections.
| 1 x 1
| Brendan - Complete
|
| High
|-
| Resource Transport Ship
| The ship that carries resources from one building to another through the tubes. Different models for each resource would be nice, though a simple colour swap would be just as effective.
| 1 x 1
| Jordan - Complete
|
| Medium
|-
| Space "Roads"
| This is the transport system for the populace. This moves people around the colony. The term road is used loosely since a system of transparent tubes would work just as well. Models needed would be 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
| Brendan - Complete
|
| 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
| Jordan - Complete
|
| 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. They 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
|}

*Note: On internal areas that are meant to be seen, such as transparent domes, be sure to create back faces for the internal sections; otherwise culling will prevent them from being seen.

=== Textures ===

=== Sounds ===

== Maritime Defender ==

=== Models ===

=== Textures ===

=== Sounds ===

== Starjack ==

=== Models ===

=== Textures ===

=== Sounds ===

== Stellar Prospector ==

=== Models ===

=== Textures ===

=== Sounds ===

System Specifications and Testing

2008-08-04T15:58:12Z

Belmonte: updated Thinkpad T43 versus T43p

== 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 ==
<table border="1">


<tr><th colspan="5">FULLY FUNCTIONAL</th></tr>

<tr><th>Model</th><th>System</th><th>Processor</th><th>Graphics</th><th>RAM</th></tr>

<tr><td>Mac Pro 3,1</td><td>Windows XP SP2</td><td>dual Quad-Core Intel Xeon, 2.8 GHz</td><td>nVidia GeForce 8800 GT</td><td>32 GB</td></tr>

<tr><td>Dell Inspiron 1720</td><td>Windows XP SP2</td><td>Intel Core 2 Duo, 2 GHz</td><td>nVidia GeForce 8600M GT</td><td>2 GB</td></tr>

<tr><td>Dell Inspiron 1720</td><td>Windows Vista Ultimate</td><td>Intel Core 2 Duo, 2 GHz</td><td>nVidia GeForce 8600M GT</td><td>2 GB</td></tr>

<tr><td>Lenovo Thinkpad T61p</td><td>Windows XP SP2</td><td>Intel Core 2 Duo T7500, 2.2 GHz</td><td>nVidia Quadro FX 570M</td><td>2 GB</td></tr>

<tr><td>IBM Thinkpad T43p</td><td>Windows XP SP2</td><td>Intel Pentium-M, 2 GHz</td><td>ATI Mobility FIRE GL V3200</td><td>128 MB</td></tr>

<tr><th colspan="5">SLOW</th></tr>

<tr><th>Model</th><th>System</th><th>Processor</th><th>Graphics</th><th>RAM</th></tr>

<tr><td>Dell Inspiron e1505</td><td>Windows XP SP2</td><td>Intel Core 2 Duo, 1.83 GHz</td><td>ATI Mobility Radeon X1400</td><td>2 GB</td></tr>

<tr><td>MacBook Air 1,1</td><td>Windows XP SP2</td><td>Intel Core 2 Duo, 1.6 GHz</td><td>Intel GMA X3100 integrated graphics</td><td>2 GB</td></tr>

<tr><th colspan="5">NOT FUNCTIONAL</th></tr>

<tr><th>Model</th><th>System</th><th>Processor</th><th>Graphics</th><th>RAM</th></tr>

<tr><td>IBM Thinkpad T43</td><td>Windows XP SP2</td><td>Intel Pentium-M, 2 GHz</td><td>ATI Mobility Radeon X300</td><td>64 MB</td></tr>

<tr><td>IBM Thinkpad T41</td><td colspan="2"></td><td>ATI Mobility Radeon 7500</td><td></td></tr>

</table>

Event Codes

2008-06-18T18:46:07Z

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.

Concept Art

2008-06-18T14:13:27Z

Belmonte: updated links to most recent game documents (Starjack not Hacker Havoc, and Stellar Prospector not Spaceship Shenanigans)

==Starjack==

In [[Star Jack]], a secret agent has been sent to infiltrate the spy satellites of the space pirates who have been harassing our cargo lines and stealing our resources. The goal is to sneak to the various comm stations that contain the pirates communication logs, hack them, and find the location of the stolen cargo.

===Main Character===
The player will control a top secret agent infiltrating pirate spy satellites. The agent has at his disposal a collection of cool equipment: cloaking fields, hacking tools and various less then lethal traps that will let him sneak undetected. The current idea is to have our agent decked out splinter cell style all in black. The cloaking device will be integrated into the suit, and his traps resemble those from Golden Eye.

What we need art-wise is pictures of the agent and his gear: shots of the agent in action sneaking about, full body shots that detail where the tools are stored and what other technologies are integrated into the suit, sketches of traps and what they do.

===Locations===
To find the whereabouts of the cargo ships the player will have to infiltrate spy satellites. These satellites are controlled by differing factions of space pirates. We are planning three different factions: Humans, Aliens and Robots.

We need art representing the various satellites. This would include both the interior and exterior of the station.

===Enemies===
To make a stealth game fun one needs things to avoid and to hide from. We need some concept art for different guards, sentry equipment and obstacles that the player must avoid to reach each comm station. These should relate to one of the pirate factions.

===Stealth Fighter===
To get to the satellites undetected the player will use the Bobcat B-3 Interceptor. This is a small, one-person long-range fighter. It is equipped with the best cloaking, stealth technologies, and hyperspace technologies. We need some schematic sketches and payload details for this ship.

===Pirate Ships===
The evil pirates have stolen our cargo! We need ship information and ideas for the various factions. This would include weapon details, propulsion systems, and hulls that fit within the different factions.

===Contact Info===
If anyone wants or needs anything clarified or wants some more info on Starjack please let me know. You can contact me, Karl Orosz, at kao7002 at rit dot edu.

===Submission Information===
Google Sketchup Pro or jped/png file formats.

==Stellar Prospector==

In [[Stellar Prospector]], the player controls the colony's resource gatherer. The goal is to collect as many resources as possible and to discharge bad resources.

===1 - Resource===

Some type of asteroid chunk with minerals and/or metals sticking out of it. It should contrast against black.

Pixels: 64x64

===2 - Space Debris===

Pieces of rusty scrap metal, similar in size to the resource. The look of this should contrast the resource. Three to four variations on this.

Pixels: 64x64

===3 - Decayed Resource===

Similar to the resource, but with a decayed/brittle look.

Pixels: 64x64

===4 - Overhead Interior===

This is inside the spaceship. It can look similar to a cockpit. Low contrast with grayish and simple/bland colors.

Pixels: 800x400

===5 - Control Panel===

This is inside the spaceship. Looks similar to the overhead interior, but with more colors - more eye-catching. In order to display the decayed ore, a TV monitor/terminal should be embedded in it.

Pixels: 176x88

===6 - Resource Detection System===

This is inside the spaceship - the area surrounding the control panel. It is divided into four sections across 180 degrees. The middle of each section should be empty (0 alpha). It should match with the control panel, and can actually be combined with the control panel image. (Think of these as window frames)

Pixels: 226x110

===7 - Window Frames===

The windows simply need frames, similar to the resource detection system but thinner.

Pixels: 800x400

[[Image:SS_ConceptArtReference.jpg]]

Mini Game Scenarios

2008-06-17T23:51:17Z

Mcd8604:

==Scenarios==
<table style="border: solid;">
<tr><th>Inside Colony</th><th>Both</th><th>Outside Colony</th></tr>
<tr><td>Medicine/Hospital</td><td>Resource Gathering/Mining</td><td>Navigation</td></tr>
<tr><td>Research/Edumacation/Monkey Test Labs</td><td>Repairs Planets</td></tr>
<tr><td>Farms/Agriculture</td><td>Asteroids</td><td>Meteors/Comets</td></tr>
<tr><td>Factories/Industry</td><td>Aliens/ETs/space pirates/ninjas</td><td>Black Holes</td></tr>
<tr><td>Power</td><td>Plants</td><td>Gravity</td></tr>
<tr><td>Leisure/Recreation</td><td>Space Fishing</td></tr>
<tr><td>Construction/Architecture</td><td>Refueling</td></tr>
</table>

==Mini-game Ideas==
*Successfully completing a mini-game can upgrade or improve efficiency of a building or technology.
===Medicine===
*Mixing/Alchemy/Pharmacy/Herbology
*Repairing an arm/Operating room
===Research/Education===
*Trick question game (test for literal interpretation?)
*Memory games
===Farm/Agriculture===
*Farm simulation
*Harvesting game – picking ripe foods (symbolic cue)
*Livestock Breeding / Crossbreeding (like chocobos)
===Factory/Industry===
*Factory frenzy
*Quality assurance – item inspection
**Circuit boards / electronics
**Toys
**Spaceships
*Assembly Line / Building product
===Power Plant===
*Solar panel construction (like Tetris)
===Leisure===
*Theme park
*Carnival games
**Ring toss
**Water guns
**Duck slinger
**Baseball throw
**Catching goldfish
===Construction/Architecture===
*Lego style – replicating things
*Finding flaws in blueprints (similar to quality assurance)
*Making cement
*Terrain (de)formation
*Sims type of house creation
===Resource Gathering/Mining===
*Puzzle style – like columns
*Breakout
*Picture finding (Where’s Waldo)
*Detecting and collecting asteroids
===Repairs===
*Tetris type game, carpentry
*Glass crack repair
*Electric repair
**mess of wires, line up and connect the correct ones
===Navigation===
*Forced scrolling
**clear a path through asteroid belt
**dodging asteroids – like Battletoads, show blinking alert, move left or right
*Mazes
*Sound / sonar
===Aliens, etc..===
*Defense game (Spaceship Shenanigans)
*Diplomacy
===Gravity===
*Inside core of colony – physics puzzles to fix gravity
*(use (planetary) gravity in navigation)
===Refueling===
*Line up the fuel pump with the ship - precision flying
*Pipe organizing

Milestones

2008-06-09T19:38:44Z

Orosz:

Sprint 1:
* Implement basic structure of Dungeon game.
[x]Loading XML data
[x]converting XML data to load level
[x]Basic update structure
[x]Data structures of the levels
[x]Input
[x]Game Flow
[x]Collision
[X]Implement Menus
[]Difficulty
[x]Game play programming

Sprint 2:
* Implement more complex Dungeon game functions
[x]Traps/Enemies
[X]Stealth bar
[x]Player abilities
[x]AI Logic
[X]placeholder UI

Sprint 3:
* Implement Hacking Phase, aka Embedded Figures test
[x]Create hackable objects
[x]Placeholder graphics for hacking phase
[X]Logging
[x]integrate into level

Sprint 4:
* Implement Sally Anne
[X]Implement first theory of mind question
[X]implement 2nd theory of mind question
[x]Tie into level progression
[X]Logging

Sprint 5:
* Implement Rewards
[]Implement a system for rewarding the player
[]calculate total rewards based of performance in mini game
[]tie to colony simulator
* Tutorial
[]yep
* Implement easy access trial modifiers to mini game menu

Sprint 6:
* Implement Map Editor
[X]Read/Write/edit XML data containing tileset information for world/level/room

Sprint 7:
* Implement Player Profiles
[X]Keep track of missions played/progression made

Sprint 8:
* Create new levels and obstacles.

Tasks

2008-06-02T15:00:14Z

Belmonte:

These are the tasks that still need to be completed for the Colony Simulator

* UI
o Details: Design and implement the UI interface and all the menus for the colony simulator.
o Assigned to:

* Gameplay programming/object interaction (big broad topic!)
o Details: This will probably be divided into many smaller categories. General gameplay elements. Factions, building interactions and the like.
o Assigned to:

* Delete Objects
o Details: Select and destroy buildings.
o Assigned to:

* Time
o Details: Design and implement a real-time turn based timing system.
o Assigned to:

* Economy
o Details: Design and implement resources and monies. Balance out supply and demand issues.
o Assigned to:

* Game Flow
o Details:
o Assigned to:

* Level loading
o Details: Load a player's colony sim from an xml file.
o Assigned to:

* Saving
o Details: Save a player's colony information to an xml file
o Assigned to:

* Transition between minigames and main game
o Details: Decide how players will transit between the colony sim and the minigames. Design and implement UI elements for this system.
o Assigned to:

* Main Menu
o Details: Create all the menus and transitions.
o Assigned to:

* Finish Art
o Details: Either August or a new artist will finish this.
o Assigned to:

* Settings/System Options
o Details: Enable, save and restore System settings. Saved in an xml file. Could be tied to user profiles.
o Assigned to:

* User Profiles
o Details: Enable, save, restore User profiles. Profiles will be saved as XML files. These will be for player information and not contain colony sim information.
o Assigned to:

Mini Game Rewards

2008-05-07T16:28:27Z

Belmonte:

One of the goals of this project is to motivate the players to want to complete and do successful in the psychological tests. To accomplish this, players will receive rewards from playing mini-games, which will allow them to build and to improve their colony.

==Rewards==
Rewards will be given in the form of Money, Resources, Buildings, Technologies and Tokens. Not all mini-games will give the same rewards.

===Money===
Money is used in the construction of every building. Completing mini-games will be the main and possibly only source of income for players. All mini-games will give the player some amount of money based on their performance. Some mini-games will reward the player with bonus money for completing bonus objectives not directly related to the tests. One such bonus objective arises in Maritime Defender where the player can gain money by destroying asteroids.

===Resources===
Some mini-games will reward the player with resources. These resources will be used to construct buildings in the Colony Simulator. Resources will be specific to a mini-game. These will mostly be common resources, but there may be a few mini-game-only resources that cannot be accumulated in the colony mode.

===Buildings===
If a player does especially well or completes a series of tasks within a mini-game, they could be rewarded with a building. These buildings will be special to the mini-game and will provide unique bonuses. Players will be able to build only one of these buildings each time they earn the reward. These buildings will be faction neutral.

===Technologies===
These will be very rare rewards. They will give the player a permanent technology bonus. These technologies will be unique and add flavour to a colony, but will not be overly important. They will be the cool technologies.

===Tokens===
Tokens will be given to a player each time they play a mini-game. Players will always receive at least one token each time they play a mini-game, but will receive many more for successfully completing a mini-game. Each mini-game will have its own token. These tokens will represent objects that can be used to trade with Interstellar Merchants. The items offered by each Merchant will be powerful, and exclusive to that merchant's shop. It is hoped that setting proper token requirements on items will encourage players to play all the mini-games.

This is similar to World of Warcraft's mark of honour Player Versus Player reward system.

Factions

2008-05-07T15:42:57Z

Belmonte:

Note: Implementation of Factions is not planned for the first version of Colony Sim. Factions may be added at a later date.

Factions

Factions will represent different paths of development that a player can choose. Players will be able to play any faction they like, and will not have to choose on exclusively. Colonies can be all one faction, or they can be blends of multiple factions.

Factions would represent races (humans, robots, aliens), corporations (each corporation has its own area of expertise), or groups of people (much like countries or political parties). Each faction will be distinct! This will be done by playing off popular archetypes that autistic players will have an easy time identifying. Giving each faction a distinct colour, unique symbols, and keeping buildings with the same style would be a good way to accomplish this. Players will have a rating with each faction.

Example: The Tree Hugger Collective's buildings and research a geared towards a more eco-friendly colony, whereas Unchained Autonomous buildings focus more on an industrial look and make robots.

Buildings, units and technologies will be associated with different factions. Creating buildings that belong to a specific faction will increase the player's faction rating for that faction. New buildings and units will be available to the player based on the player's faction rating. Some buildings may give bonuses to some factions and/or penalties to others.

For example, the player would like to build a tree skyscraper. However the Skyscraper requires trees and a rating of 60 with the Tree Hugger Collective (THC) neither of which the player has. The player can build Tree Farms though, which produce trees and give a THC rating. The player builds 20 of these farms, granting him enough faction and wood to make the skyscraper.

If a player destroys a building they will lose the faction bonus associated with it. We could implement a level system, where once a player achieves a level that gain is permanent, but their faction could still change. Levels could override a faction requirement. Some buildings would not have a level option and would require a high faction. Once a building is built it will never need to check the players faction rating again.

Example: Jimmy has spent a lot of time making tree farms and skyscrapers. In doing so he has reached 1000 faction rating and advances to level 2 with the Tree Hugger Collective. However Jimmy decides that he doesn't want his tree farms anymore and decides to destroy all of them and replace them with "Unchained Autonomous" robot factories. His rating with THC drops to 25 as a result. Jimmy likes the idea of his robots living in tree sky scrapers, but needs to build more skyscrapers for his colony's people. Since he has a level 2 faction rating with THC and the tree skyscraper requires 60 Faction OR Level 2 he can still build more sky scrapers for his robots to live happily in.

In this example I used level N to indicate the faction level. This could easily be assigned something more visually identifiable. Maybe a military rank or something else that use insignias. The player's current level would be shown at all times beside the Faction Bar.

Detailed faction information can be viewed from its own window in the game. On the game screen the Faction could be shown as an level up bar coloured with the faction's predominant colour. The faction rating will be displayed in the centre of the bar. The bar will indicate how much more faction score the player needs in order to achieve the next level with that faction.

TODO List

2008-02-11T15:36:22Z

Zinsser:

This is the communal TODO list. Use it to store tasks that will be done several weeks from now or have no particular dev assigned to them. This is obviously not a complete list, but should contain all of the major tasks that are planned, but are not currently being worked on.

==Tier I (must eventually be implemented)==

* Add the appropriate copyright information (see GNU public license) to each file and a file in the build with the copyright info
* Make fonts resolution dependent. Right now their physical size is in pixels so their display size changes as resolution changes.
* Implement some form Jump/Goto in the ScriptManager Lua Interpreter.
** Change all the tutorials to allow the user to repeat sections until they are ready to progress
** Implement a "tutorial menu" that allows users to jump to one particular section and then return to the menu. This option should only be available after the tutorial has been played once through.

==Tier II (should eventually be implemented)==

* Load all content in overloads of Microsoft.Xna.Framework.Game.LoadGraphicsContent() and unload them in ...UnloadGraphicsContent()

==Tier III (would be nice to have, but definitely not necessary)==

* Voice overs for dialog

Important Neuroscientific Considerations in Game Design for Autism

2008-01-27T02:44:20Z

Belmonte: added a caution about maximum-likelihood psychophysical threshold estimation

'''Neuroscientific Considerations in Game Design for Autism'''

'''If there's a way to use a game feature as an object of repetitive behaviour, a player with autism will find it..''' Players with autism often find predictable sensory contingencies more rewarding than unpredictable, surprising events. So whereas non-autistic players could be expected to self-motivate to 'level up' or in general to proceed through the game narrative, autistic players often are more content to keep on repeating the same feature, or causing the game to produce the same sound or visual effect. These purely sensory effects can be much more salient and motivating to a person with autism than the less tangible and immediate, more abstract and future-oriented effect of, say, a game score or a power-up. So, for instance, an autistic player might become fascinated with the sound effect that takes place when their avatar is destroyed, and therefore keep 'dying' on purpose, just to hear the sound effect - clearly a strategy that thwarts the intended game mechanic! When designing and implementing a game, put yourself in the place of the player with autism, asking yourself, "What sensory aspects of this game could a person become fixated on?" Try to move the player through the game, nudging them away from such repetitive behaviours and into new experiences. At the same time, though, you can use limited, rationed opportunities for repetitive behaviour as a reward and a motivation for moving through the game - e.g. a game structure that allows a player ten (and only ten) repetitions of their favourite sound effect once they've done the hard work of reaching the next level.
 In his memoir There's a Boy in Here, Sean Barron describes his own autistic fascination with repetition and predictability:
 ‘I loved repetition. Every time I turned on a light I knew what would happen. When I flipped the switch, the light went on. It gave me a wonderful feeling of security because it was the same each time…. Even when I knew, it was thrilling to do it over and over. It was always the same.'
 ‘People bothered me. I didn’t know what they were for or what they would do to me. They were not always the same and I had no security with them at all….'

'''Avoid timed events; give the player control of when things happen; whenever possible, prompt the player.'''
People with autism have difficulty with executive function, that is, in rapidly planning and executing actions in response to sensory inputs. They have a great deal of skill and often exceed the performance of people without autism -- but it's a intensely studied and considered, deliberate style of skill, often not expressed under time pressure. So it's important to make certain that the timing of events is controlled not by the computer (except in cases where the experiment requires it) but by the player. Small additions such as a "next" button or a "ready" button can make all the difference. (An example of the event-driven rather than time-driven structure is the use of the up-arrow key to connect with the wormhole in the Maritime Defender mini-game.)

'''Do not depend on a player's memory for instructions; prompt the player every time.'''
A corollary of the executive planning problem is that the player may have trouble remembering a sequence of steps. Even if (s)he has learnt in a tutorial that key A triggers action X and key B triggers action Y, these arbitrary associations might not be remembered, unless the player has had a chance to practise these actions actively, many times over.

Another corollary of this memory problem: '''Do not make input-output mappings depend on the game state.''' You might be tempted to hide functions inside submenus, access to which depends on the player's clicking on the right primary menu, or to make a drag of the mouse do something different after a click than after no click (or even worse, something different after a left-click than after a right-click). Avoid such sequential logic in the user interface. Wherever possible, use purely combinational logic. Some sequential logic is of course unavoidable -- otherwise we wouldn't be able to have separate mini-games! -- but it ought to be used sparingly and only when absolutely required.

Maintain a consistent mapping between user inputs and game functionality; eschew a confusing multiplicity of modes. People with autism work best with predictable relationships between action and reaction, that do not change. A large number of game modes can overtax a player's short-term memory: What does this button do at this moment?" On this screen should I speak my answer, or type it? Instead of trying to make the game do everything, by partitioning it into many modes, try insofar as is possible to flatten the design so that all functions and modalities appear side by side and simultaneously -- so that it's up to the player, rather than the computer, at any given juncture to choose how to play. For instance, in a game in which input can be manual or vocal, do not separate these two input modalities into different game phases. Instead, accept both input modalities on one and the same game screen.

'''Instead of a sequence of actions, ask for one action at a time.'''
Rapid actions can be difficult enough by themselves, but when people with autism face the additional demand of performing several of these actions rapidly and in the proper sequence thay can feel very much overwhelmed. (See the previous entries on executive function and memory.) Instead of requiring sequences of inputs in response to a single prompt, try to prompt separately for each input.

'''Use pictures, not words.'''
Most people with autism tend to think in pictures rather than words. Instructions presented as text might not be comprehended -- not because the player is incapable of comprehending but because (s)he's concentrating so much on decoding the individual words that (s)he can't spare much effort to put those words together into the meanings of complete sentences and narratives. Sometimes text is unavoidable; if text is used, avoid verbosity and don't clutter the display with words. Reading can be slow; see the entry on ''timed events'' above about waiting and prompting the player to continue.

When designing game player avatars and non-player characters for children, be aware that the '''anthropomorphised "cute" creatures that work with non-autistic children actually are something of a turn-off for autistic children.''' People with autism are stringently matter-of-fact as to what is real and what isn't. Imagine your player thinking, "Look, I know that caterpillars don't have human faces and don't smile, so why is this game treating me as though I could believe that they do? Why are you treating me as someone who could be so stupid, so childish?" Mechanical stimuli such as trains, gears, etc., work much more effectively. An anecdote might best illustrate this phenomenon: when my autistic niece was about five years old, my sister, sitting with her on a park bench, tried to dispel the boredom by playing a pretend game with her, saying, "Oh the house is on fire; let's get the fire engines!" In reality, of course, there was no house, there was no fire, there was only a park bench, and my niece gazed quizzically at my sister as if to say, "What, mum, what kind of an idiot are you?" Anthropomorphic animals and other counterfactual, imaginary stimuli tend to turn off people with autism.

'''Players should learn by doing, not just by observing or reading or listening.'''
In this regard, people with autism are no different from people without autism: we all learn best when we can be active rather than passive learners. The challenges faced by people with autism make it even more crucial that game activities involve learning-by-doing, rather than depending on learning-by-reading or learning-by-listening. This is particularly true of the game tutorials.

'''Avoid depending on simultaneous or near-simultaneous events in different perceptual channels (e.g. different places on the screen, or different senses such as video with audio).'''
People with autism focus intensely and exclusively on one perceptual channel at a time. When focusing on one point or area of the display, events away from this spatial focus of attention may not register. Anathema for a person with autism would be a cockpit display with many gauges indicating different quantities which all need to be observed simultaneously -- or a visual display that needs to be observed at the same time as a spoken or other auditory signal. (Background music is okay because it doesn't need to be attended; players can just let it go on whilst they focus on the visual display.) Instead, either information should be displayed in one region of the display or one sensory channel, or ample time should be allowed to shift attention between points in visual space or between sensory channels. Shifts of attention can take 2 to 3 seconds for people with autism, whereas people without autism take 0.2 to 0.3 seconds. Think about what it would be like to be looking at the display through a long telescope that magnifies a small area but shuts out the periphery.

'''Avoid evoking unnecessary anxiety.'''
People with autism are '''much''' more prone to anxiety than people without autism -- especially when faced with a new and unpractised task, or with a timed task, or with an interactive situation that's out of their control. (See entries above on avoiding timed events and giving prompting, pictures, and practice.) Do everything possible to make certain that the player, not the computer, is the one controlling what happens next, and that the player has every opportunity to practise and to become comfortable with the demands of the game.

'''For repeating events, vary the timing slightly so that the time between two successive instances of the event is not constant.'''
This consideration actually isn't about accommodating people with autism; rather, it's about accommodating EEG analysis. Those of you who know something about signal processing will be familiar with the phenomenon of '''aliasing''' in which a discrete sampling of a high-frequency signal at too low a sampling rate produces an artefactual low-frequency oscillation. The problem here has a lot in common with aliasing. Consider as an example the situation that exists when the firing button is pressed and held: the weapons will fire at a certain rate, say, once every 500 ms. Suppose that we're interested in the brain response to the combined auditory and visual effects associated with weapons firing. Suppose also, though, that there is an ongoing, endogenous (that is, internally driven) 10 hz oscillation in the player's brain that has nothing to do with these exogenous stimuli. Since 500 ms is an integral multiple of the 100 ms period of this oscillation, when we sample the exogenous brain response to each weapons firing we're going to end up also sampling the endogenous oscillation at the same point in its phase every time, and we will thus misattribute the endogenous signal as an exogenous response to the weapons firing. To forestall this ambiguity in EEG analysis, we can add a small amount of temporal jitter to the intervals between firings - not so much as to make them seem unnaturally jittery to the player, but enough to get rid of this phase artefact. The exact amount depends on what seems natural given the event separation; in this example of a 500 ms event we might deem that any variation more than 10% of the interval in either direction would seem unnatural, so we might then choose to vary the intervals over a uniform distribution from 450 ms to 550 ms. Given the frequencies of the signals in which we're interested, it isn't ever necessary to add more than 150 ms (that is, 75 ms in either direction) of temporal jitter. Add as much temporal jitter as you can, up to this 150 ms limit - but don't sacrifice playability.

'''Log event codes for everything - absolutely everything.'''
This is another consideration for EEG analysis. Did the weapons just fire (even though the firing key is being held down constantly)? That's an event. Did some sort of motion start or stop or change speed? That's an event. Absolutely everything that happens in the game should be reported with an event code. (See "Game/Engine/Logger.cs".) We can always ignore event codes if we decide that they aren't of interest in our analysis. What we can't do is go back and insert event codes after the data have been recorded. So put everything in.

'''DO NOT use a maximum-likelihood method when estimating psychophysical thresholds.'''
Although Pentland's "Best PEST" maximum-likelihood statistical estimator is theoretically optimal, it assumes that a human is an invariant system, one whose attention never wanders, one who never is distracted or bored, one who never blinks at a crucial moment. Psychophysical estimators in general also assume that s subject's missing a stimulus is as informative and beneficial as detecting a stimulus - and the maximum-likelihood method amplifies this shortcoming by converging not on a 75%- or 80%-correct threshold but on the 50% point. At the 50% point, the slope of the psychometric function is maximal and there is a fine line between successful and unsuccessful detection. It is therefore at this 50% point that estimated thresholds are most prone to error, and experimental subjects cum game players most prone to frustration. In a game context, these properties make for a boring game. Because the maximum-likelihood method considers all stimuli ever presented to the subject, the level of difficulty in detection will not adapt much to shorter-term trends in the subject's acuity. This lack of adaptation to changes in the subject's acuity can make for a frustrating game sequence in which all or nearly all stimuli go undetected, placing the player in a situation where it seems impossible to succeed. Even the best of circumstances, a game in which fully half of the trials are missed can likewise become very boring very quickly. To avoid such pitfalls, we recommend eschewing maximum-likelihood "Best PEST" and Bayesian QUEST algorithms, and instead hewing to a more traditional adaptive-staircase procedure such as described by Garcia-Perez (1998):
http://dx.doi.org/10.1016/S0042-6989(97)00340-4

'''SEE ALSO'''

http://www.gamasutra.com/view/feature/3538/designing_games_that_are_.php

"Designing Games that are Accessible to Everyone" by Eitan Glinert

Meetings

2008-01-14T14:52:39Z

Belmonte: updated meeting details from old Skype to new Ventrilo

With the expansion of the development team we have moved from Skype to Ventrilo for our weekly meetings. In order to accommodate August and Brendan on the West Coast as well as developers in Rochester and Ithaca, the usual meeting time is 9pm Eastern Time. During some weeks this time may be changed; in these instances, notice will be sent to the staff mailing list.

Meetings are held via the Ventrilo server on port '''43503''' of '''chromium.typefrag.com'''. This server is password-protected; members of the development team can obtain the password from Matthew. The Ventrilo client can be downloaded from https://www.typefrag.com/services/downloads/

By 10am on the day of the meeting, each developer should post to the Astropolis forum their Accomplishments since the last meeting and Objectives for the next meeting (A's and O's).