This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

NES Dev Collaborative Fighting Game

NES Dev Collaborative Fighting Game
by on (#39817)
Alright, there is now an option to vote for which everyone would rather see done. Right now the poll is set to run for 2 weeks, but if anyone feels that more time is needed, speak up : )

The poll is pretty self-explanatory I think. Out of the two styles of fighting games, which appeals most to everyone?




ORIGINAL POST----------------------------------------
TITLE: Collaboration

Hey guys, I was shot down in #nesdev about this, but I guess I should go ahead and talk about it here.

I would like to collaborate with some of you in a game. I have no set topic about the game, I have no storyline, etc. I just know I would like to make a game with some of you. If anyone has an idea that they think is out of the scope of their own ideals, or an idea that you would rather not embark on themselves, then please post it here. I am more than willing to work with any one of you because it seems there are alot of good ideas, but no one (or not many) willing to go the distance.

I just would like to make a game that is at least playable by the masses, and have some fun with it. I'm not picky about anything. I just want to have some fun, guys : )

by on (#39818)
I know it really sucks, but if I were to collaborate with people on this, I couldn't do much programming. I am capable of programming, I just don't have much time. I would, however, be able to contribute by coming up with formats for things, like level compression and AI. I would be able to contribute conceptually for the engine, mostly.

by on (#39819)
I've collaborated with others on game projects in the past, and it hasn't really been successful thus far. It seems there are always problems with conflicting schedules, varying levels of availability/commitment, and some team members pulling more weight than others. Then there are the inevitable design conflicts that come from having "too many cooks in the kitchen".

Roth, you sound like a really cool guy. I admire your enthusiasm and don't want to shoot it down. I just find that working alone (or with one or two friends who can help with music, etc.) carries the least amount of overhead.

Having said that, I really enjoy the community here, and am perfectly willing to contribute in other ways. For example, if I write a tool or a section of code that others could benefit from, I'd be happy to submit those.

by on (#39828)
I've done some collaborative projects with a group over the internet before, 2 programmers, 1 artist, and 1 musician, and things came together pretty well. Art and music is pretty easily independant, but code can be a little challenging. It's good when you can modularize the code. e.g. one person does sound code, another does AI/ character interaction, another does tools, etc.

I guess in a way, if we use any libraries/code like the famitracker driver its a collaborative effort.

by on (#39830)
Insteresting, yet I have to comlete my game :cry:
I have several ideas for other NES games I'd like to be making in the future, maybe that'd be great if people collaborate, but it would make things easier if they collaborate from the begining I guess. It would probably hard to include new people to a project I started alone.

EDIT : What about a fighting game where everyone could contribute one or more of his characters ? So that it would have protagonist from most known homebrew NES games :wink:

by on (#39838)
Ooh, interesting idea Bregalad! A fighting game is something that I have actually talked to some of my friends about, and they all thought it sounded like a cool idea since there aren't many on the NES. That Yie Air Kung Fu (whatever it's called) and TMNT Tournament fighters are the only ones that come to mind. I think a fighting game would be a friggin' GREAT idea to run with!

I also understand everyone wants/needs to finish their own games, I am in the same boat with Elusion of the Dead. But in the near future, I would really like to work with other people, because to me it just seems like it would be more fun to do so.

I just think it would be really cool if we could break past the barrier of the whole "me me me look at my game," and progress forward to the "Hey, look at what WE did." I don't know, just a thought.

by on (#39846)
Quote:
I just think it would be really cool if we could break past the barrier of the whole "me me me look at my game," and progress forward to the "Hey, look at what WE did." I don't know, just a thought.

You're probably not all wrong, but I see a little problem : For my game I have my ideas and some things I saw about it since I started it 3 years ago, and if someone else came to help me to do the graphics and some programmings, I wouldn't say no. But if he imposed some of his ideas to be I would be somewhat annoyed, because I'd be afraid in the end the game wouldn't be as I originally wanted to. Maybe I'm comletely wrong on that one but oh yeah.
Typically I'd refuse that anyone would impose me to use fami tracker or nerd tracker, I want to use my own sound driver for my games because I have personal reasons to do so (it's more optimal, and I love writing sound drivers).

However, I'm not against contributing something for a game of someone else, I couldn't be frustrated because someone modified my game because it's not my game anymore (I'd only contribute small parts of it).

And yeah, the fighting game sounds like a cool idea, as discussed once before it shouldn't be too hard to programm, it could still do impressive/innovative graphics for the console, and it would be easy to split tasks with characters, and include various characters from various authors. Also, nobody would be able to make such a large fighing game on their own because you'd need to create so many characters and attacks. It would be like a NESdev tournament/competition. This sounds exiting.

by on (#39851)
Roth wrote:
A fighting game is something that I have actually talked to some of my friends about, and they all thought it sounded like a cool idea since there aren't many on the NES. That Yie Air Kung Fu (whatever it's called) and TMNT Tournament fighters are the only ones that come to mind.

Kart Fighter was a Hong Kong Original attempt at Smash Bros. before Nintendo decided to make one of its own. And surprisingly, it sucks less than some other HKO fighters.

by on (#39860)
It'd be interesting to work with others on a project. I could contribute to the programming part, but I can't draw very well and still haven't learned to compose music.

by on (#39869)
If there ever would be a community fighting game, I call dibs on Squeedo del Tepton being the "Goro" of the game. :) No guarantee of quality character design though.

I'd be thrilled to do any sound work for any game project. I know there's a lot more talented musicians than me out there, though. It was a lot of fun to do the sound for Solar Wars. It was a bit stressful at the time, but infinitely rewarding.

The most collaboration I've done has been more of an advisory role. I imagine it'd be rare that a couple people could do much work on the same program like this (where all of it so tightly interwoven). Not without constant communication, like being in the same room.

My NSF Player for example, I could have (and did) make it all by myself (not the compression code, Rob Northen's), except for a couple extremely crucial math problems, and kevtris coded the solution to those. My other point being that a little bit of collaboration can go a long way.

by on (#39913)
Memblers wrote:
The most collaboration I've done has been more of an advisory role. I imagine it'd be rare that a couple people could do much work on the same program like this (where all of it so tightly interwoven).

Collaboration becomes easier if the developers 1. document the API to each part of the engine in detail, and 2. use some sort of version control and automated rebuilds like Mozilla does. I'm pretty sure the music teams on commercial NES games used technique 1, as a lot of games' music engines are pretty much self-contained. Likewise, CHR and maps can be developed fairly independently of code: see all the ROM hacking tools out there.

Quote:
Not without constant communication, like being in the same room.

By "room", do you mean "channel"?

by on (#39938)
Okay, well, let's start running with ideas here!

Let's say we go ahead and start thinking about a fighting game. Everyone is welcome to introduce their character(s) into the mix, with the limits of whatever mapper is chosen (size-wise, I mean).

If we do this, then we should probably set a max number of sprites that a character can have. 5 sprites tall, 3 sprites wide? 5 or 6 tall, 4 wide? I'd like to hear some input on this. We can incorporate the flicker thing of course, but I'd like to know what others think would be best for this kind of game (think of the moves like jump kicks, etc.)

Palettes. Does it sound reasonable to allocate 6 colors (1 1/2 sprite palettes) to each character? This could leave room for more sprites for score, how many times they've been beaten, etc.

Moves. Should we set a definite way that the moves should be made? Like, should we only allow for certain button combinations, or let people run wild with their ideas on button combos?

Are there any particular people that would like to do certain things? Like, backgrounds, the sprites themselves, music, etc. I see Memblers has already said he likes to do sound.

This could be really cool. I'd like to hear all sides, here.

by on (#39941)
If you make a fighting game, you'd want to have larger sprites. You'd definitely want to use 8x16 sprites for this reason. I think 6x4 sprites sounds like a reasonable size for metasprites. With 8x16 sprites, you can get taller sprites using less. But you probably don't want to do much sprite layering, as you'd interfere with the limit of 8 sprites per scanline a lot.

Thankfully for backgrounds and the title screen, you could fit those all into one bank. I'd also suggest having like a 64x30 tile arena (2 screens wide, 1 tall). That would be easy enough.

The most difficult challenge would be making a decent fighting game with only 2 buttons. I suggest that up would be jump. Would you have lots of combos? I would probably have pre-defined combos, but a lot of them for individual characters. It would be easier to program.

by on (#39942)
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 (for example a street that has a grey area in the middle, a forest that would have a plain grass area in the middle, etc, etc...). I wouldn't mind minor flickering, but the game should look as good as possible. Using 8x16 sprites seems like a good idea, too.

About sound, I'd agree to do some music but I'm inexperienced in composing rock/techno oriented music (I could easily get inspired by existing music though).
I guess everyone can contribute characters with their graphics, arenas, music themes and controls, but some work should be done in order to come with cohesion between them (it would look wrong if a super realistic fighter would come against a super-SD fighter with the head being half of his size).

About controls, I'd be for the standard A=punch, B=kick, up=jump, down=duck, and various combination of them allowing more moves (for example upper-cuts) or combos. I'd be against using select or start during gameplay (for something else than pausing the game).

Arenas of 1 screen tall and 2 screens wide sounds perfect to me.

EDIT : If a project like that is actually done it'd be great to actually have an official blog/wiki/webpage about it or something like that. Just posting here in the bbs will make things unorganized, but yes we should first have some brain-storming before actually starting of course.

by on (#39943)
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 would create a sweet parallax effect like the one used in Street Fighter 2 on the SNES (or the bonus stages in Battletoads in Battlemaniacs, also on the SNES).

by on (#39944)
SecretServiceDude wrote:
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.

by on (#39945)
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.

by on (#39946)
Celius wrote:
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. :)


Celius wrote:
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.

by on (#39947)
SecretServiceDude wrote:
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!

Quote:
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.

by on (#39949)
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).

by on (#39967)
Bregalad wrote:
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.

by on (#39968)
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.

by on (#39977)
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... :\

by on (#39980)
Celius wrote:
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):

Image

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.

by on (#39983)
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?

by on (#39984)
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.

by on (#39985)
Quote:
But in real life people can't throw energy balls at each other either, but that makes fighting games more interesting! =)

100% agreed.

Quote:
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:
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 ?

Quote:
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.

Quote:
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).

by on (#39988)
Bregalad wrote:
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.

Quote:
(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.)

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

Or A=physical attack, B=special.

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

And what for guard?

by on (#39990)
tepples wrote:
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.

by on (#39993)
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.

by on (#39996)
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.

by on (#40008)
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.

by on (#40038)
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.

by on (#40053)
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?

by on (#40054)
You can allow for full movement through scrolling, but you're limited to 16x16 pixel color areas.

by on (#40056)
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.

by on (#40058)
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.

by on (#40059)
Yes, but thanks to CHRROM you can switch different banks in that 4kb at different times so this is really not a big deal.

by on (#40062)
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.

Quote:
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.

Quote:
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.

by on (#40063)
Quote:
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.

Quote:
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.

by on (#40187)
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.

by on (#40188)
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.

by on (#40189)
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.

by on (#40190)
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.

by on (#40191)
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.

Quote:
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.

by on (#40192)
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.

by on (#40193)
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.

by on (#40194)
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?

by on (#40221)
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:

by on (#40229)
Quote:
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.
Quote:
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.

by on (#40237)
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.

by on (#40243)
What about using 8x16 sprites? Would that help matters any?

by on (#40244)
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.

by on (#40245)
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?

by on (#40247)
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.

by on (#40248)
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. :)

by on (#40250)
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.

by on (#40252)
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.

by on (#40253)
Quote:
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 :)

by on (#40254)
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.

by on (#40255)
Bananmos wrote:
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. :)


I definitely agree, that's what I called the "accent sprites" earlier. I think we should allow for it. The max width of the character then is up to how many accent sprites that you use (per line!). I think we don't necessarily want all characters to be the same size, and with different artists working separately, the proportions are likely to be all different anyways. We need some base models.

by on (#40256)
Things can't be "kicks and punches" only. Think about a MegaMan character firing against Leonardo, from TMNT, and he can block the shots using his Katana. ;)

by on (#40258)
Yeah, I just voted for Smash Bros. style... I guess I couldn't resist the though of having platforming elements in a fighting game! =)

Seriously though, I get Membler's point about keeping it simple. I still think a SFII fighting game would be prety easy to program, but I agree that drawing the graphics would take a lot of time. OTOH, platforming elements might increase the complexity of the project a bit, but that might be worth it.

Anyway, keeping the fighters small would make it easy for everyone to include their own characters, as it wouldn't take forever to draw all the frames. Though I still think that having all the frames in just 8KB of CHR-RAM would be pretty limiting, so I keep voting for CHR-ROM, in spite of the smaller characters.

I have a couple of characters from unfinished (for now) projects I could consider including in the game.

Memblers wrote:
We need some base models.

We should probably post pictures of the characters we plan to put in the game, so that everyone can have an idea of what we're dealing with.

by on (#40259)
I'd like to include these characters:

http://www.freewebs.com/the_bott/CeliusNESPortrait.bmp
http://www.freewebs.com/the_bott/LeahNES.bmp

Celius is the first one, and Leah is the one below that (though I might change her name to Lelia). If I submit Leah, she'd be wearing a coat and possibly a witch hat, as she's a witch.

by on (#40260)
I would probably have to go with Skeleton Joe or one of my nameless worms, as I obviously can't use Sonic.

Joe: Image

Worms: Image

Most of us will have small sprites already, but would need to draw larger ones if that style is chosen. Personally, I have ZERO time to dedicate to this thing right now, but I really would like to see where it goes.

by on (#40264)
Quote:
Actually, that character is only made of 3 colors, and I don't think it's horribly obvious.

Yeah, but it seems that it is on a black backround, that you didn't include in your color count. If a sprite is 3 colors on a black background (like Final Fantasy battle sprites or Contra bosses of stage 5 and 6), it will look terrible if pasted on a random background because there is no black outinles. If you add black outlines, you get a 4th color and this can't be done with only one layer.

But I agree it should be possible to make characters with only 3 colors without it being obvious, especially since due to their large size, a heavy usage of lighning and dithering could be easily done.
And I don't think drawing larger characters should take more time than drawing small ones. You have less to worry about tiny details, and each single pixel won't change radically the end result, like it does for small images.

Quote:
Most of us will have small sprites already, but would need to draw larger ones if that style is chosen.

It's very easy to enlarge a sprite (Tile Molester does that very easily), and then remove the blocky "metapixels" and replace them by staight curves. It will look identical, but bigger. You're also free to add detail and dithering where you want, and you'll end up with handsome big sprites. I've done that to create portraits of my characters, based on their regular sprites, so that I'd be sure their face would be the same shape.

I have at least 2 characters to submit right now, Lucia and a yet unnamed boss that can bee seen on that Screenshot (sorry I'm too lazy to rip the sprites apart right now) :
http://jonathan.microclub.ch/rainbow/images/drgskill/drgskill_009.png
Also the sprites are obsolete, I've made them smaller since them to gain some CHR space, but still conserved the old bigger version in case of.

Their more detailed portraits (made from the small sprites like I mentionned above) can been seen here :
Image

by on (#40272)
My character just happens to be against a black background. He is really outlined in black. The only other two tones used in the sprite are for skin color and coat color. Though the coat color is also used for the hair, and the skin color is also used for the fur outlining the coat.

See the link to the portraits of my characters. He is against a blue background this time.

by on (#40273)
Oh my your portraits are so realistic as opposed to mines. This makes me feel a little bad, but whathever. I really belived your sprite had a darker brown color too, it looks like so on the avatar. Probably because it was scaled down ?

by on (#40274)
I don't think my portraits are realistic. And I like your portraits, especially the guy on the right. They may be more defined because they're 64x96 pixels, though.

The color may be different because they're from different emulators. The portrait is from Nestopia, my avatar is from FCEUXD. I hear that brown shows up really different on different emulators, so I'll have to make sure I'm using one that doesn't look bad on any emulator.

by on (#40308)
Not trying to be pessimistic here... but I kind of doubt this concept of using avatars from homebrewn games by programmers who double as pixel artists will give us enough content to keep this project from becoming a sitting duck.

I think most people working on their homebrewn games here would focus on working on those homebrews rather than being distracted by another project. And why shouldn't they? There's hardly any point of having the hero of your own homebrewn game as a cameo in a fighting-game if that hero doesn't have his own game to begin with. ;)

Instead, my recommendation to Roth (and anyone else wanting to take an active role in this) would be to try and recruit people from far and wide. Heck, there's a whole community for musicians interested in doing NES/Famicom music (2a03.org), so there ought to be at least some kind of similar interest in drawing NES-graphics. It shouldn't be impossible to find at least some talented pixel artists who'd fancy the idea of contributing a character of their own free choice to a homebrewn fighting game.

And with the limits talked about, even someone with little experience in NES graphics could grasp the limitations. Just have one layer with 3 colors + transparency that can be used pretty freely, and another 3-color layer where you should try to draw smaller details sparingly and close together.

This by no means implies that I wouldn't like to actually see the avatars from your homebrews star in this possible fighting game. I just hope the list of potential content contributors won't be limited to these forums by mere principle. :)

by on (#40317)
Well the characters from our games don't have to be the only ones in the game. I know this wouldn't contribute enough characters at all. But I've contributed 2, Bregalad's contributed 2, and Tokumaru seems to have contributed 1 or 2 characters. That's already 5-6 characters and we can come up with more.

I actually could contribute a few other characters. I don't have any art scanned for them or anything. I do have one question though. Would it be a bad idea to have some of these characters have a humorous/comical appeal to them? I mean, I could contribute like 5 more characters if that's not the case.

I happen to really enjoy making NES graphics. I've been told that I'm good at it, so I could contribute that way. I'll make a picture containing all the fighters I'd contribute. Possibly in their NES form with portraits. It'll take me a while, though.

EDIT: Just so you know, if I were to contribute as a graphical artist for this project, I'd focus on this more than my other project. At the moment, I'm lazy about my other project because I finished doing most of the map engine with AI handling, and I just have to do some boring optimizations and stuff. But focusing on art would be really fun for me, even if I did have to draw 16-20 animation frames for 16 or so characters.

by on (#40327)
If the project last for a while I'll have a few more potential characters hopefully.
Sometimes I like doing graphics but not always. It' hard to exaplain.
Since I'm often stuck an a project it's a good idea to work on another to change mind, to eventually continue the former project when you feel the motivation to do it.

by on (#40345)
You say 16 to 20. Once I calculated how many animation frames one would need for each character in a Street Fighter clone, and it was around 100. I forget the breakdown I used then, but imagine a Ryu/Ken/Mario type character with moves like these, and then draw 3 to 5 frames for each:

stand
quick attack
strong attack
crouch
crouch + quick attack
crouch + strong attack
jump straight up
jump forward
jump backward
jump + quick attack
jump + strong attack
toss fireball
rising dragon uppercut/super jump punch
whirlwind kick/spin jump
being hit on ground
being hit in air
being knocked back
being thrown
getting up
burned by fire or electric attack

by on (#40346)
We'd have to minimize this, obviously. a 6x9 character would take 5400 different tiles according to that math, and that's just not happening. For one thing, I see quick attack and strong attack. We could do away with those. Also, it's not really the frames that count as the space eaters. It's the tiles. We can store tile mappings of the characters for each move in ROM and re-use lots of the tile data. Every character would be given a limited amount of graphical data. What should this limit be? 4k? 8k? 6k? We'll be using bankswitched CHR ROM, right?

by on (#40350)
Well, that's sure a lot of frames. But you should do kick/punch instead of quick/strong attacks I guess for most characters.
And it's possible to reduce the frames, for example when getting up it would display crouch then quickly normal frame again. It should look decent. But tepples is right that about 20 frame may not be enough. It should be possible to re-use many tiles between frames tough. Although we'll have to reuse less if using 8x16 sprites. I still think that a limit of 8k should be decent, maybe I'm wrong.

by on (#40352)
Celius wrote:
We'd have to minimize this, obviously. a 6x9 character would take 5400 different tiles according to that math

True, based on the upper bound of 54 tiles per frame. But a lot of the area of a character will be the blank tile, so I'll assume 32 to 42 tiles, which would fit 3 to 4 frames into each 2 KiB CHR page. So for a game with eight fighters, you'd have about 48 to 64 KiB of CHR per fighter, or the majority of a 512 KiB CHR ROM. But then Kart Fighter was half this because it used only about 2 frames per animation.

But then the sheer amount of data also shows an advantage of a platform fighter over a Street Fighter style system. There's a reason that Street Fighter 2010 had nothing to do with Street Fighter.

by on (#40818)
Sorry, I don't really know what to write, but it's a shame to see this project go to waste, so, uh, bump.

by on (#40819)
For me, it's not going to waste, for sure! I'm in the midst of finishing up alot of other projects that I have going on. I planned on bumping this topic up as well, but I was going to wait until said projects were polished off. I am glad to see that it's still in the minds of others : )

by on (#40822)
100% agree with Celius, and yeah I don't know what to say. Roth you are the project's founder so it's up to you to do something (and please do something !). If you don't want to for any personal reason then please say it straight.

by on (#41266)
Hi, sorry for not helping the continuity of this thread, but, I'm a c programmer and cannot help very much with asm coding, but I can contribute with pixel art.
Hope to see this project realized.

by on (#41363)
I know I essentially have no place talking here, being a lurker/newbie, but as a person who has done some pixel work before I wanted to comment on the large sprites vs. small sprites issue.

It's true that individual pixels matter more on small sprites than on large ones, but this isn't necessarily a bad thing. On a smaller scale, our eyes fill in the blanks more and we "see" something greater than the sum of its parts (which is really just a couple of colored dots). As the resolution gets higher, we get closer to actual drawn lines making up an image, at which point it becomes more difficult to just suggest something rather than explicitly drawing it.

Look at Ryu here:

Image

It's cool to have bigger sprites, but the main reason of doing so is to also include more detail. It's true that you don't have to worry as much about how many pixels his nose has, but now you have to pay more attention to the folds of his clothes and the highlights on his muscles. You also will want access to more colors in more places, or it'll end up looking more monochromatic and bland. Also notice techniques like anti-aliasing on Ryu's edges; these things become more necessary as you scale up.

Essentially, your drawing, animating and coloring talents matter much more because now people can see it.

I also think space limitations are going to come into effect more than has been previously thought. How much freedom are your artists going to be allowed? NES era artists were always very conscious of the NES's limitations, and with good reason. You very commonly see squished or squared off images to keep things inside the boxes or at the edge of a color change. I think you'd be hard pressed to find a good artist who is aware of and able to function with the necessary restrictions.

Here's a really big NES drawing:

Image

Not horrible, but clearly drawn with strict guidelines. Any awkwardness might be partially attributed to drawing ability as mentioned above. It might also be due to the grid, or it may be a bit of both. Every bit of fleshtone in those faces fits perfectly into a rectangle, and you can bet the space from the top of the eyebrows to the bottom of his nose is carefully calculated. Everything is specially placed to allow for the most solid color tiles possible. It's a big picture, but there's no detail. It looks like a coloring book.

Image

Similarly here, you can see how Piston's arms have been forced into the rectangle. Notice the perfect horizontal line at the bottom of his gloves. And even with as few characters and frames as Punch Out has, they were carefully designed to have reusable mix-n-match body parts. Again, it's just line art filled in.

Is that sort of art good enough, or do you want it to look more like a real 90's fighting game?

Is it ok to just erase a guy's arm and then draw it straight out and call that a punch frame? If the artist wants to animate it realistically, are you going to tell him you don't think the lower body should move at all in order to save frames? If the artist draws the character's face two pixels out of the grid, is that acceptable or do they need to be shaved off? It all depends on how good you want it to look, and this should be considered in advance. Larger sprites are very tempting to trim for the programmer, and you need to decide early what you will and won't do. Smaller sprites are less of a concern here since the whole picture is crucial to the pose.

I am not trying to be discouraging, I just think these things should be thought through carefully. It's possible to make a great game with large or small sprites, but depending on how you do it things may be needlessly difficult. I understand well that anyone posting here would not deterred by the difficulty of something, but it may not be a type of difficulty that you're used to.

Personally I think the best idea is to scale down a little without going down to Mario size sprites. Keep it smaller than the max and your program is extensible. If you end up with space for three extra frames for each character, hey, that's one more special move per person, or some extra portraits and background art.

Also consider that if, for example, you shave off the top row of tiles from a proposed 6x9 tile fighter and make them 6x8 instead, that's 3 sprite tiles per fighter of extra colors. Is more height or more details more important?

On a different note, in terms of what I might offer, here's a guy I made. Single sprite overlaid for eyes.

Image

Yes, he is somewhat naked.

But I don't know how much I could volunteer to this considering I am mainly here now to learn the programming side of things. :P

by on (#41379)
Quote:
I know I essentially have no place talking here

No everyone have a place talking here and that was very interesting.

Now that you mention it Honda's harms doesn't looks very good, but before I read this post I never noticed it altough I've fought him a few times. If there is a few imperfections only the pixel artits are likely to see I mean it doesn't matter.

It's true there is a lot of deatail in Ryu's sprite, notably the highlight of his muscles and of his pants which are very well done. But are they THAT hard to do ? Instead of doing a traditional straight shadow lines you randomly make them going into the surface and with some experiment unless you find something, it will likely look great. Or am I completely wrong ? (sorry it's hard to explain what I have in mind in english)

I think details matter on "stand" frames because they are likely to be viewed by the player. But they matter much less in attack frames because they are viewed fastly in sequence, and if there is arms that are cut off, or details in pant's highlight that doesn't look right, for a few fractions of a second, the player will most likely NOT see anything anormal.
To have good animation it is needed that motion is shown. For example instead of just "moving" the arm, there should be a pitcure of the arm actually moving in between (that would more look like a big white slash from the old position to the new), so that it looks much better. Fire Emblem GBA games does that and it looks awesome.

by on (#41383)
Just a rough draft.
It lacks some detail as UncleSporky noted.
But hey, he has clothes on.
The pants could have some shade of gray. not the jacket though, as it has a lot of skin surrounding it.
Hey it's a lot of work making pixel art with 3 colors.

Image

Image

Image

by on (#41385)
The trick (in my mind) to making really good pixel art for the NES is choosing the right colors. Black is essential, as you can use it in combination with any other color to make various shades of that color with dithering tricks. White is pretty great too, as it acts as the very brightest of all colors. However most of the time you don't have enough room for both black and white (leaving you with only one other color), so black takes higher priority.

In this portrait (I know you said it was a rough draft), many things could be done to make it look lots better. First of all, it seems to use 3 different palettes: Black, Skin, White; Brown, Skin, White; and Brown, Black, White. This isn't very efficient, as you'd have one palette left. I would either eliminate brown from the 4 colors used by the sprite, or I'd add 2 more colors to it including brown. So if it's using 4 colors, that means at least 2 palettes, so you're using 4/6 colors, which gives you 2 unused colors. If it's only using 3 colors, it's just using 1 palette. This is more than possible to pull off with this sprite.

The pants would need shading with dithering, and so would the arms. Otherwise, it's a decent outline/rough draft. But the pants really need some dynamic.

by on (#41386)
Here you are what would be technically possible with only one palette :
Image
Of course the face doesn't look very good and would need absolutely more colors, but other than that with better colors it can look much better than what one could think at first.

That's what most GBC games did in it's late life, people weren't used to pixel art any longer so most developper converted images from a higher resolution.

by on (#41387)
Make the orange skin tone, maybe keep the brown (otherwise make it black), and make the lightest shade white. I think you'll have a decent nintedoization.

by on (#41389)
Bergalad, I think that that type of conversion, at least the example you posted, looks too much like monochrome.

Celius: About palettes, you're right I used too many palettes.
But I think now, that we could use up to 2 palettes for each character, because you know there won't be more than two fighters in the screen at the same time. So palette data could be switched from fight to fight to match the players'.

I saw some homebrew/pirated street fighter games for NES which had graphics very similar to this one.

This is how it'll look scaled down to 6x8 tiles. not bad. ( 6th column could as well be gone )

Image

by on (#41391)
Quote:
at least the example you posted, looks too much like monochrome.

I guess the secret to making good graphics is to draw them as monochrome, and then add color afterwards. If you turn an image to monochrome, you'll likely reconize it. If you preserve colors but make all the same lightning level, you will most likely not reconize anything. The proof is here : http://en.wikipedia.org/wiki/HSL_and_HSV Look at the image in the middle of the article, when they removed the 'L' componant, nothing is reconizable.

Oh and the stauration is always on maximum on the NES because of the palette itself, so it doesn't even enter into consideration.

That said, after drawing a monochrome image, you'd still want it to look good colored, and that's why you should use tricks like Celius said.

BTW I belive there is already a Gameboy version of SF2 which features low resulution and monochrome fighters. Also it does everything with background so that the sprites could get 4 colors + transparent, which isn't possible with sprites. Obviously the graphics were originally drawn for the SNES and scaled down for the Gameboy.

by on (#41392)
Petruza wrote:
Celius: About palettes, you're right I used too many palettes.
But I think now, that we could use up to 2 palettes for each character, because you know there won't be more than two fighters in the screen at the same time.

And any projectile attack would have to use one of those palettes. Remember that Ryu from Super Street Fighter II can throw both blue and orange fireballs.

by on (#41398)
Looks like you get the best result by color reducing first and then resizing, unless Petruza did some other modifications. I did mine the opposite way and it's not as pretty. With dithering and without:

Image Image

Those are just 6x9 tiles, but you also have to remember you get a lot of weird shaped sprites and have to keep the scale the same (in Ryu's case, hes 77.7% size of his SNES resolution):

Image

(I'm getting all these from here by the way)

I know the point here isn't to pick apart another fighter's sprites, but perhaps a full set of Street Fighter 2 animations reduced for NES would be good for coding the engine with.

By the way, I'm not well versed on attribute tables yet, but isn't it true that background palettes are limited to 2x2 tile chunks? That makes it harder to use multiple palettes effectively.

Also remember that there have been some successful 4 color fighting games with a nice style:

Image Image Image

Match of the Millennium: SNK vs. Capcom

by on (#41399)
Oh my those 3 last sprites looks *so cool* !!

And yeah dithering doesn't look any good when animated. Or you must make it with care so that the dithering pattern is the same in all animations ?
As much as I like Street Fighter, we must know from the start that NES is not SNES. When punching, there is no reason the bottom part of the body moves significantly, this should be a waste of memory. And yeah, all moves have to be extensively eggagerated to look normal. If you make moves that looks normal it will look like the character barely moves. Oh and sprites from SFA2 are better than those from the original SF2, in case of.

by on (#41404)
The dithered one isn't so bad, it actually kind of reminds me of GB games like Donkey Kong Land or Gameboy Camera. Maybe I just think it's good for nostalgic reasons, I don't know.

Anyways, I think the right most animation looks pretty good, though I think it needs some more non-computed work. It would be nice to have some sort of editor where you could flip back and forth between animations while editing, so you could really fine tune every frame of animation. I would add some highlights, and possible make it so he isn't yellow. I see that making him the usual skin tone would probably screw some of the shading up, so you'd have to put in some of the brown in place for the original shading.

by on (#41405)
Celius wrote:
The dithered one isn't so bad, it actually kind of reminds me of GB games like Donkey Kong Land or Gameboy Camera. Maybe I just think it's good for nostalgic reasons, I don't know.

Anyways, I think the right most animation looks pretty good, though I think it needs some more non-computed work. It would be nice to have some sort of editor where you could flip back and forth between animations while editing, so you could really fine tune every frame of animation. I would add some highlights, and possible make it so he isn't yellow. I see that making him the usual skin tone would probably screw some of the shading up, so you'd have to put in some of the brown in place for the original shading.
It was NES skin tone in the editor, I swear. :)

But really I was just doing it for a mockup, to test different styles and see what we might be looking at once it's up and running. Doing it by hand, pixel by pixel at the right size will always look much better than reducing existing graphics.

by on (#41416)
I think actually the best way to go about it is to trace reduced models. I'm doing this for my game where I draw the models on paper by hand, and just scan them, scale them, and trace them. Of course, lots of times, I have to trace over them with thick outlines before I scale them because sometimes the scale is so drastic (going from like 600x800 to 24x32 type of stuff) that when you shrink it it is hardly recognizable. Actually, more often than not I have to do multiple trace-and-scales. I shrink it to 25%, trace it, shrink it again, trace, etc. I get some decent results though:

Image

The top right corner has a really really quick sketch that's scanned, and then next to it is where I traced over it with a thick outline. I had to scale it down to the larger size, then down to the smallest size, as is seen in the bottom left corner. The only thing that sucks is the finger pointing. It's rather hard to get it to look right.

EDIT: Sorry about the page width stretching; I'll fix that in a sec.

EDIT 2: Updated image so it wasn't stretching the page to be so wide.

by on (#41418)
Mmh, I often draw stuff by hand, and draw at pixel art without scanning or anything, because I find it's worthless. I often end up with different results, but I don't really care - as long as they look decent.

by on (#41427)
hey I can't vote. Is the poll closed?

by on (#41430)
Petruza wrote:
hey I can't vote. Is the poll closed?

Judging by the first post it was open for two weeks back in November.

by on (#43983)
Well, err.... anyone to start something serious npw ?

It seems in the poll big sized characters wins, but by a very close match. So I'd say let's go with averagly-big-sized characters in mind, right ?

by on (#43985)
I agree on having average sized characters. The problem is is I'd like to suggest 3.5x6 tiles in size, but there's no using 3.5 tiles; it'd have to be either 3x6 or 4x6. Is that too small?

by on (#43987)
4x6 sounds like a great size to me. It would allow the character to still be chiby/cute deformed (head is more than 1/7 of the body) but not too much either (usually in games head can get as big as 1/2 of the body).

Also this would allow the 1 character 2-layered sprite & 2nd character 1 layer sprite + 1 layer BG sheme introducted by Bananmos.

by on (#44135)
Seems like many people are interested in making pixel art. The more the better. I'd like to contribute animations too, I can do it to any character at any size, any amount of frames(preferably few, otherwise it would take too long). But anyway the sprites can be non animated nor detailed during the programming. Quick done images, and if the main gameplay gets done, then add detail and frames to the images. So you don't waste talent in something that is not clear if it will be ever finished, until the phisics and moves get done. Look at my only decent finished game(Game Maker): http://snowmoons.com/downloads.php?cmd=get_file&id=641
The graphics and animations was the last thing done. Before that, there was just two images of Felix (one with the pressure against the floor) and a lot of different colored and sized rectangles to represent enemies, floor items, etc. because I never knew if I was going to finish it or leave half way through in favor of another project.
I'll see if I can do something about this fighting game with rushed images in Game Maker, then I'll show it to you so we can discuss the changes, and eventually, when everybody likes it, someone can adapt it to the 6502 language, because I'm pretty newcomer to that.

by on (#44136)
egfelixdcg wrote:
But anyway the sprites can be non animated nor detailed during the programming. Quick done images, and if the main gameplay gets done, then add detail and frames to the images. So you don't waste talent in something that is not clear if it will be ever finished, until the phisics and moves get done.

Well, I don't really agree.

I'd say I'm not programming anything before I have good graphics and animation for the game I'm programming, because I don't want to waste my programming talent for a game that is never going to be finished.
In my current game I'm making, the thing that causes me most problems right now are the graphics. Programming is easier than doing graphics in my opinion (I know many people don't agree, but the same task isn't the same difficulty for everyone). I wish I had done all graphics first.

So your logic doesn't really hold I think.

by on (#44142)
But don't you need animations as a reference for setting the hit boxes?

by on (#44198)
Maybe you are right Bregalad, it's a matter of preference.

tepples wrote:
But don't you need animations as a reference for setting the hit boxes?


Just have a quick drawing of the fighter in the punching pose, and set the hitbox in the arm, this image would be still during the needed few frames. When the greater part of the programming is complete, the punching animation gets done and you modify the hitbox adjusting it to the frames in wich the fist hasn't reached the extreme.

by on (#44728)
I managed to do something: http://snowmoons.com/downloads.php?cmd=get_file&id=717

zip includes an executable and an editable game maker 5 file. Screenshot:
Image
By tinytoonboy at 2009-03-24

You can walk and jump with the arrow keys. By now only a simple punch with key Z. The grid around the characters(representing the tiles) will be removed, I just thought it was ok by now.

I think now we can continue discussing the game and change/add things.

by on (#44881)
Looks quite like a good start ! The "camera" control looks perfect so far. My vote is to make the jump slightly less high (so that the head doesn't touch the background), and to allow the player to change direction while jumping.

by on (#44900)
Thanks! I did those changes you said. Yeah, I think that allowing to change direction while jumping is better, and anyway if the mayority prefers the other way it can be changed back. Now the player can also drag the enemy along if walking against him. Here is it:

http://snowmoons.com/downloads.php?cmd=get_file&id=732

I forgot to say that the game can be restarted pressing R, just in case of a bug or something.

by on (#44906)
This is a great start, really. But now it should be structurated arround a website or something serious about the project.

On the programming side... allow crouching and kicks would be great, but so far it's really good.

by on (#44948)
True. Sadly I don't know anything about making web pages. I'd suggest creating a new thread for the Game Maker version, and later another thread for the assembly port. So maybe those threads would be for updates and we could keep disscussing the posibilities on this one.

by on (#50153)
Sorry to dig this one, but.... is somebody still motivated to do a colaborative fighting game ?

I like programming so I'd probably do the programming part if there would be someone who tells me what to do. Once we agree with graphics standard, everyone could work on character's sprites and arenas, while I (and possibly someone else) would do the programming of the game engine with only one character.

Is it beacause so many people disagreed about the size of the sprites and amount of layers that the project didn't start ?

by on (#50156)
My specialty is the graphics side. About programming, I can only do Game Maker samples. I abandoned studying NES programming a while ago.
Maybe we should choose some people to establish ideas and someone to be the director.

I suppose the main problem is that this requires too much time and effort by everyone. Generally one wants to relax during spare time. Thinking how to make a game might be fun, but actually working on it after a day of study or work could be exhausting.

by on (#50161)
Quote:
I suppose the main problem is that this requires too much time and effort by everyone.

Well I suppose not, because everyone here pretty much agree that it's worth the effort of making games. The point of making a collaborative project is that there is more people doing less effort rather than one guy doing all the effort. But if that's so I'm all inclined I don't want to force people making a collaborative fighting game.
Quote:
Generally one wants to relax during spare time. Thinking how to make a game might be fun, but actually working on it after a day of study or work could be exhausting.

I find making games fun, altough it can be a little exhausting. Like tokumaru said earlier fighting games are some of the simplest that could be made since there is only 2 characters at once, and arenas are relatively simple (as opposed to levels or so).

So who'd want to be the director ? Roth seems to be the one who started it all, but I haven't seen him here for a while. I'd be it but only if there is people motivated to join ! I have enough other nesdev projects, but honnestly this one sounds cool for a relaxing project where you just draw characters doing cool attacks and don't have to worry about levels and bosses.

by on (#50162)
I like nes games but I always found this platform the worst for fighting one. 1 on 1 fighting as never been it's strongest point. But if you're talking about a beat-em-up a la double dragon, in that case it would be interesting.

The nes shine more for platformers and the like. For fighting, I don't think so. Maybe that's why the interest vanished so fast.

by on (#50164)
The size of characters in Street Fighter II-style fighting games would make them flicker-fests if implemented on the NES with its 25% overdraw limit, unless perhaps you would make the background behind the characters blank. That's what happened to TMNT Tournament Fighters and Kart Fighter. They'd also take more space in CHR for a given number of frames of animation. That's why I've long recommended the smaller fighters as seen in the platform-fighter hybrid Smash Bros. series (and in the forgettable Shaq-Fu).

by on (#50169)
Big sprites sound like a headache to code while small sprites would allow for much smoother animation at the same cost of CHR space.

I'm thinking of exaggerated cartoonish animation and physics like in the Smash Bros. series or Battletoads. In my opinion that's much more impressive than an engine with big bulky sprites.
Not sure if I will be able to contribute to the code, but I might have a go at pixelling a few sprites once the format is decided and there's a template sprite sheet or something.

by on (#50173)
I'm thinking about 16x32 to 24x32 pixels, bursting up to 32x32 or 24x48 or so for special attack animations. (This size leaves room for two players and a couple projectiles with no flicker.) Try using sprite sheets from Contra or Super Mario Bros. 3 as your templates.

by on (#50187)
Well I'm pretty sure that if the few fighting games on the NES failed it's because the developpers didn't have the idea (or the guts) to make one of them BG and the other one sprites. As long as the BG color is proprely chosen, it's possible with CHR-ROM to make whathever fighter looks right to be BG, and whathever fighter that looks left sprites using the same BG tiles flipped horizontally, allowing them to use a decent amount of space.

The poll is a close call, and anyway that "Big vs small" things have no point when it's possible to do them any possible size, there isn't only 2 sizes allowed.

To allow enough detail it would be really nice to have them seriously larger than the big mario of SMB 3, slightly less than twice that size, making them 7x4 tiles wide "standard", different when doing attacks. That's smaller than SF2, and bigger than most platform games.

That way the biggest size fighter would be about 7x4 tiles of sprites (that's 16 8x16 sprites or 28 8x8 sprites, both are acceptable), plus up to 2 tile wide of a second layer to allow for more colors (as bananmos said) for the face which needs more detail/colors and is relatively small as opposed to the body which is large and needs typically less colors.

The other fighter is 7x4 tiles of BG, and it's second face layer would still be sprites (obviously), which makes a great total of 8 sprites (exactly !) on the head line, and 4 on the others lines, allowing for smashes without even too much flickering, and even if you see 2 hears layers, 1 body layer and one smash and there is like 10 sprites for a few frames, with correct cycling this won't look weird at all !

The worst case is probably if both players are grounded at once : There would be 7 sprites for the body of the grounded sprites, plus 4 for the head layers, which would flicker a bit, but it'd be rare that both are grounded at once anyway.

Of course, not all fighter should be the same size, nor should them all be square shaped sprietes ! My specs would be for the biggest 2m giant of the game (Zanghief, Abobo, ..., what fighting game doesn't have one ?), other people should be always smaller and thinier than him.
If anyone feels like doing their fighter smaller, by all means do it (as long as it's not 16x16 or something), but keep in mind that it will actually look like smaller.

by on (#50189)
Bregalad wrote:
whathever fighter that looks left

So in other words, you want to make a fighting game without anything like the "roll" mechanic of some games: the player on the left can roll around the other player and attack his back. At that point, both are facing left. And I forget: in SF2, if Chun Li jumps over Ryu, does Ryu automatically turn around with no keypresses?

Quote:
If anyone feels like doing their fighter smaller, by all means do it (as long as it's not 16x16 or something), but keep in mind that it will actually look like smaller.

If a character's size doesn't fit in with the rest of the gang, you can always scale it up and then have the submitter retouch it.

by on (#50198)
Quote:
I'm thinking of exaggerated cartoonish animation and physics like in the Smash Bros. series or Battletoads. In my opinion that's much more impressive than an engine with big bulky sprites.

Well, the animations for 2D sprites HAVE to be cartoonish and exagerrated anyways no matter the size, else it will look dumb. Even for a simple walking animation you have to exagerate the legs movement a lot so that it looks nice. Street Fighter animations are exaggerated as well.
And the engine doesn't specify how the sprites are, only how they are used.
Quote:
If a character's size doesn't fit in with the rest of the gang, you can always scale it up and then have the submitter retouch it.

You get a point. When doing graphics for my game I often came up with graphics with the wrong size, and scaled them and retouched them by hand to add detail that was removed (when scaling down) or to round off the blocky pixels (when scaling up) and it always worked pretty fine.
It's even possible to change the aspect ratio and have a character looks more real-proportioned or more SD that way. I guess drawing characters with big legs and a small face can be easier since a leg is basically less complicated than a face, but I might be wrong.

Quote:

So in other words, you want to make a fighting game without anything like the "roll" mechanic of some games: the player on the left can roll around the other player and attack his back. At that point, both are facing left. And I forget: in SF2, if Chun Li jumps over Ryu, does Ryu automatically turn around with no keypresses?

Yes. I've double checked that in SF2 characters never faces the same direction it seems even if the match is Chun Li vs Ryu (why would it change anything?), and even if it's possible, our game wouldn't be SF2 anyways, nor would it be Super Smash Bros. And I guess it's possible to have graphics less detailed than SF2 while still having fighters taking a decent proportion of the screen.

Would people be more motivated to contribute to the project if someone (I) would come with a functionnal engine with one example character of how to do a submission ?

by on (#50201)
Bregalad wrote:
It's even possible to change the aspect ratio and have a character looks more real-proportioned or more SD that way.

I used to be a fan of the super-deformed "Precious Moments" style, but now I'm getting to the point where I see an SD character in a breakfast pastry advert with CPD and think "gotta be C-section". But then my main Brawl character is still Lucas (tires don exits), so there's a bit of dissonance going on.

Quote:
I guess drawing characters with big legs and a small face can be easier since a leg is basically less complicated than a face

"MANTIS or MAИTIƧ? How about MAXIMUM?" -- Dee Jay

Quote:
Yes. I've double checked that in SF2 characters never faces the same direction it seems even if the match is Chun Li vs Ryu (why would it change anything?)

Chun Li and Vega (バルログ) can wall-jump off the sides of the arena. In SSF2, Vega also has a Flying Barcelona Attack (D, U+K, P) and a Sky High Claw (D, U+P) that involve wall-jumps. That makes it easier to jump higher and thus easier to see potential situations where characters could momentarily face the same way. Game rules would have to be written to avoid these situations.

That, and it might take a while to rewrite the pattern table for each frame of animation.

Quote:
Would people be more motivated to contribute to the project if someone (I) would come with a functionnal engine with one example character of how to do a submission ?

That would be nice. Even just a video and a corresponding PNG sprite sheet could get things started.

by on (#50214)
Quote:
That, and it might take a while to rewrite the pattern table for each frame of animation.

Well I was planning to use CHR ROM so it'd take as slow as a few mapper writes at worst. However the name table would have to be rewritten, but 7x4 characters sounds doable in one frame (at worst double duffering will be used).
Quote:
That would be nice. Even just a video and a corresponding PNG sprite sheet could get things started.

Okay I'll work of it whenever my current NES project will make me mad for a change.
Quote:
Game rules would have to be written to avoid these situations.

Yes, but without a doubt there would be less combos than in SF2 anyways.
Quote:
"MANTIS or MAИTIƧ? How about MAXIMUM?" -- Dee Jay

I don't see your point here.

by on (#50217)
Bregalad wrote:
Quote:
"MANTIS or MAИTIƧ? How about MAXIMUM?" -- Dee Jay

I don't see your point here.

In Super Street Fighter II, Dee Jay's pant leg was originally going to say MANTIS until Capcom's artists realized that this would make Dee Jay's CHR data 50% bigger (need separate data for left and right views of bottom half). So they changed it to MAXIMUM for great symmetry.