Data analysis - Maritime Defender

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.

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.