Rooftop Ninja

Rooftop Ninja is an intense action game for the NES blending high-flying ninja jumping with shuriken throwing!

The game is an endless action platformer with boss fights:

• Use the B button to throw shurikens
• Use the A button to jump.
• You can Wall Jump by pressing Left or Right towards a wall and A to jump again from the wall. Use this trick to climb up to the sky!
• Collect silver coins to get extra points

Looking for challenge?

My  current record is 3157 points, can you beat it?

Credits

As the game doesn't feature a title screen due to space constraints (see next section), here is the full credits for this project:

• A game by Dr. Ludos
• Graphics by Seiyouh - "Free Ninja Gameboy" : https://seiyouh.itch.io/ninja-gameboy
• Font by DamienG : "Shinobi Extended" : https://damieng.com/typography/zx-origins/shinobi-extended/
• Music by Ipi
  • Gameplay music: "Revenge of the devil" : https://battleofthebits.com/arena/Entry/revenge+of+the+devil.nsf/30835/
  • Boss music: "The enemies are random animals" : https://battleofthebits.com/arena/Entry/the+enemies+are+random+animals.nsf/67378/

About this project

This game was made in a bit more than two weeks for the "Lofi mini Jam 2: Single Chip Cartridge" hosted by lidnariq over the NesDev forums. The goal of this jam was to make a NES game that could run within the added constraints of a "Mapper 218" cartridge. It offers 32K of code (PRG)  and that's all! Unlike all the other NES games, there is no separate rom chip for the graphic data (CHR). So how are the graphic handled with this mapper?

It's simple, it hijacks the 2K of internal VRAM from the console to store the graphic data, that you have to manually upload from your code (CHR-RAM). The issue is that these 2K of VIDEO RAM (VRAM) are solely dedicated to storing the tilemaps (Nametables) displayed on screen. So now you have to use the same graphic memory to both store the raw graphical data and the tilemap displaying it. As you can imagine, this comes with an unique set of challenges to display anything meaningful onscreen. The mapper 218 offers several solutions for this:

• You can sacrifice one nametable to store up to 64 tiles of graphical data, and use the other nametable to display them. This is the easiest path, but you can forget about scrolling games. And you're limited to 64 tiles, while even the simplest normal NES games have at least 512 tiles available.
• If you want to use scrolling, you'll have to come up with tricks to "hide the glitches" that comes with storing raw data instead of display information. Several such tricks are listed on the game jam page.

Tricks used in Rooftop Ninja

As you can see in the animated GIF, my game uses scrolling, so I had to use several tricks:

1) First of all, the game uses only 40 tiles in total. I tried to use as few raw graphical data as possible to limit the amount of tilemap data that would need to be sacrificed. The main consequence is that the game doesn't embed a text font besides the numbers 0-9 to display score. So it's very difficult to display any textual information. That's why the game doesn't have a title screen with credits information. And that's also why I had to use a lot of shuriken sprites to write the word "DEAD" when the player loses. I couldn't simply print the words "GAME OVER" like I usually do. To lessen the issue, I tried to animate this with the shurikens coming from all around the screen to write the word.

2) The main trick is that I sacrificed 1 background palette, setting all of its 4 entries to the background color. I then apply this background palette to all the area of the screen than contains raw graphical data instead of valid tilemap data. So the graphical glitches are displayed on screen, but as there are painted with a single color, you won't notice them. For more details, I sacrificed the top 8 row of the tilemap (64 pixels high) and the bottom 2 row (16 pixels high) on both nametables. For example, here is a screenshot of the game with the "glitches hiding" disabled:

After you paint those glitches with an unique color, the game looks normal:

The tradeoff is that the topmost 64 pixels and bottom 16 pixels of the game will always be solid blue, they can't display any background graphic data. I tried to make a game where this won't be too much of an issue. I also used sprites to display the score and life counter over this "mandatory empty" area.

So, there are the graphical glitches that the raw tile data are causing to the tilemap. But as the memory is shared, the opposite is also true: the tilemap data shows up as graphical glitches in the raw tile data, as you can see here:

You can see the 40 different 8x8 tiles of the game here. The glitched areas here are actually "non glitched" tilemap areas on the screen display. Obviously, you can't use any of the glitched tiles as a source to display something onscreen. In the end, it's really a tradeoff between more unique raw tiles and larger "non-empty" tilemap area.

3) Last but not least, the game also use graphical data streaming to display the player animation. Only 4 tiles are dedicated to display the 16x16 pixels players on screen. Each time an animation changes (and it's almost every frame), new graphical data is uploaded from the code to these 4 tiles in the shared video memory. It's great because you can display as many animations as you want this way, but you are limited in the amount you can modify each frame: up to 8 tiles if you don't do anything else. In my case it's only 4 because I'm also doing work on the procedural level generation, so I'm also modifying the tilemap almost each frame.

An open source game

The retro games homebrew communities are wonderful places where people create new games for old consoles for the fun of it, and love to share their work and knowledge with others. So whenever I can, I try to contribute too by documenting and sharing the source code of my games, hoping it may help others to make their own games.

In addition to the ROM, you'll find a zip file containing the fully commented source code of the game. As detailed in the README inside the zip file, the source code is released under the MIT license. The game was programmed 100% in C using the wonderful CC65 toolchain coupled with the NESLib, NESDoug and Famitone 3 wonderful libraries. Please don't hesitate to ask me if you have any questions about the source code or how the game works.