This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Chu Chu Rocket

Chu Chu Rocket
by on (#41894)
So yeah, I might be making a NES version of Chu Chu Rocket at some time. I've calculated that you can get all possibilities of mice entering and leaving squares, as well as different wall positions, within 256 tiles per scanline.
The big question is how to iterate over a map and calculate new values for mice on the map, can it be done within 16 frames?
Re: Chu Chu Rocket
by on (#41895)
Dwedit wrote:
So yeah, I might be making a NES version of Chu Chu Rocket at some time. I've calculated that you can get all possibilities of mice entering and leaving squares, as well as different wall positions, within 256 tiles per scanline.
So you're char-plotting the mice then? I suppose that's the only viable option given that that the original game often shows whole columns of 16x16 mice parading across the screen.
I'm not entirely sure what you mean by 256 tiles per "scanline" but personally I'd just pre-render all the combinations of mice entering and leaving the various tiles from various directions into CHR-ROM. And since all of the mice move in step with each other you'd easily be able to animate the entire movement across the a tile without actually touching memory simply by switching ROM pages (e.g each page would correspond to one phase of the animation.) Plus with a bit of double buffering there would be plenty of time to replace the old tilemap within the blanking periods.
But perhaps that was what you meant?

Dwedit wrote:
The big question is how to iterate over a map and calculate new values for mice on the map, can it be done within 16 frames?
I honestly don't see how it's much of a problem. 16 frames is a great deal of CPU cycles, and it's not as if the movement patterns are very complicated. Plus you only have to deal with nice integral coordinates on a grid with less than 256 squares. Hell, you could handle the mice as cellular automata rather than game objects in the usual sense if you wanted to.

Why not simply pre-calculate the next step at each square and for each direction into a table in RAM? That, plus some collision detection so you don't run into another mouse, ought to account for most things in the game as far as I can recall. Granted, I never actually got all that far so perhaps there's worse things to deal with later on in the game.

Good luck with the project at any rate, it's certainly a nice little puzzle game well-deserving of a NES port!

edit: Lets make a rough estimate of the worst-case scenario. Say there a hundred mice on the screen, we've got half of the total CPU time to dedicate to movement logic, and we're in "turbo" mode so we want to perform each move in only four frames instead of sixteen. This still leaves 600 cycles per mouse.
I don't care what method you adopt, you'd have to be trying not to fit the movement routine within that limit!

by on (#41897)
By "Per Scanline", I mean that if you're using 16x16 metatiles, you can alternatively bankswitch the CHR every 8 scanlines to get 512 effective tiles instead of 256.

As far as progress at the game goes, I've only made a tool which generates a CHR file, and have drawn graphics for the mice. That's it.

A tile in the CHR file is a function of:
* Frame number (0-7) or (8-15)
* Whether it's the first 8 frames or not
* Whether a mouse is entering or leaving on 4 directions
* Whether there is a LEFT+UP wall, UP wall, LEFT wall, or no wall for the tile
And I've worked out that every possible state will fit within 512 8x8 tiles per frame, and 16 frames of animation.
It might be hard to make background rockets work though.

Also, the background area of a tile would be nontransparent, to allow the checkered grid, and also have a black color available for pits.

I plan on making cats, arrows, and other game objects sprites.

by on (#41903)
Dwedit wrote:
By "Per Scanline", I mean that if you're using 16x16 metatiles, you can alternatively bankswitch the CHR every 8 scanlines to get 512 effective tiles instead of 256.
I see. I sort of did that for a C64 game project once and it worked pretty well there, though as we well know the NES timers are notoriously fickle. MMC3 IRQs I presume?

Intuitively it seemed you wouldn't need anywhere near that many tiles but you're right, it all adds up... exponentially.
Lets see what we get by treating the individual 8x8 tiles separately (not that you are of course, vertically anyway, but humor me anyway) shall we?
Something like the empty tile plus the eight cardinal and intermediate directions, times the four mice headings and a mouse standing still or no mouse at all, times the four mouse tiles. In other words 9 * (5 * 4 + 1) = 189 tiles. Yikes!
Too bad the NES hardware doesn't support horizontal or vertical tile flipping like a certain competitor's 8-bit system does :(

edit: Bah! I forgot to account for mice moving back-to-back, and not being able to enter and leave from all directions. I don't have the patience to work it all out but I presume it comes out somewhere above 256 tiles?

by on (#41906)
It comes to over 256 tiles, but when you factor in some impossible cases, like how exiting a square to the right will have no effect on the top-left tile during the second 8 frames, you get 64 possibilities per 8x8 tile, and that's without walls. The first 8 and second 8 frames are two separate cases which need to be handled differently.
So with 64 tiles for the top-left tile, and 64 tiles for the top-right tile, you have 128 remaining. There are five wall states for the top-left tile, and two wall states for the top-right tile. When you factor in walls, you can mask away some more possibilities.
You end up with 244 CHR tiles for the top two tiles. For the bottom two, you end up with less.

by on (#41911)
Dwedit wrote:
You end up with 244 CHR tiles for the top two tiles. For the bottom two, you end up with less.
Heh, it took some head-scratching to figure out why it's asymmetrical but you're really only drawing horizontal and vertical walls on one side of the tile, and adjusting the adjacent tiles instead when dealing with the other sides. Why didn't I think of that?

I just checked out the game again and it seems the little fuckers can actually run straight through each other from any direction. That combined with having to deal with columns of mice moving back-to-back makes me wonder how you managed to get away with "merely" (2x)244 tiles.
Though I suppose it wouldn't look too weird if you only showed one mouse when multiple mice overlap, especially if it's done on the 8x8 level. And the nice part is that there's no need to reserve tiles for stopped mice or handle collisions as part of the movement logic.