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

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

Post by Celius » Wed Nov 19, 2008 8:59 pm

For health, the sprites can still be horizontal/made out of sprites They just can't be on the same scanlines. You could stack one on top of the other, or have one 8 pixels higher than the other. Though you'd probably be better off stacking if you're going to use sprites.

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

Post by Memblers » Thu Nov 20, 2008 12:19 am

tokumaru wrote:
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.
I figured most of the time would be what remains of vblank + the top of the screen. Bottom of the screen I figured could run something else if needed. But, the weird thing is that the time for the delay depends on the height of the playfield (or how high they can jump)..!

I didn't consider parallax effects, I guess with my plan it'd only work on the bottom, which wouldn't be as useful.

I admit that ~192 tiles isn't much to make a big animated character with. Using (for example) 7x3 size allows for 9 animation frames. Which is like the bare minimum. I think double that would be better, I don't know if I'd want to draw more frames than that. Certainly then, banked CHR would help out. How about 6kB for characters and 1kB (64 tiles) for background? The main thing I like about the background player is that we should have no sprite flickering whatsoever (excepting maybe 2+ player missiles on-screen).

I guess it is my approach then that I think the simplest ways are good. As simple as possible, actually, because it makes the project most likely to succeed.

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

Post by tepples » Thu Nov 20, 2008 4:38 am

tokumaru wrote: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.
Which demonstrates my idea: make the fighters about 28px to 32px tall (the size of Mario from SMB3, Link from Zelda II, Simon from Castlevania, Samus from Metroid, or Batman from the first Sunsoft game), and the backgrounds could be better used for tactical obstacles. Just make sure the hit detection is better than that of Shaq Fu.
Memblers wrote:I guess it is my approach then that I think the simplest ways are good. As simple as possible, actually, because it makes the project most likely to succeed.
Would it be simpler to have big characters and Street Fighter mechanics or small characters and Smash Bros. mechanics?

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

Post by Memblers » Fri Nov 21, 2008 3:19 pm

tepples wrote:
Memblers wrote:I guess it is my approach then that I think the simplest ways are good. As simple as possible, actually, because it makes the project most likely to succeed.
Would it be simpler to have big characters and Street Fighter mechanics or small characters and Smash Bros. mechanics?
I think it'd be cooler to have big characters. I haven't played Smash Bros. yet (I did just now check out some vids, that hardly counts), my experience with fighting games ends after Mortal Kombat 2. So I can't comment much on it. Looks fun though.

I'm just trying to imagine how detailed the characters will need to be. It's kind of interesting to think that we'll be stuck with mostly 4 colors (and on 16x16 grid for palette!). Really big chars would be cool because noone has done it on NES, and I always thought it'd be cool to make a cart with a really huge CHR-ROM (sky is the limit, we can realistically do CHR-ROM size on a Neo-Geo scale with today's memory chips). It's just A LOT of data to create.

Accent sprites for extra colors, that'd be 2 per scanline (1 per player)
A single 8x8 player missle (multiplexed for more/larger)
That leaves us with 5 sprites, 40 pixel width, and improved color selection.

I'm just throwing out numbers here. :)
The sooner we can have a sprite size determined, the sooner we can get started.

Using accent sprites extensively, and player-unique missile sprites, might call for the use of banked CHR-RAM. If there were enough characters, there's all those loading combinations..

The NES wasn't designed to be used like this. :twisted:

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

Post by Bregalad » Sat Nov 22, 2008 2:39 am

I guess it is my approach then that I think the simplest ways are good. As simple as possible, actually, because it makes the project most likely to succeed.
Probably, but the people here seems more excited when something evil is planned than when something 100% standard is.
Which demonstrates my idea: make the fighters about 28px to 32px tall (the size of Mario from SMB3, Link from Zelda II, Simon from Castlevania, Samus from Metroid, or Batman from the first Sunsoft game), and the backgrounds could be better used for tactical obstacles.
Why not, but then it'd be more like a Beat 'm' up than a fighting games, which I'm not against. The BG player is just an insanely cool thing ;-) But after all we've all seen BG ennemies in Final Fantasy and Dragon Warrior games (as well as bosses other games).

I also haven't played Smash Bros (I have no gamecube), but I guess my bro in law have that game so I could ask him to show it to me. I played Street Fighter and Tekken games much more so I can refer only to them when talking of "Fighting Games".

Also I think making bigger "sprites" (bigger characters) does not imply that this should be harder than making them small. When dealing with something huge you can go away without worrying about each single pixel, something you couldn't hope to do on smaller pixel arts. Personally I guess it'd take a while to figure how to draw a character that throws someome with very small size constraints. It'd prbably not be very easy to make it big, but at least you get rid of the size constaints.

Using a new custom-made mapper could allow us to do anything, but the problem is to test it.

About the size, I think to have more realistinc graphics it sounds like required that not all characters are equally the same size, just like not all humans are the same size. But no characters should be twice the size of anyother too. I guess there should be a fixional reference "giant" that should be the greatest and largest possible character.

I guess the biggest possible should be about 6 tiles wide and 9 tiles height. When grounded, this becomes 8 tiles wide (by squeezing the 9 a little so no flickering is appearing) and 6 tiles height (rotated as before).
This would allow for smash effects or energy balls, that would barely flicker in the worst conditions, that isn't that bad with decent sprite cycling algorithm.
And it's not that huge. To get about 20 frames of animation, that's theorically 1080 tiles, but I'm pretty sure a lot could be re-used between frames of animations. A character could probably fit largely in 512 tiles, which is 8kb. Then assuming each background arena takes 2kb, that would allow up to 10 characters+arena in a simple 128kb CHRROM, which is good, leaving good room (28kb) for title screen, font and various other graphics.

About raster effects I guess that'd not be hard to pull out, as Tokumaru mentionned that few CPU time will be dedicated to game logic, because there is very few active objects (2 in fact, exept maybe energy balls).
We could do a timed VBlank so that the status bar doesn't scroll, the top background scrolls at a slow rate, the fighters scrolls as they move, and then the bottom background scrolls at a faster rate.
Since the top background could probably be large, a part of the game logic could be ran here, and a sprite zero hit could be used to re-sync the programm with the screen for the bottom raster effects. That doesn't sound hard to do to me.
I guess all of that could easily fit a simple SLROM board, that could also allow easy reproductions of the game. Using a more advanced mapper would imply deal with CPLDs and all of that. Also switching 4kb at a size is an advantage when doing raster effects, because this make it less likely to get graphic glitches (as opposed to do slow 1kb, 1kb, etc... switching as on the MMC3). Or we could always come with a custom made mapper that allows insane CHRROM but that switch 4kb at a time.

The project would likeley require a boss, and stuff like characters size, mapper constraints, etc... would be dedicated to him. If people disagrees, they could just not contribute to the project and make their own games or cooperative project. Altough it sure wouldn't be good if everyone ends up with 10 different cooperative figthing games projects ;-)
I guess Roth chould be the boss, as he started the thread and seems to have loved the idea of a fighting game.
Useless, lumbering half-wits don't scare us.

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

Post by Roth » Sat Nov 22, 2008 9:09 am

Man, I really want this to happen for sure. The main reason I haven't posted recently on this thread is because, to be completely honest, alot of the ideas that are here are way out of the scope of my knowledge of dev right now.

I love the idea of the big fighters, and I also love the idea of the smaller Smash type fighters. Maybe I should edit the first post with a poll that runs about 2 weeks to see what everyone thinks? It'd be alot easier to see instead of reading back on every post and count up what people would like to do.

User avatar
clueless
Posts: 498
Joined: Sun Sep 07, 2008 7:27 am
Location: Seatlle, WA, USA

Post by clueless » Sat Nov 22, 2008 12:13 pm

What about using 8x16 sprites? Would that help matters any?

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

Post by Memblers » Sat Nov 22, 2008 12:33 pm

If we use 6x9 tiles as the maximum size, that's 54 of our 64 sprites. That leaves enough for sprite #0 and some effects/objects, so it's nearly as big as we could go.

8x16 sprites might not be useful. The pattern-table interleaving would call for more complex CHR bankswitching.

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

Post by Celius » Sat Nov 22, 2008 1:32 pm

I seriously am all for using 8x16 sprites. The main two reasons: half the tile usage for metasprites (with a few exceptions), and the ability to take from both pattern tables.

EDIT: And we've decided to use CHR ROM, pretty much. So each character will be designed facing either left or right in the pattern tables (let's just say left). So any character who's facing left is BG. The other character is made of sprites. The characters are never facing the same direction. Each player is designed as if they were part of the BG. So even sprite characters are designed using 16x16 pixel color blocks so if they are part of the BG, they won't look different. I don't think we've decided on a specific mapper or size. Though I see that 128k CHR ROM seems to be what some people want. Is there a safe area where if the BG player jumps above it, their head will be made of sprites? 8x16 sprites would allow this by taking from 2 different pattern tables, and it would be doable with less sprites.

I do think that we should still do sprite cycling techniques, even if we don't want flickering at all. However, IF for any reason there are more than 8 sprites per scanline, you'd want some cycling to happen and not have SMB1 type things happening.

Before moving on, we should resolve these issues completely:

Character size
Number of animation frames per player
Pattern Table space distribution

I know it's what we're talking about, but I'm just saying, before moving on, they should be resolved. I'm for 8x16 sprites, something like 5x8 characters, 3 or 4 frames per move (like a punch), making about 16 to 20 frames for each player. If we use CHR ROM bankswitching, we can have about 3 frames frames of animation in each 2k section. And we should have something like all the punch frames in one 2k section, and the kicks in another, etc. And of course, have an integer number of animations in one chunk; you don't want half an animation in one chunk.

Is 2k CHR ROM bankswitching even an option?

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

Post by Bregalad » Sat Nov 22, 2008 2:38 pm

I'm for big characters, but if everyone decides to go the small way I'd still like to contribute characters as well.

Well, I don't think it does much difference between 8x8 or 8x16. Allowing sprites from both pattern tables isn't much a requirement when working with CHRROM in that way. The only real difference is that 8x16 implies arranging them so that tiles comes in couples (this is easily doable in Tile Molester), and that it would allow twich as much sprites on the screen. Tile usage is less optimal, but in that case it doesn't matter, as the animation will be made to be possible to do on a 8x8 girded background.

Altough there sure would be 20 frames of animations for big fighters, I'm pretty sure things like the legs wouldn't move much for a punch (maybe they'd move slightly I don't know), etc...
Exploiting this would allow to reduce the number of times considerably. This would make larger chumks of CHRROMs swapped at a time more versatile, as you'll less likely copy identical tiles into different banks. But multiple smaller CHRROM switching can equal one big switching, but it increase the chances to get graphical glitches.
Useless, lumbering half-wits don't scare us.

Bananmos
Posts: 532
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Post by Bananmos » Sat Nov 22, 2008 2:57 pm

Reading this thread, I can't help but think that people are perhaps getting a little *too* excited about doing as large characters as possible. :)

Sure, using more pixels for characters allows for more detail, but when I think back about the NES games I consider to have the most detailed graphics, the trait they all have in common is using multiple sprite palettes rather than just sticking with the 3 colors available in a single sprite palette. Mega man does this and wouldn't be high-rated in the graphics department without it. Radd Spencer in Bionic commando wouldn't be very convincing either. Heck, even the simple white in the characters' eyes in SMB2 makes them look a lot more colorful than the Doki Doki Panic characters.

And as far as my own favorite game goes, Battletoads' presence *and* lack of this is pretty telling. While I prefer the gameplay of the first game, all enemies look pretty crappy compared to the toads themselves. Even if the gameplay is weaker in Battletoads and Double Dragon, the graphics are superior just because they spent as much time cramming more than 3 colors into the enemies as well.

Thanks to these games, I could never have imagined that NES sprites were limited to just 3 colors as a kid. So rather than going for the largest characters possible, why not settle for medium-sized characters and dedicate an extra sprite palette to each characters than can be used to add small details to them?

With this method you would have one "base palette" for each character, which would be switched between being a sprite palette and a BG palette just like proposed, and then an extra palette for details. For a typical Ryu/Ken style character, you could make the base consist of the clothes, while the detail palette could be used for the head, hands and feet.

This method would use a total of 3 sprite palettes (1 base + 2 detail) and 1 BG palette (the base for the BG character), leaving 1 sprite palette and 3 BG palettes left to play with. Of course, you'd need to settle for somewhat smaller characters, but I really think this will look a lot better. 3-color characters usually look very bland, no matter how large they are. :)

User avatar
clueless
Posts: 498
Joined: Sun Sep 07, 2008 7:27 am
Location: Seatlle, WA, USA

Post by clueless » Sat Nov 22, 2008 3:07 pm

Would it be possible, with timed code or a custom mapper, to switch name tables half-way through each scan-line? So that the left side of the screen comes from one name table, and the right side comes from the other? Then any graphics that would need to extend over the boundary would be done with sprite overlays?

I'm not an expert here. I'm just proposing an idea. However, I am unsure if it would work. I seem to remember that to stay in the same pixel column on the screen, but drop down one row, the game would need to delay a fractional count of cpu cycles.

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

Post by Bregalad » Sat Nov 22, 2008 3:17 pm

Hmm, Baranmos is not all wrong. It would probably be an idea to have a constant skin-colored sprite palette, and have all arms, feets and heads drawn with it. However this increases complexity and chances of flickering, but maybe it'd be a good deal overall, even if the character would be smaller "only" 3-4 tiles wide. Since only arms, legs (which are mainly vertical) and head (which is small) would be drawn with sprites on both sides, they could take 2 tiles horizontally, leaving 3 for the body of the sprite fighter and one for effects, but then the fighter would only be slightly larger than normal games (but still without flicker).

Also this would be complicated if a non-human character or non white skinned human were to be introducted, as the skin color couldn't be much of usage.
Useless, lumbering half-wits don't scare us.

Bananmos
Posts: 532
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Post by Bananmos » Sat Nov 22, 2008 3:29 pm

Also this would be complicated if a non-human character or non white skinned human were to be introducted, as the skin color couldn't be much of usage.
But the point is you wouldn't need to limit it to using the same "skin palette" for both characters. Like I said in my post, there's enough palettes to let each character have at least a base palette and a "skin palette". (though keep in mind it doesn't have to be used for the skin, if a character fights in shorts, you'd probably want to have it the other way around and use the base palette for the skin :)

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

Post by Celius » Sat Nov 22, 2008 3:36 pm

About switching mid-scanline, it's really not worth it. It would require so much annoying effort to try and do that, and you wouldn't end up with pretty results. I've often wondered about vertical split screen effects, but they're really hard to do.

I too will be fine if we stick with smaller characters. It just seems like everyone wants large characters. What Bananmos was suggesting is a good idea, I think. I do this for my portraits in my game, where I have details made with sprites and the "base" part made with BG. Though I use multiple palettes for the base part.

EDIT: You might not want to assume that each character will have lots of skin showing. Look at the character in my portrait. He has only his face and hands showing. The rest is a brown coat. Actually, that character is only made of 3 colors, and I don't think it's horribly obvious. Though you can tell by looking at it. He wouldn't require many palettes.

Post Reply