Implementing "Rewind" in NES Game

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Post Reply
User avatar
Goose2k
Posts: 104
Joined: Wed Dec 11, 2019 9:38 pm
Contact:

Implementing "Rewind" in NES Game

Post by Goose2k » Wed Aug 26, 2020 5:31 pm

I'm working on a port of my Pico-8 game, Witch n Wiz. It's a grid-based puzzle platformer, based on the sleeper hit Catrap/Pitman for the Game Boy.

One really cool thing about these games is they feature a rewind feature, so if you make a mistake you can go back a few moves without starting the game from scratch.

In the original GB version, this is done very well, and is actually fully animated as it goes back in time (as if going frame by frame backwards - I think).

catrap_rewind.gif
catrap_rewind.gif (3.6 MiB) Viewed 648 times

In my Pico-8 game, I simplified a bit and just stored the state of each object when the player made a move (basically the only time something interesting can happen in this game). Even with this dumbed down version it took up a LOT of memory, so I think the GB version must be doing something clever...

witchnwiz p8_2.gif
witchnwiz p8_2.gif (617.57 KiB) Viewed 648 times

Any ideas on how that might have been implemented (so that I can do similar on the NES)? I can't find anything online.

Fiskbit
Posts: 153
Joined: Sat Nov 18, 2017 9:15 pm

Re: Implementing "Rewind" in NES Game

Post by Fiskbit » Wed Aug 26, 2020 6:12 pm

I'd probably include a history list with all the information needed to reverse each move, and then have code to undo the move in a way that looks visually as close to the original move as possible. Since movement in this game is block-based, that'll simplify things a lot so you probably won't be worrying about difficult-to-find bugs with subpixels being slightly off after rewind or something like that. The main thing is probably making sure you're saving all the state you care about. You may end up making sacrifices to work within the RAM limitations, choosing not to save state that doesn't significantly impact gameplay.

User avatar
Goose2k
Posts: 104
Joined: Wed Dec 11, 2019 9:38 pm
Contact:

Re: Implementing "Rewind" in NES Game

Post by Goose2k » Wed Aug 26, 2020 9:10 pm

Fiskbit wrote:
Wed Aug 26, 2020 6:12 pm
I'd probably include a history list with all the information needed to reverse each move, and then have code to undo the move in a way that looks visually as close to the original move as possible. Since movement in this game is block-based, that'll simplify things a lot so you probably won't be worrying about difficult-to-find bugs with subpixels being slightly off after rewind or something like that. The main thing is probably making sure you're saving all the state you care about. You may end up making sacrifices to work within the RAM limitations, choosing not to save state that doesn't significantly impact gameplay.
Yah that's pretty much what I did for Witch n Wiz (minus the animation stuff). Thinking about it again, if all the animations were done via tables (containing x, y, anim frame, etc) it might be pretty trivial to play backwards; all I would need to store is the state between moves, and a pointer to the "movement" table that was used to get there. I already use movement tables for some special cases which require movement to ease in/out, so I could do it for linear movement too. Need to think about it some more.

Oziphantom
Posts: 913
Joined: Tue Feb 07, 2017 2:03 am

Re: Implementing "Rewind" in NES Game

Post by Oziphantom » Wed Aug 26, 2020 10:51 pm

so 8x8 gird means 3 bits per X and Y and you have 4 directions which is 2 bits so

DDYYYXXX in one byte. you store each title that moves each update. Store the X and Y as final position not starting position. Even in 2K you should be able to fit a lot of wind back state info.

DD
00 = up
01 = right
10 = left
11 = down
Then when you want to reverse the commands you read the byte mask off and look up the X and Y, eor #$C0 to reverse the direction.

BPL LD
BVC Up
; right here

LD
BVC Left
; down here

and then you can swap the tile. If that is a cheap "pop" as per your Pico-8 game or if you implement and animation that is basically the same.

As you have destructive elements you need to go 2 bytes per object. As you also need a "killed thing" byte. You could make it a bit field that packs in 8 commands worth for movements. I would for sanity go with byte per "frame" rather than global but it depends on how tight you memory is.


If you have multiple side effects per frame you can keep a "frame pointer list" which is index + count. Depending upon how many you have you could probably split the bits again to pack "starting offset" and "number of moves" into 1 byte, or maybe 2 bytes if you want to be able to back track a lot.

User avatar
Controllerhead
Posts: 148
Joined: Tue Nov 13, 2018 4:58 am
Location: $4016
Contact:

Re: Implementing "Rewind" in NES Game

Post by Controllerhead » Thu Aug 27, 2020 9:48 am

I would definitely choose a mapper with extra RAM, you're probably gonna need that sweet $6000-$7FFF
Image

Post Reply