Data analysis - Maritime Defender

From TACWiki
Revision as of 19:55, 19 August 2011 by Belmonte (Talk | contribs) (added a note on handling uncertain time offsets in rapid stimulus series for events 29 and 30)

Jump to: navigation, search

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:

1 MD_DotPhaseBegin The navigation phase (comprising many motion coherence trials) of the game has begun
2 MD_DotTrialBegin One individual motion coherence trial (within the navigation phase) has begun
3 MD_DotTrialExpire A motion coherence trial has timed out without any behavioural response
4 MD_DotTrialUserRespondLeft The player has pressed the left arrow during a motion coherence trial
5 MD_DotTrialUserRespondRight The player has pressed the right arrow during a motion coherence trial
6 MD_DotCoherenceEstimate At the end of a navigation phase, the maximum-likelihood estimator has recalculated the psychophysical perceptual threshold for motion coherence
7 MD_ShipIdentifierTestBegin At the beginning of the game, the friend-or-foe ship identifier dialogue has begun
8 MD_ShipIdentifierSelectLeft During the friend-or-foe ship identifier dialogue, the player has pressed the left arrow
9 MD_ShipIdentifierSelectRight During the friend-or-foe ship identifier dialogue, the player has pressed the right arrow
10 MD_ShipIdentifierConfirmSelection During the friend-or-foe ship identifier dialogue, the player has pressed the return key to confirm their selection
11 MD_ShipIdentifierTestEndSuccess The player's response in the friend-or-foe ship identifier dialogue is correct
12 MD_ShipIdentifierTestEndFailure The player's response in the friend-or-foe ship identifier dialogue is incorrect
13 MD_ShooterPhaseBegin The shooter phase (comprising many go/no-go trials) of the game has begun
14 MD_ShooterActivateOpenWormholeBeam During the shooter phase, the player has depressed the up-arrow to activate the wormhole-opener beam
15 MD_ShooterCeaseOpenWormholeBeam During the shooter phase, the player has released the up-arrow to cease the wormhole-opener beam
16 MD_ShooterOpenWormholeSuccess During the shooter phase, the wormhole-opener beam has opened the wormhole
17 MD_ShooterActivateMovePort During the shooter phase, the player has depressed the left-arrow to begin moving clockwise
18 MD_ShooterCeaseMovePort During the shooter phase, the player has released the left-arrow to cease moving clockwise
19 MD_ShooterActivateMoveStarboard During the shooter phase, the player has depressed the right-arrow key to begin moving anticlockwise
20 MD_ShooterCeaseMoveStarboard During the shooter phase, the player has released the right-arrow key to cease moving anticlockwise
21 MD_ShooterPresentFriendly During the shooter phase, a friendly ship has emerged from an opened wormhole
22 MD_ShooterPresentEnemy During the shooter phase, a hostile ship has emerged from an opened wormhole
23 MD_ShooterPresentWormhole During the shooter phase, a wormhole has appeared
24 MD_ShooterActivateFireWeapon During the shooter phase, the player has depressed the space bar to begin firing
25 MD_ShooterCeaseFireWeapon During the shooter phase, the player has released the space bar to cease firing
26 MD_ShooterPlayerWeaponFired 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)
27 MD_ShooterEnemyWeaponFired During the shooter phase, a hostile ship has fired at the player
28 MD_ShooterCollectibleSpawned During the shooter phase, a collectible has emerged from a destroyed asteroid or from a friendly ship
29 MD_ShooterPlayerCollectibleCollision During the shooter phase, the player's ship has picked up a collectible
30 MD_ShooterMeteorExplosion During the shooter phase, an asteroid has exploded
31 MD_ShooterPlayerGetsHit During the shooter phase, the player's ship has been hit by hostile fire or by an asteroid
32 MD_BossPhaseBegin The 'boss phase' has begun - no scientifically important events here, just entertainment and reward for completing the level
33 MD_GameSuccess The player has successfully completed the boss phase, beating the game
34 MD_GameFailure During any game phase (shooter, navigation, or boss), the player's last of three ships has been destroyed, losing the game
35 MD_DialogSkip The player has skipped a dialogue
36 MD_MenuSelect The player has selected an item in the menu
37 MD_MenuCancel The player has cancelled the menu
38 MD_Pause The player has paused the game
39 MD_Unpause The player has unpaused the game
40 MD_OpenConsole The player has opened the console
41 MD_MaritimeDefenderGameBegin The game has begun
42 MD_CockpitDamageFeedback During the navigation phase, the cockpit shakes, indicating damage and loss of energy, following a non-response or an incorrect response
43 MD_TutorialStart The optional tutorial has begun
44 MD_Section1 This and the next several codes define the times of entry into the tutorial's several successive sections:
45 MD_Section2
46 MD_Section3
47 MD_Section4
48 MD_Section5
49 MD_Section6
50 MD_Section7
51 MD_Section8
52 MD_Section9
53 MD_Section10
54 MD_Section11
55 MD_Section12
56 MD_Section13
57 MD_Section14
58 MD_Section15
59 MD_Section16
60 MD_TutorialEnd The tutorial has ended

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.


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.