Fighting Game Engine

DChilders84

New member
I know this wasn't a stretch goal, but does anyone think there will be a way of creating a decent fighting game engine in NES Maker? Obviously I'm not expecting something like Super Street Fighter 2 Turbo for SNES, but something workable that can potentially be inserted in to another style of game.

This was always one of my "fantasies" in gaming. I wanted an RPG style game (Final Fantasy 3) that swapped to a fighting game style (Street Fighter 2) engine for the random battles. As you grew your character's stats, the enemies you fought would scale as well. To date, I really can't think of any game that has done something like this. There are games with combo systems (Legend of Legaia) and similar, but nothing that seamlessly blends the genres of RPG and Fighter. This would also open the door to online battles where you pit your character against other peoples'. Like I said, just a fantasy of mine.
 

RadJunk

Administrator
Staff member
One of the big challenges with these sorts of fighting games is the sprites. The NES has some hard rules when it comes to sprite drawing...for instance, only 8 8x8 tiles (sprites) on a scanline...after that, they just don't draw. Or, if you develop a system to cycle drawing priority, they "flicker", and if you ever played a NES game, you know how many games have that classic flicker.

So let's say you have a game that has graphics comparable to Street Fighter 2 in size. If I'm not mistaken, Ryu standing still is approximately 40 pixels wide...so 40/8=5 tiles. That means Ryu fighting Ryu would be 10 tiles...which means even just two characters standing facing each other would either have sprite dropout or flickering. Now, what if they both have their arms extended in a punch? That adds another 40 pixels or so to each. So...now you have 20 pixels in a single scanline, when the NES can only handle 8.

Not to mention, Ryu is approximately 5 tiles wide and 10 tiles tall, making him 50 tiles total. Two Ryus on screen would be 100 tiles total...but the NES can only handle 64.

That's the first problem with making a traditional fighting game. What MIGHT be able to be accomplished is something more like a versus Double Dragon. There, the sprites are only 16x32 (so, 2 wide by 4 high when idle, let's say 4 wide when attacking, so if they were both attacking each other on the same scanline, it would still only be at that 8 tile limit, and total, would be well under the 64 sprite limit). But then, such small graphics for a fighting game as we've come to think of them offers much less detail and is far less interesting.

So lets say you max out the sizes to be perfect to work. THEN you have to worry about all of the animations. You really would only have about 128 unique tiles to make your animations for each character. Let's say you have four frame animations for all of your *moves*, and you managed to make characters that used only 8 tiles like the size of the characters in double dragon.

IDLE = 8 tiles x 4 frames = 32
PUNCH = 32
KICK = 32
HURT = 32......

And now you're out of available tiles.

Sure, you could probably re-use some tiles, and shorten some animations to make this work, but fighting games are fun precisely because there is SO much that a character can do to attack or counter attack, this would get really, really limited.

I could go on and on and on, but this is the sort of reason why the NES is a horrible platform for versus/fighting games. There will always be people who end up doing hyper-wizardly, uber game-specific things to attack these sorts of problems (to mixed result), but working from an engine that is supposed to start from sort of a vanilla base and be versatile, you can see the problem it presents to make something that feels like a true fighting game!
 

DChilders84

New member
Ahh, I see. So it is technically doable, but the sprite limitation would limit the aesthetic. I guess I could do the RPG engine and go to a brawler style for the random encounters - Double Dragon style, as you mentioned. For now I'll just be patient and see what the engine allows come August. Perhaps there will be an ASM wizard out there, as you mention XD
 

Kasumi

New member
RPG Game that Switches to Fighting Game on random battle.
Cross of Venus comes to mind: https://www.youtube.com/watch?v=2x16b2Fg-BM Not NES, obviously.
It doesn't lock you to facing the opponent from what I remember (in case that affects what you consider a fighting game).

Neo Geo Pocket Color has similar sprite limitations to NES (64 8x8 sprites), and had rather a lot of fighters. But it had no sprite per scanline limit from what I can tell. Here's some gameplay footage from SNK vs. Capcom: The Match of the Millennium: https://youtu.be/jHHr8lBQsL8?t=1m4s
A lot of Neo Geo Pocket (Color)'s library was fighters.

But managing lots of animation in this way Is more suitable for CHR ROM bank switching on NES and NES Maker's Mapper is CHR RAM. I've been working on a CHR ROM NES graphics data tool and I'm importing character graphics from Match of the Millenium to test it.

I had written a long thing about how to potentially do it in CHR RAM, but I guess it boils down to:

I wrote a test ROM that did 32 pixel per frame scrolling (horizontally). That means it could push 128 bytes to the PPU every frame. A tile is 16 bytes. Therefore you can update about 8 tiles in a single frame. (It may be possible to do slightly more than this... but eh...)

Since you probably want the characters to move and animate independently, this is 4 tiles per character per frame. If the frame you want to display needs 12 tiles and none of them are in memory, you need to wait 3 frames for it to come out.

You can make faster attacks by ensuring they're always in memory. For instance: Say your 12 tile attack can use 4 tiles of the head from idle. Now it can come out in 2 frames. If all the tiles it needs are always in memory, it can come out immediately.

So the strategy would be to have hitstun frames always in memory. (Since the opponent can always interrupt your attack by hitting you.) Any projectiles the player can use also need to always be in memory. And then you want as many tiles as you can fit from the first frames of the fastest attacks always in memory. With all those things in, you can use whatever is left as a scratchpad to put tiles for new frames. Imagine a three frame animation. 12 tiles per frame. If you want each to play for 1/60th of a second, you need the first two frames always in memory.
Before frame 1 is displayed, 4 tiles from frame 3 are put in the scratchpad.
Before frame 2 is displayed, 4 more tiles from frame 3 are put in the scratchpad.
Before frame 3 is displayed,the final four tiles are put in the scratchpad. Literally just in time for it to be displayed.

But the more tiles an animation uses, the slower it has to be. (Or else, it'll just have to use a lot of the "always in memory" portions, but eventually you run out of that space.)

pZeS81o.gif

The Indivisible boss is like 30 tiles per frame. It'd take 8 frames to write the tiles to display a new frame that wasn't in memory assuming two of them. With CHR ROM bank switching, this doesn't matter even a little bit. One can display any frame from any character at any time no matter how large. (There are some caveats, but they wouldn't matter much for a fighting game.) That's what I mean when I say CHR ROM bank switching is better for this.

(What do you know, turns out I wrote a lot again. Better explained this time around, though.)

@R Cohrs: I'm not sure if you're suggesting NES Maker should be able to do it because those games do. Understand that not all NES cartridges are created equally. Little Ninja Bros, TMNT Tournament Fighters, and Radia Senki - Reimei Hen all use MMC3 with CHR ROM bank switching. The cartridge NES Maker targets doesn't have the same options those games had. Just as those games didn't have the option to play over 20 minutes of streaming audio: https://www.youtube.com/watch?v=3w8atFA2fk0 Extensions in NES cartridge hardware greatly changed what was allowed, even back in the day. It's also not as easy to just target a new cartridge type.

Of games I know, Battletoads gets the closest using a similar setup. It still had to really be designed around. How many tiles your characters take up affects how fast your animations can be played and where they need to be. With MMC3, none of that matters.

Edit: And just because I guess the inevitable followup question is "Why not just target MMC3 as well?" The answer is that they're different in many subtle ways besides just CHR RAM vs CHR ROM.
 

RadJunk

Administrator
Staff member
Kasumi...I hate you. You make everything I do look so trivial with your awesomeness :)

Seriously, dude. You rock. And I can't wait for people who really know there stuff to get their hands on this, break it into a million pieces, and say, "look at this awesome thing I bent this tool to be able to do". :)
 

Mihoshi20

Member
TheNew8bitHeroes said:
Kasumi...I hate you. You make everything I do look so trivial with your awesomeness :)

Seriously, dude. You rock. And I can't wait for people who really know there stuff to get their hands on this, break it into a million pieces, and say, "look at this awesome thing I bent this tool to be able to do". :)

LOL, yes, that's what I'm excited about the most, seeing what wicked cool things people make once they get their hands on the tool and underlying engine and start diving into the asm. Even if they just use it to study the NES or do some preliminary work and then the rest all pure asm weaving. I imagine some people are going to make some great things judging by the mockups on the FB group alone.
 

Kasumi

New member
I finished up my own animation exporting last night. (But it's still a CHR ROM solution.)
70kmfF6.gif

Here's what the tooling looks like.
fCyZuar.gif

For CHR RAM, you could use 50 sprite tiles for a two frame buffer leaving 78 for always loaded. 78 only gives you like three full frames which doesn't help much.

These Sakura sprites average around 24 sprite tiles per frame. At four tiles per frame per character, it'd take six frames (1/10th of a second) for the average frame of animation to be ready for display. That's not necessarily slow. Everything in the above images is played at that speed.

You get a lot more options in a single player game if you want a bunch of large animation. Without dividing the tiles between characters, you can double the amount you can update in a frame. If you do that, your main character only needs to use (number of tiles for the largest frame)+(number of tiles for the second largest frame) in the set. For the above Sakura frames (in the GIF at least), that's 46. That leaves 210 for all the enemies in the level.

Exporting this kind of data for CHR RAM is perhaps even easier than for CHR ROM, but loading it on the NES side requires safely syncing a lot of parts. I might attempt it, but there's a lot of stuff I want to get done more.

tl;dr: If six frames (1/10 of a second) of animation latency is cool, you can totally do sprites as large as these in a two player fighting game on CHR RAM.
In a one player game you can do the same with three frame latency.
Both example games probably need to be extremely light with every other kind of graphics update, though.
 

Mihoshi20

Member
Kasumi said:
I finished up my own animation exporting last night. (But it's still a CHR ROM solution.)
70kmfF6.gif

Here's what the tooling looks like.
fCyZuar.gif

For CHR RAM, you could use 50 sprite tiles for a two frame buffer leaving 78 for always loaded. 78 only gives you like three full frames which doesn't help much.

These Sakura sprites average around 24 sprite tiles per frame. At four tiles per frame per character, it'd take six frames (1/10th of a second) for the average frame of animation to be ready for display. That's not necessarily slow. Everything in the above images is played at that speed.

You get a lot more options in a single player game if you want a bunch of large animation. Without dividing the tiles between characters, you can double the amount you can update in a frame. If you do that, your main character only needs to use (number of tiles for the largest frame)+(number of tiles for the second largest frame) in the set. For the above Sakura frames (in the GIF at least), that's 46. That leaves 210 for all the enemies in the level.

Exporting this kind of data for CHR RAM is perhaps even easier than for CHR ROM, but loading it on the NES side requires safely syncing a lot of parts. I might attempt it, but there's a lot of stuff I want to get done more.

tl;dr: If six frames (1/10 of a second) of animation latency is cool, you can totally do sprites as large as these in a two player fighting game on CHR RAM.
In a one player game you can do the same with three frame latency.
Both example games probably need to be extremely light with every other kind of graphics update, though.

Looking great! You always do such cool and fluid animations.
 

TonyTheTGR

New member
After a few years of dabbling with KoF All-Star, it's entirely possible that a good basis for this would be a modification to the Brawler Base Engine.

Sprites don't *have* to be big; and this is how GB came out with lots of phenomenal fighters like Battle Arena Toshinden, SamSho, and KoF '96.

That said... design-wise you're real constraint that you'll be dealing with is the limited buttons. You can go with a light/hard press P/K system; but it may be just as easy to do a "light attack" and "medium attack" and press them both to get a "heavy attack." Or you can do a simple combo button, and then a direction+special button, like Smash does. Making it fit mechanically in NES spriting limitations and various enough takes some minimalist design to work, but again... most of this is a matter of changing foundationals in the Brawler engine (like remapping jump to "up," or removing jumps/aerials entirely and making them specific special moves/commands.

EDIT: Oh yeah. THE BACKGROUNDS. There's your asset squeeze!

The real trick is making multiple bounding boxes (hitbox vs. hurtbox)...
 
Last edited:
Top Bottom