NES Dev Collaborative Fighting Game

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Which type of fighting game would you rather see come to fruition?

Poll ended at Sat Dec 06, 2008 9:16 am

Big fighters (think Street Fighter style)
9
56%
Smaller fighters (think Smash Bros style)
7
44%
 
Total votes: 16

User avatar
SecretServiceDude
Posts: 99
Joined: Wed Oct 22, 2008 3:49 pm
Location: Los Angeles, CA

Post by SecretServiceDude » Thu Nov 13, 2008 10:02 am

tepples wrote:
SecretServiceDude wrote: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.
I don't recall that ever being a problem in Street Fighter 2. I think the guard only gets activated if the other player is within attacking range.

In either case, nothing prevents the player from jumping backwards as a means of backing up.

tepples
Posts: 22017
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Thu Nov 13, 2008 11:08 am

Then how are throws done? I could never pull off throws in SF2 on my Super NES. In the game I play more often, throw is guard+attack or attack+special.

User avatar
SecretServiceDude
Posts: 99
Joined: Wed Oct 22, 2008 3:49 pm
Location: Los Angeles, CA

Post by SecretServiceDude » Thu Nov 13, 2008 7:48 pm

tepples wrote:Then how are throws done? I could never pull off throws in SF2 on my Super NES. In the game I play more often, throw is guard+attack or attack+special.
In SF2, throws are usually done by pressing the punch button while holding either forward (to throw the opponent forward) or back (to throw the opponent backward). But you have to be right up against the opponent; if you're separated by more than a small distance, you'll throw a punch instead.

Some of the characters (e.g. Ryu and Ken) have alternate throws that are performed the same way, but with the kick button instead.

Roth
Posts: 399
Joined: Wed Aug 03, 2005 3:15 pm
Contact:

Post by Roth » Fri Nov 14, 2008 9:40 am

How complicated is it to make an entire character out of background and allow for regular movement that doesn't look different from a character that is all sprites?

tepples
Posts: 22017
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Fri Nov 14, 2008 9:47 am

You can allow for full movement through scrolling, but you're limited to 16x16 pixel color areas.

User avatar
Bregalad
Posts: 7889
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Fri Nov 14, 2008 9:53 am

This isn't complicated, but just that background only allows 16x16 color definitions and doesn't allow any flipping, tiles have to be aligned on a 8x8 gird too. Using only sprites it's possible to cheat and using misaligned tiles to optimize tile usage, but that won't be possible in that case.
If we don't want to store each character two times in the CHRROM, it'd be good to have the one watching in one direction always BG and the one watching in the other direction always a sprite (using horizontal flipping).

Also it'd be good to have some way of uploading the BG character in nametable in a single VBlank, maybe 2 if this simplifies things (split top/bottom, but that will introduce some minor artifacts I guess).

That way, when a character jumps over another, they imediately switch the direction they're watching (as in SF2) and the BG character and sprite characters immediately get swapped.
Life is complex: it has both real and imaginary components.

Roth
Posts: 399
Joined: Wed Aug 03, 2005 3:15 pm
Contact:

Post by Roth » Fri Nov 14, 2008 11:13 am

Does this mean that every character would also require having all background tiles for all the fighting scenes in their 4k chunk of space? If so, wouldn't this severly limit how many scenes we could have, and/or how many moves the characters themselves could perform? Forgive me if these aren't the best questions, but I'm trying to get some sort of planning in my head for how data would be set up.

User avatar
Bregalad
Posts: 7889
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Fri Nov 14, 2008 11:20 am

Yes, but thanks to CHRROM you can switch different banks in that 4kb at different times so this is really not a big deal.
Life is complex: it has both real and imaginary components.

User avatar
tokumaru
Posts: 11755
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Fri Nov 14, 2008 2:30 pm

Bregalad wrote:If we don't want to store each character two times in the CHRROM, it'd be good to have the one watching in one direction always BG and the one watching in the other direction always a sprite (using horizontal flipping).
This is a very good idea! There is simply no extra ROM cost then.
Also it'd be good to have some way of uploading the BG character in nametable in a single VBlank, maybe 2 if this simplifies things (split top/bottom, but that will introduce some minor artifacts I guess).
With optimized code, it's probably possible to do it in 1 VBlank, since there is not much else going on. The scrolling is just horizontal, and depending on the nature of the background, VRAM updates might not even be necessary. Sprite DMA is required, as are occasional palette updates.

But even if for some reason it has to be done every 2 VBlanks, since there are 2 name tables it's possible to draw the new tiles to the half that is not on screen, and only show it when the fighter is complete. Double buffering, essentially. Note that this wouldn't even make the game any less smooth, because the fighter can still be moved around, only it's animations will be restricted to 30FPS, which is still more than the typical animation.
That way, when a character jumps over another, they imediately switch the direction they're watching (as in SF2) and the BG character and sprite characters immediately get swapped.
Right. and with priority control it's possible to maintain one in front of the other consistently even when they switch sides, so that a person playing the game will have no way to tell what's happening. Most fighting games have the players always facing each other, which is a requirement for this trick to work.

User avatar
Bregalad
Posts: 7889
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Fri Nov 14, 2008 2:37 pm

But even if for some reason it has to be done every 2 VBlanks, since there are 2 name tables it's possible to draw the new tiles to the half that is not on screen, and only show it when the fighter is complete. Double buffering, essentially. Note that this wouldn't even make the game any less smooth, because the fighter can still be moved around, only it's animations will be restricted to 30FPS, which is still more than the typical animation.
Yes, but you'd want to be sure the fighter is never partially outside of the screen to do this. Using the normal method (only one image in one nametable) allow the character to be partially outside of the screen, there will be proper blank data from the other nametable. This is not a big issue tough as we'd hardly want to do that. What you describe is probably the way to do it in fact.
With optimized code, it's probably possible to do it in 1 VBlank, since there is not much else going on. The scrolling is just horizontal, and depending on the nature of the background, VRAM updates might not even be necessary. Sprite DMA is required, as are occasional palette updates.
Yes, SpriteDMA+Palette is compulory (palette updates will probably be needed instantly when player switch their directions), and only minor nametable updates like score and lifebar will be intervealed with the heavy BG fighter nametable updates. The playfield would probably never change, exept for maybe some palette effects or tileset effects if CHRROM allows it.

EDIT : About priorities, in SF2 it seems the attacker is always in front and the guy being attacked behind. In that case, the sprite has to set it's "behind BG" flag if being attacked, and clear it otherwise. That should fix the priority problem.
Life is complex: it has both real and imaginary components.

User avatar
Bregalad
Posts: 7889
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Wed Nov 19, 2008 12:41 pm

Okay now let's start something serious before this threads vanishes, ok ? I guess everyone comes with pretty good ideas so it'd be a shame to just let this project being forgetten forever.
Life is complex: it has both real and imaginary components.

User avatar
Memblers
Site Admin
Posts: 3858
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers » Wed Nov 19, 2008 2:51 pm

Bregalad wrote:Yes, but thanks to CHRROM you can switch different banks in that 4kb at different times so this is really not a big deal.
We've got 2 midframe scroll points (3 with a status bar), where we can also swap BG/SPR tile usage. If 2 players + level fit in 8kB, you could get by with 8kB CHR-RAM. Having the upper part of the screen at $0000 and the lower part at $1000, background tile usage could be divided somewhat equally.

I think the game is more likely to get done if we have a limited amount of graphics that we can easily fill up. Because not everyone will want to work on character design for months.

Celius
Posts: 2157
Joined: Sun Jun 05, 2005 2:04 pm
Location: Minneapolis, Minnesota, United States
Contact:

Post by Celius » Wed Nov 19, 2008 4:44 pm

How are we going to count to these scroll points? Will we use something like MMC3 or MMC5's scanline counter? I suppose we shouldn't use MMC3 if we want to take sprites from both tables and use 8x16 sprites.

User avatar
Memblers
Site Admin
Posts: 3858
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers » Wed Nov 19, 2008 5:21 pm

Celius wrote:How are we going to count to these scroll points? Will we use something like MMC3 or MMC5's scanline counter? I suppose we shouldn't use MMC3 if we want to take sprites from both tables and use 8x16 sprites.
Sprite #0 hit, followed by timed code. Status info would need to be sprites, then. We'd be using a lot of CPU time with delays, but I think there would be plenty to burn.

User avatar
tokumaru
Posts: 11755
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Wed Nov 19, 2008 5:45 pm

Memblers wrote:Sprite #0 hit, followed by timed code.
What time would there be to update the game logic? Only after the background player is finished? That's too little.
Status info would need to be sprites, then.
Say bye bye to the horizontal health bars...! I hope this game gets something more original then.

Also, there are the parallax effects at the top to consider. If the end of VBlank can be detected (when the sprite hit flag clears), the status bar and the background at the top could have as many raster effects as necessary with the use of timed code.

In fact, if CHR-RAM is used, you might just as well get rid of the whole background player thing, because if all the graphics have to fit in just 8KB, you can bet these sprites will be really small! The whole point of the background player is the possibility of large fighters.

IMO, what we've discussed so far is not a simple UNROM project. A fighting game with large fighters and lots of parallax effects is just not suited for UNROM. Not saying UNROM isn't a valid choice for a good game, but what we've discussed so far and UNROM games are very different things, just keep that in mind if you take that route.

Post Reply