Attract mode

[DRW]

What is the best way to do an attract mode in a game?

The way I would do it is this:

I would set the randomizer to a specific seed value and then I would play the game and record the input with the emulator.

Then I would save the input as an array:
First byte: Pressed buttons
Second byte: Number of frames these buttons are held
Repeat.

Before the attract mode starts, I would save the current randomizer seed in a specific variable. Then I would set the specific value with which I recorded the play to the randomizer seed.

Then I would let the game play out normally, only that controller input is like this:
Controller = attractMode ? ReadNextAttractModeValue() : ReadController();

And in the end, I would set the randomizer seed back to the saved value.


Do you have any improvements to suggest?

[tokumaru]

Sounds good. One thing missing from your description is a way to exit from the attract mode. Personally, I'd solve that by ORing the status of the real start button with the logged keys and have the start button end the demo, so that either a logged or a real start button press would do it.

As for recording the key logs in the first place, you could use an emulator that records movies, but personally, I think it's better to record the button presses using the game itself, because then there're no synchronization issues at all, even if there are lag frames. I just log the keys to PRG-RAM at $6000-$7FFF (which I enable only for this purpose), already using the RLE format, and then I extract the data from the save file or from the emulator's memory editor.

[DRW]

Right, exiting the attract mode is of course necessary.


About saving the button presses: I think it's really just an issue of preference.

I mean, if you actually have lag in the 30 seconds of demo play, then you should maybe redo your game engine. It doesn't really look good if the first seconds of the first level already lag.

[Alp]

What is the best way to do an attract mode in a game?

I would set the randomizer to a specific seed value and then I would play the game and record the input with the emulator.

Do you have any improvements to suggest?

Your game is a randomly generated platformer, with randomized platforms at fixed elevations, yes?

It wouldn't take all that much work to automate an attract mode, that simulates being played, by simply performing relative-position checks for power-ups, enemies, new platforms, and periodically applies input, to "play" the game. With procedurally generated game content, that feature could be a nice addition.

(You'd be surprised how convincing "input acceleration" can look.)

I had planned such a feature for my SonSon parody, but I ran out of time to add it to the game.
(I only had 2 months to work on the game, from start to finish, the art took up most of that time.)

[DRW]

It wouldn't take all that much work to automate an attract mode, that simulates being played, by simply performing relative-position checks for power-ups, enemies, new platforms, and periodically applies input, to "play" the game.

Nah, I guess that's too much.
If I decide to include an attract mode (I'll have to see how much space is left in the end), I would just start the attract mode with a specific seed value, so that platforms and enemies are fixed, and then I would read an array of pre-recorded input data that I recorded when I played the game with this seed value.
Actually implementing an algorithm that lets the computer play the game dynamically in any situation is too much here.

[slobu]

Last time I did an attract mode I set a flag that would branch the usual end user joystick routine to an AI movement routine. I also skipped the sound routines if the attract mode flag was set. When a life would usually be decremented I checked to see if it was in attract mode and skipped back to the title.

Why store recorded values when you can re-use the existing game engine and just let AI take over the player? It doesn't have to play like a human. It just has to display a small portion of gameplay.

[DRW]

Why store recorded values when you can re-use the existing game engine and just let AI take over the player?

Because unless you program a fighting game or something else where all character act alike, there is no AI for the player character in the game.

For example, which character in "Super Mario Bros." would have the same abilities as Mario himself, so that you could reuse this function for the attract mode movement? None. Therefore, you have to pre-record Mario's attract mode movements.

Or do you want to use the Goomba's AI for Mario's attract mode movement?

And if you have to implement Mario's AI specifically for the attract mode, then it has nothing to do with reusing it.

[Pokun]

Well if you already have an AI for the player character you could always use it, but I wouldn't write an AI routine just to be used once in the attract mode.

[Alp]

Because unless you program a fighting game or something else where all character act alike, there is no AI for the player character in the game.

For example, which character in "Super Mario Bros." would have the same abilities as Mario himself, so that you could reuse this function for the attract mode movement? None. Therefore, you have to pre-record Mario's attract mode movements.

Or do you want to use the Goomba's AI for Mario's attract mode movement?

And if you have to implement Mario's AI specifically for the attract mode, then it has nothing to do with reusing it.

I think the point is, that producing a "wrapper" function, to take control over the game logic, is more efficient than "recording" controller input. Less ROM space, and negligible RAM space use.

What's being "re-used" in that case, is the core gameplay logic.

The (obsolete) object code for my current RPG project, was only 79 bytes of ASM, for example.
It controlled the player character's movements, and directly controlled the behavior of (up to) 8 non-player objects. It's currently undergoing an overhaul, to add automated party members.

The Goomba is a bad example, because the object logic in Super Mario Bros. was poorly made.
(Too many copy/pasted routines, as far as I can tell.)