News:

Look at this spiffy theme!

 

Bokosuka Wars (Famicom)

Started by RT-55J, Fri, 2025 - 06 - 20, 08:31 PM

Previous topic - Next topic

RT-55J

Bokosuka Wars is a legendary Famicom "kusoge." It's one of the earliest RPG-likes on the Famicom, as well as a very early predecessor to the "real-time strategy" genre. Allegedly "bokosuka" is an onomatopoeia for the sound of fighting or a scuffle. Given how combat in this game amounts to cartoon cloud scuffles, that seems like a very fitting (if also very silly) name.

Yesterday I was feeling listless, so I looked at a list of NES games and fired this up completely on whim. I managed to make it all the way to the ending with no understanding of the mechanics using a fancy strategy called "rewind." This is viable because the result of a combat encounter is simply the result of a coinflip of your attack power versus the enemy's (there are no other stats), so I could just reroll any encounters I lost until I won. This is made even easier by the fact that the enemy cannot initiate a combat encounter.

Anyhow, after I saw the "win" screen, I decided to actually do some research about the game.

It turns out the main mechanic I missed was that you can recruit other soldiers and knights into your army through the magic technique of bumping against various rocks on bushes. I guess it makes sense that the king doesn't have to do everything alone.

One thing I noticed immediately when playing the game is that it is very unresponsive. It takes 20 frames of time for the game to render the next frame, so the game appears to run at a brisk, locked 3 FPS. There appear to be a few reasons for this. One is that the game does not use any sprites (during the game), and it does not use any hardware scrolling. Instead, it uses the NES's two nametables as a form of double buffering. The other reason (this is only a guess) is that I think the game processes all 200-ish actors every single frame, whether or not they are onscreen (though whether or not they do anything might be determined by whether or not they are in aggro distance). I suspect this is even further slown down by the fact that this is an NROM game, and so it might have to do some things in a computationally inefficient way due to the base NES's severe RAM constraints.

Anyhow, I was also curious about how the map is stored. It's 600 "meters" (tiles) wide and 10 meters tall, which almost certainly means that it's not stored in the NES's paltry 2048 bytes of onboard RAM. Given the high degree of (apparent) persistence of the game world, I also suspected that it does not do the SMB1 approach of loading things on the fly and only having two screens active in RAM at once. Thus, I concluded that the map was likely uncompressed in the ROM.

With that in mind, I fired up one of my favorite tools, Binxelview, and futzed around with it until I got a potentially reasonable seeming result. I eventually found a portion of ROM that, when interpreted as 16-bit words, was 600 units wide and 12 units tall, which seems pretty close. Unfortunately, I don't really see much that seems to resemble the geometry of the game world, so maybe I found something else instead (regardless, though, it takes up a ridiculous portion of the ROM).

Will I do anyhting more with the game? Perhaps.

RT-55J

one incredibly vexing thing about NES hacking is that cursed 0x10 byte header before the beginning of the rom

RT-55J

screw you *removes your iNES header*

RT-55J

I still haven't fogured out the map format, but I have found the data that initializes both the player and the enemy armies.

Units are tagged as dead by giving them a negative position. Every frame, the game checks the first and last units (you and the enemy king) to determine if it should display the victory or loss screens.

This is one of those games where the units' displayed power is 10 times their internal number (I love adding zeroes in post).