NES Dev Collaborative Fighting Game

[tokumaru]

While scrolling horizontally, it would look really cool if each scanline of the arena floor were scrolled just a little bit faster than the scanline above it.

That should be easy to do, specially considering that there will aready be raster effects if one of the players is drawn with background tiles like Bregalad suggested.

I fully agree with him, as this would allow for really large fighters, something that would seem impossible on the NES. The down side is that we'd still be restricted to 3 colors per fighter, although it would be possible to use different palettes in different areas if we picked a rule that worked for both sprites and background (since players can be drawn with either one).

Sprites would also be used for effects like energy attacks and blood I believe, which would cause one of the players to flicker a bit, but I guess this isn't a big deal.

Fighting games have a lot of room for effects, because they are not very intensive logic-wise... after all, there are only a handful of active objects at a time and there is hardly a level map to collide with.

[Celius]

You know, you could actually do away with any collision with the level map. All you really need to know is where the floor is, which is constant. Unless you'd really want for levels with lots of platforms.

What Bregalad suggested about the BG is a good idea. There is one thing to consider, however. Take a look at the enemies in Final Fantasy I-III. Why do you think the background is black? This wouldn't allow for detailed BG behind the character who is part of the BG.

However, you could move the characters in 8 pixel chunks, updating the BG instead of scrolling for the part of the BG with the character.

[SecretServiceDude]

You know, you could actually do away with any collision with the level map. All you really need to know is where the floor is, which is constant. Unless you'd really want for levels with lots of platforms.

What he said.

However, you could move the characters in 8 pixel chunks, updating the BG instead of scrolling for the part of the BG with the character.

Wouldn't that look incredibly choppy?

I don't know if this is feasible, but just to throw the idea out there: Since there probably won't be a huge number of arenas (and they'll only be a couple of screens wide anyway), would it be possible to use bank switched CHR ROM, and just use several ROM banks to store all 8 rotations of the character against the background? Sure, it's hugely wasteful, but if it's doable, that method would allow complex backgrounds and smoother character animation.

[tokumaru]

would it be possible to use bank switched CHR ROM, and just use several ROM banks to store all 8 rotations of the character against the background?

I don't think so... Even though fighting games are easy on the PRG side, they are huge CHR hogs, because fighters are very large and have many frames of animation. It's already difficult fitting a decent number of players with smooth enough animations, imagine all of that multiplied by 8!

that method would allow complex backgrounds and smoother character animation.

I fail to see how that could improve background detail...

In some fighting games for the original GameBoy, the characters were dynamically drawn over the background, but that was only possible because the whole screen used a single palette (everything was gray... or green, whatever). If you try to do that on the NES (using CHR-RAM) there will be lots and lots of ugly color clash, unless only 1 palette was used, which is just as bad.

Bregalad's suggestion is indeed the best one in my opinion. Out of all the ideas that were thrown at the old fighting game topic mentioned, this semed the most interesting one, because fighters can be very detailed and smoothly animated at the small cost of background detail directly behind them. I think it's worth it, because we can still have very detailed backgrounds at the top and bottom of the screen. They just need some creativity to look good.

A park with a wide green area behind the players, but with benches, trees, clouds and all that in the distance. A bay type of thing with the sea behind them, but with ships, mountains and so on far away at the top. There are many possibilities for good backgrounds that include a large area of a solid color the player can move in.

[Bregalad]

Yes, 8-pixels movement can look good in some particular cases, but not here.
You'd need several megabytes of CHRROM to do the 8 rotion things, and that'd still be limited.

The only problem with why I mentionned is that it would disallow fighters to jump as high as they does in SF2 for example, but that would look more realistic if they only jump to about half of their size (like people in real life).

[tokumaru]

but that would look more realistic if they only jump to about half of their size (like people in real life).

But in real life people can't throw energy balls at each other either, but that makes fighting games more interesting! =)

I'm not discussing the jump height though, I'm all for making the jumps lower in order to have larger fighters.

Another possible idea that would be less restricting is implementing a smart player rendering system, that will use the background for parts of the player that are inside the safe area but will use sprites in parts that are out of that area. Since it should not be very common to have both players at the top of the screen, the flickering would not be so noticeable.

[Celius]

I agree with what Tokumaru was suggesting. It would really be less noticeable if they jumped above the "safe area" to have sprites for that.

My only concern would be the region that has the BG character. Wouldn't it be really noticeable if there was a whole region with color #0? How would you work that into the map?

Though I suppose you can put objects in the foreground/background that are sprites to make this less noticeable.

So I suggest that each character is donated 128 tiles, one character in the BG and the other in sprites. There'd also be 128 tiles donated to the background. I suppose the remaining 128 tiles in the sprite pattern table would be donated to blood and health bars. I think it would also be a good idea to have the health bars be sprites so you would have more tiles for the background to deal with.

EDIT: Oh, and I think it might be cool to have some characters in the game that are from games we're working on. I think it'd be cool to see the character in my avatar in a fighting game. I have another playable character in my game who's a witch who could also be included.

And also, about what Tokumaru was talking about with the safe area, this would be possible if one character's tiles were on the BG side of the pattern table, because 8x16 sprites can take from both.

[BMF54123]

You guys might be interested in this:

YouTube video
AtariAge thread

An unreleased NES port of "Way of the Exploding Fist," which uses background tiles for the player character. The programmer gives a few details as to how it was done here.

The ROM has been dumped, but I can't remember whether or not it was released to the public... :\

[tokumaru]

Wouldn't it be really noticeable if there was a whole region with color #0? How would you work that into the map?

It would probably be noticeable, yes, but it should be possible to blend that region into the scenery if the graphics were good. The screen could be setup like this (excuse the 5-minute paint work):



There could be some parallax effects at the top, and *some* narrow objects in the foreground, such as that lamppost thing I put there. Unfortunately, in this scene in particular, the fighters must stand on a 2D platform, which is kinda weird for fighting games.

The only way to have that slightly raised angle most fighting games have is by having the background color be the color of what they are standing on. Like Bregalad said, they could be fighting in the middle of the street, and you'd see one sidewalk at the bottom of the screen and the other one at the top, but everything between them is essentially asphalt. In a park, they could be standing on grass and the grass would extend all the way back. If we did this with the water, they'd have to be walking over it. No, no Jesus jokes, I promise.

[SecretServiceDude]

Out of curiosity, how do you handle scrolling only the central area? Do you detect two sprite 0 hits in a single frame (and set the scroll values each time), or is there another method?

Also (sorry for getting slightly off topic), where do you typically place the non-transparent pixel in sprite 0 for an optimal hit response? Do you place it at x=0 on the desired scanline, or do you place it at, say, x=255 on the previous scanline so that you can change scroll settings during the HBlank that immediately follows?

[Celius]

You can't do 2 sprite #0 hits in the same frame, unfortunately.

Without the aid of a scanline counter, a sprite #0 hit would have to be performed to detect the start of the color #0 region. Once this happens, it would have to be timed code to do any more scroll setting. This wouldn't be so bad if somehow you did fixed length routines to time it out. Though if you're doing lots of independent scanline scrolling, you'd probably be better off using a scanline counter.

[Bregalad]

But in real life people can't throw energy balls at each other either, but that makes fighting games more interesting! =)

100% agreed.

I agree with what Tokumaru was suggesting. It would really be less noticeable if they jumped above the "safe area" to have sprites for that.

Maybe just the head of the BG character could be done with sprites (because usually the head is narrow, as opposed to the body), allowing to jump slightly above the blank area and alllowing for more colors.

Code: Select all

There could be some parallax effects at the top, and *some* narrow objects in the foreground, such as that lamppost thing I put there. Unfortunately, in this scene in particular, the fighters must stand on a 2D platform, which is kinda weird for fighting games. 

Well, some narrow object could be made entielely with sprties but this would reduce the limit of sprite to 7, and a character that is only 7 tiles wide when grounded wouldn't be that big (and it'd look weird if they suddently become shorted when grounded, except if that's only by a small amount).
I don't think standing on a 2D background looks weird. It just doesn't look exactly like SF2 does, but who cares ? We'd be making a new game anyway, wouldn't we ?

Do you detect two sprite 0 hits in a single frame (and set the scroll values each time), or is there another method?

Yeah sprite 0 hit + timed code or scanline counter. As tokumaru mentionned before there is only 2 active objects and no collision, so game logic will take few CPU time, allowing for complex raster effects to be made.
You can place the sprite 0 anywhere, but not at pixel 255 because the flag will never be set I belive.

EDIT: Oh, and I think it might be cool to have some characters in the game that are from games we're working on. I think it'd be cool to see the character in my avatar in a fighting game. I have another playable character in my game who's a witch who could also be included.

That's what I intended to say from the start in fact. Everyone could contribute characters from games they're making (but of course with bigger and more complex models).

[tepples]

About graphics, I think making one fighter BG and the other sprite would be a good idea. This would allow characters of about 8 tiles tall and 6 tiles wide, which sounds decent. Various arenas can look good while coming with a blank area in their middle

Or you could use smaller (SMB3 sized) characters, and have them jump onto platforms within the stage to force the other player to attack at an angle.

(it would look wrong if a super realistic fighter would come against a super-SD fighter with the head being half of his size).

It would only look wrong to you when my Lucas evades every single Falcon Punch that your Falcon/Ganondorf tries. Or if my cousin's Toon Link hands your Zero Suit Samus her own behind.
(In other words, it happens all the time in Smash Bros. without looking wrong.)

About controls, I'd be for the standard A=punch, B=kick

Or A=physical attack, B=special.

up=jump, down=duck, and various combination of them allowing more moves (for example upper-cuts) or combos.

And what for guard?

[SecretServiceDude]

And what for guard?

I'd recommend the Street Fighter 2 method, where holding the direction opposite your facing direction invokes a guard. Or hold down + back for a crouching guard.

Mortal Kombat has a dedicated guard button, but the NES hasn't really got the buttons to spare.

[tepples]

I'd recommend the Street Fighter 2 method, where holding the direction opposite your facing direction invokes a guard. Or hold down + back for a crouching guard.

And then the other player can spam weak punch to prevent you from backing up.