How was a demo mode implemented in arcade machines

Question

On many arcade machines when running in attract mode, they often show a demo gameplay. I wondered how they did this?
I guess those are not pre-recorded movies, so I think that they probably ran the game engine with some pre-defined input. On some machines one can see that this demo is not always the same, so there is some randomness there as well.

Answer 1

Most of the time, game coders are not going to program an A.I. just to show the demo so the moves are pre-recorded, and generally the demo ends quickly with the main character dying/exploding (maybe not to show too much of the level)

To record the moves, the programmers probably added some piece of code to log all player input along with the exact frame where it occurs and save it in memory. In the end, the memory is dumped and the moves are integrated as game data. (and recording code is then probably removed from the final release).

Part of the disassembly of Bombjack arcade game proves that there was a recording of some input (fake player input)

; play mode ?
ld     a,($8070)       ; 038C 3A 70 80
or     a               ; 038F B7
jp     nz,$0398        ; 0390 C2 98 03

; no (demo), A = fake input
ld     a,($807a)       ; 0393 3A 7A 80
jr     $03a2           ; 0396 18 0A

; yes (play), A = player pinout
ld     a,($b000)       ; 0398 3A 00 B0
bit    0,b             ; 039B CB 40
jr     z,$03a2         ; 039D 28 03

Sometimes there are several moves or levels recorded just for variety too. Introducing randomness in the player moves would be risky and would bear poor results. Just recording 2 or 3 different games is better.

About the randomness, well, most games have randomness in them (enemy moves/shots). So if you record moves with some random setting, and replay them with another, then the game will be different.

If this causes too much problems, they can fix the random seed of the demo so it matches the random seed of the time when they recorded it.

In the game Pengo, the demo mode does fix the random seed and the difficulty setting (which matches the recorded sequence) so the sequence replays exactly the same, and even the random movements of enemies are the same as when recorded.

A "modern" example of this is the fact that you can record input in a lot of emulators. MAME for instance. Of course, you have to record the moves from the machine bootup. Replaying moves of a game on another game without rebooting the machine will give another (failed) sequence because of randomness not being the same. This technique is also used (along with state save) for tool assisted speedruns.

Okay, but... (aka: counter-examples)

Mrs Pacman

Just to contradict myself, I checked Mrs PacMan source code derived from PacMan source, and commented by the person who reverse engineered it) and this comment directly contradicts the above... Duh.

controls pac-man AI during demo. pacman will avoid pink ghost, or chase it when red ghost is edible

The A.I. is simple in that case, but it's very unlikely that an A.I is used in platformers/shooters or a racing game. A complex A.I needs time to make it right, and takes more room on released program ROM (so a fighting game could totally use its own opponent A.I. for the main character during a demo)

Galaxian

The demo mode relies on random player moves, but it has some rules to try to shoot aliens when X coordinate match. I wouldn't call that an A.I but for a few seconds (until ship is destroyed) the illusion is there.

Karate Champ

Even more naturally, the Karate Champ game naturally has a A.I. for CPU opponent. Demo mode just configures both players as CPU and the A.I. does the rest.

Conclusion

So the right answer is "it depends", depending on the ability to auto-play during a few seconds without the main character moves looking dumb.

Let's not forget that the demo mode is vital to attract players, so if the demo game play is dumb A.I. that doesn't demonstrate the game possibilities, that's not going to work to cut it.

Answer 2

For space invaders what happens is the game has short list of movements (11 in ROM but only 10 are used) left and right or stay still.

If there is no bullet in flight the player fires, each time the bullet fires the next direction action is pulled from the list and the player starts moving in that direction. The time of flight of the bullet acts as a timer, either it hits an alien, base or goes of the top of screen and then the player fires again.

The position in the movement list only gets reset as part of the power on (IIRC) so the movement feels fairly random.

If you use mame there are some oddities around the way the two screen scan interrupts work which mean that performing a mame reset is slightly different from starting mame and you get different sequences.

In psuedo code it looks something like this:

IsrRoutine60Hz()
{
  CheckForPlayerFiresBullet();
  MovePlayer();
  // Draw Screen / Invaders etc....
}

CheckForPlayerFiresBullet()
{
   if (no_bullet_in_motion) 
   {
     if (demo_mode )
     { 
       FireBullet();
       demoPlayerDirection=moveList[nextDemoCommand++];
       if (nextDemoCommand>=moveList.Length)
          nextDemoCommand=0;
     } 
     else 
     {
       if (fireButtonDown) FireBullet();
     }
   }
}

MovePlayer()
{
   if (demo_mode)
     command=demoPlayerDirection;
   else
     command=GetDirectionFromButton();
   // Move left,right or stay still based on command
}

Answer 3

In Battlezone, the code for the play loop is shared between "play" and "attract" modes. At various points, a flag is tested to see if the game is "played" by the player or a demo. A counter is used to cycle between showing the logo, showing high scores, and driving around.

The self-driving logic is in the UpdatePlayer code. It steers toward the enemy position, alternating forward and reverse movement every 64 frames. Other bits of code check play_flag to change enemy behavior, omit display of the copyright string, unmute the engine sound, etc.

It's not very sophisticated -- it doesn't really show you what playing the game looks like -- but it was enough to get one's attention back in 1980.

Update: a couple more...

In Missile Command, the game actually plays the first wave, which is randomized. It targets missiles in the order in which they appear, moving the crosshairs to a point the missile will reach in 16 frames. When it reaches the coordinates, it fires an ABM from the closest launcher. There are some limitations, like not having more than two ABMs in flight at once, that slow the pace of the demo.

There's a little bit of "am I playing or attracting" code elsewhere, to suppress sounds and scoring and so on, but most of the work happens in a replacement for the controller read routine.

In Asteroids, the game just plays without a player. Saucers appear and occasionally shoot asteroids; when they're all gone, the wave resets. Not really a play demo; more like everyone left but somebody forgot to turn off the lights.