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

Easier and harder game genre to code/developp

Easier and harder game genre to code/developp
by on (#26438)
I'm wondering, for general information of everyone (especially people trying hard to become homebrewer) what game genres are the easiest and hardest to develop for, and for which reasons ?
I'll start throwing my trought, however I haven't tried to code a game of each genre (at least not yet !) so it's hard to tell.

Action - Platformer :
Graphics : You only have to draw stuff on one side (wich is much easier) and mirror it horizontally. Platformer graphic design isn't too hard I guess. You can make some oblic projection or paralax effects if you want to. Even if the graphics aren't awesome, this has few impact on gameplay
Music : It is important to have upbeat music else the game will feel boring.
Level design : Again it has to be good, but I don't think it's too hard to design a good platform level.
Gameplay : This is the hardest part of this genre without a doubt. The controls have to be responsive, and the enemies have to be fast and fun to fight (especially bosses) else the game will be bad no matter what.

OVERALL : No a too hard genre to code for, but to get a real good game this is still a challenge.

Action - Shooter :
Graphics : You only have to draw stuff on one side again, and the graphics have few impact on gameplay.
Music : Same as above
Level design : There is less creativity possible than a platformer because there is no pits/jump needed, however it's still possible to make fun things without working too hard I guess.
Gameplay : Should be slightly easier than a platformer, because the lack of gravity, and the fact that the player will have to avoid enemies in 4 direction will make the game automatically harder.

OVERALL : Again not the hardest genre, but it should still be well balanced.

Fighting :
Graphics : The graphics (especially sprites) have to be great and detailed on fighting games, else the game will just suck, and the same goes for character design. But, for a 2D fighting game you just draw the sprites in a side view wich is never too hard to do.
Music : The music is less noticeable in fighting game because the action is intense, so typically even if the music sucks nothing is too much ruined.
Level design : No level design is needed at all, only character design (and combo design).
Gamplay : Again, it should be hard to code gameplay for a fighting game, because it has to be fun, cool and responsive. Even harder is to code CPU animated oponant that still let a chance to the player. This should definitely be a very hard part when designing fighting games.

OVERALL : A somewhat hard genre to code for, even if complexity is minimal any little error in the system can be fatal to the overall game quality. Characters have to be inspired and varied.

Action-RPG :
Graphics : This time the sprites have to be in all 4 directions, which make things much harder. The background is top-down which is also slightly harder.
Level design : Since the view is on the top all the design is focused on exploration, so there should be something really interesting frequently so that the player does not get bored, which make level design slightly harder.
Gameplay : Often gameplay is less intense than on platformer, as minor strategy elements begin to take place, so if bosses are less fast and have less attacks it won't matter too much I guess, slightly easier than other types but still has to be responsive and fun.

OVERALL : A somewhat hard genre to code for, but not the hardest either.

RPG :
Graphics : Playable characters have to be cool, but other than that the graphics can suck just as much as you want and this wont affect gameplay. Good graphics are a plus, but aren't really needed. However, the top-view and 4-direction sprites make the task harder. Also textbox graphics have to be loaded in memory (exept if using tricks) so this is a restriction for the background.
Music : The music have to be good in a RPG, else the player is just going to stop playing after 2 seconds.
Level design : The levels can be designed pretty much freely and they will often be fun, often there is a world map too which is cool. However, a very well designed RPG should still not be easy to do.
Gameplay : The hard part in a RPG should be to create a cool battle system that isn't just ripped from an existing ones. Too much RPGs tends to have just boring battle systems, even good ones. Monsters also have to make good use of the system once existing.

OVERALL : For anyone with ideas for a good battle system, probably one of the easier genres to code for, but not the easier to design proprely.

Strategy-RPG :
Graphics : Again they doesn't matter too much, but the character have to be cool.
Music : Again the music is important, maybe less than in a regular RPG as the player is always thinking to something else.
Level design : This is where the hard part comes, the player should have surprises and have a hard time to make his way through the levels. Since there is only enemies to stop him, the enemies should be posted at the right place and act the right way.
Gameplay : Of course the play system has to be undestandable and not overly complicated.

OVERALL : Shouldn't be too hard basically, but if you want quality and intelligent CPU controlled enemies it can get hard, especially if you want the game to be interesting and challenging.

by on (#26440)
Personally, I think a shooter (Gradius, TwinBee, etc.) would be the easiest genre to develop for, since you just need to worry about enemies and power-ups. Rarely do shooters have puzzles outside the bosses, and the enemies and power-ups are usually simplistic.

The basic genre that would be in the medium difficulty to develop for in my opinion would be a platformer, since you do need a variety of enemies, a basic enviornment for the player to interact with, and a few interesting puzzles and gimmicks if you want (such as the pipes, Warp Zones, and hidden blocks in SMB1, the spike ceiling in SMB3, large bosses in the Contra games). However, you don't really need to have intelligent enemies, although you may need interesting bosses. Plot is usually not as important in platformers either.

For me, the most difficult basic genre to develop for would be an action RPG (Zelda, Secret of Mana), since the plot and gameplay need to be connected well for objectives for the player. So you would need a good battle system and an interesting plot; a very innovative one would need to try not to use too many cliches in the plot and gameplay.

by on (#26441)
You are missing a pretty big class of games, the single screen arcade or puzzle. I think this should be the starting point of most homebrewers because it avoids the tile scrolling/loading confusion and can usually be done without anything more than NROM. Single screen doesn't by itself make the game less complicated but generally leads to a more simple starting design.

I think for a complete final product the RPG is the hardest. Doing enemies, dialog, balancing items, and generally making a good game takes more work than other types. My friend designed many Dragon Warrior type games, but it was usually just the map and vague storyline which isn't enough for a complete game.

by on (#26446)
You both guys are mostly right I guess.
However, a RPG is much easier to programm technically even if it's harder to design, as the programm just have to maze 16x16 sprites for any character, and just to check colision with big 16x16 block and move the sprites one whole block at a time. Also, even if the controls aren't too responsive, this is not much a big problem (within a certain margin of course) and enemies are definitely easier to design when they just have to chose from a handful of attacks randomly and have only one animation frame than on a platformer where the enemy moves a lot and have to be animated.

Quote:
For me, the most difficult basic genre to develop for would be an action RPG (Zelda, Secret of Mana), since the plot and gameplay need to be connected well for objectives for the player. So you would need a good battle system and an interesting plot; a very innovative one would need to try not to use too many cliches in the plot and gameplay.

Heh, I have to confirm that as stupid I am I have chosen this genre as the first complete game for me. I always wanted to make RPGs neverthless, and I told myself an action-RPG would be easier to do than a real RPG or a strategy SRPG. However, it will never be as complex as Zelda and Secret of Mana (it will be a lot more linear), and will have a very small and simple plot (still better than SMB). I will try to compensate this with stage design and fun. In fact the only thing which gets really hard is to design enemies in all 4 direction, because drawing stuff from front and back is much harder than just a normal side-view, and additionally it takes much more pattern table space, letting place for fewer enemies at once. Design bosses is just insane.

And yes, puzzle games shouldn't be that hard to code, but to have them really fun is probably very hard, as I only played a couple of puzzle games I consider myself fun. And even if there is no scrolling, the need to handle graphics for lots of falling (or climbing) pieces can be just as hard, if not even harder. I mean, come on, scrolling isn't really that much complicated, I did the scrolling code for my action-RPG without any problem (however it scrolls on a screen-based map, which make things considerably easier).

by on (#26463)
But there are still some kinds of games that I'm almost sure cannot be made on an NES using common Nintendo mappers and Nintendo controllers:
  • Twitch-oriented bipedal shooters such as Quake III, even redone in a pseudo-overhead perspective like Metal Gear or Ikari, because of the lack of a way to quickly aim a weapon in increments more precise than 45 degrees
  • Simulators such as SimCity, The Sims, Harvest Moon, Animal Crossing, where the state of a simulated town is much larger than 8 KiB
  • Manic shooters such as DoDonPachi and Espgaluda, where sprite flicker would surpass that of the first port of Pac-Man to Atari 2600

Am I right?

by on (#26464)
tepples wrote:
Twitch-oriented bipedal shooters such as Quake III, even redone in a pseudo-overhead perspective like Metal Gear or Ikari, because of the lack of a way to quickly aim a weapon in increments more precise than 45 degrees

Thats what the PowerGlove is for! ;) Don't have specific examples but there should be overhead car racing or skiing games that do smaller than 45 degrees? RC Pro AM? Of course with the dpad getting good aim is hard or slow, not good for twitch games.


tepples wrote:
Simulators such as SimCity, The Sims, Harvest Moon, Animal Crossing, where the state of a simulated town is much larger than 8 KiB

Except there is a finished version of SimCity for NES. No idea what mapper it uses but there are uncommon boards with 32KB+ WRAM (SXROM, EWROM). More CHR address lines could be used to get even more WRAM, but that gets away from the available Nintendo made boards. I would assume SimCity would have been MMC5 for the extra tiles and full batt backup instead of just 8KB.

by on (#26465)
bunnyboy wrote:
Thats what the PowerGlove is for! ;)

I said "Nintendo controllers". Power Glove was a Mattel product; Nintendo wouldn't do its own motion-sensing console controller until 2006. I guess the Control Pad would move the player, the glove would control a bulls-eye, and pulling the trigger finger would shoot at it.

bunnyboy wrote:
Don't have specific examples but there should be overhead car racing or skiing games that do smaller than 45 degrees?

Overhead-style racing games such as Micro Machines, RC Pro-Am, and Rock n Roll Racing have their own problems: you can't see far enough down the track.

bunnyboy wrote:
Of course with the dpad getting good aim is hard or slow, not good for twitch games.

Especially when you need to hop around with precision, bunnyboy.

bunnyboy wrote:
tepples wrote:
Simulators such as SimCity, The Sims, Harvest Moon, Animal Crossing, where the state of a simulated town is much larger than 8 KiB

Except there is a finished version of SimCity for NES.

Was a prototype ever found? I have a feeling that as with Earthbound: Prototype, Nintendo decided against putting this on cartridge due to replication cost.

Quote:
No idea what mapper it uses but there are uncommon boards with 32KB+ WRAM (SXROM, EWROM).

I seem to remember that a save state from SimCity for Mac OS was 27 KiB. But then you'd need yet another 27 KiB for the current state of the town. Round up to a power of 2 and you have 64 KiB, half of which must be battery-backed. Add MMC5 and you're looking at one expensive Game Pak.

Another thing about Animal Crossing: It lets the player design patterns on his clothes. You'd need 3D hardware (or an insanely optimized software renderer) to be able to animate a custom clothes pattern for all of the character's actions, and you'd need more than four colors per sprite to be able to draw this clothes pattern without using the Mega Man overlap trick and potentially causing tons of flicker.

by on (#26466)
tepples wrote:
bunnyboy wrote:
tepples wrote:
Simulators such as SimCity, The Sims, Harvest Moon, Animal Crossing, where the state of a simulated town is much larger than 8 KiB

Except there is a finished version of SimCity for NES.

Was a prototype ever found? I have a feeling that as with Earthbound: Prototype, Nintendo decided against putting this on cartridge due to replication cost.

A verified final finished version is in the hands of a Nintendo Power editor, never to be seen again! Cost and end of NES lifetime probably cancelled it.


tepples wrote:
I seem to remember that a save state from SimCity for Mac OS was 27 KiB. But then you'd need yet another 27 KiB for the current state of the town. Round up to a power of 2 and you have 64 KiB, half of which must be battery-backed. Add MMC5 and you're looking at one expensive Game Pak.

I assume Mac vers didn't bother with too much compression, but that still likely wouldn't get below 32KB for both current and saved. Would be expensive but not much more than Romance of the Three Kingdoms II (MMC5, 32KB WRAM battery backed, 256KB PRG/CHR) but Koei was just crazy :) Add in the licensing fees and they must have made nothing on those carts.

by on (#26467)
tepples wrote:
  • Twitch-oriented bipedal shooters such as Quake III, even redone in a pseudo-overhead perspective like Metal Gear or Ikari, because of the lack of a way to quickly aim a weapon in increments more precise than 45 degrees

There are ways to do this... even if you have to implement some sort of automatic targeting system, that moves the cross hair from shootable thing to shootable thing... I think it could work... on the NES even.

Quote:
  • Simulators such as SimCity, The Sims, Harvest Moon, Animal Crossing, where the state of a simulated town is much larger than 8 KiB
  • Manic shooters such as DoDonPachi and Espgaluda, where sprite flicker would surpass that of the first port of Pac-Man to Atari 2600

That does not make a game difficult to program, just unlikely to be done on the NES. But provided you have the appropriate resources, it shouldn't be hard.

Anyway, the difficulty in programming a certain type of game shouldn't vary much from one platform to the other, because the mechanics are the same. You might have to use some tricks here and there when attempting certain things on older systems such as the NES, but a 2D platformer works mostly the same on the NES and on a PC, and that has little to do with how difficult it is to program.

And even if the platform did play a huge role on how hard it is to program the same style of game (too many tricks to emulate some native feature of other platform), that shouldn't matter when comparing different genres of games. Regardless of the platform, an RPG will be harder to code than a space shooter.

by on (#26469)
Yes - I asked the question for general purpose programming. Of course it also means on the NES, but I guess the NES don't make genre harder to code or to design, it just has some limitation.
And shots from smallers angles than 45° exists on the NES (Solar Jetman) however they can be a pain to control sometimes. Automatic targetting would rock, I guess you just have to automatically target the enemy which is closer to the player (according to the sum of the horizontal and vertical delta of position) this give me some ideas. Final Fantasy Adventure does target enemies automatically when using the magic Fire, and this is great, as for some reason the enemy who I want to be hit is automatically hit, as if the gameboy was able to read my thinkings. I know this is a gameboy game, and not a NES game, but apart of the CPU those systems are still close enough when it comes to overall power (I already see Tepples finding arguments to proof I'm wrong here, but I mean aproximatively, both are 8-bit systems with the same number of buttons).

A game engine that could never made it to the NES no matter what is Tales of Phantasia : Just look at how many sprites per line there is in battle (even the SNES, wich holds 4 times more sprites than the NES, flickers a lot). Plus, the battle system is programmed mediocrly (even on the SNES), so I guess it was very hard to programm this game, as not only it's a RPG but additionally its battle system is somewhat unique and strange. They got it pretty right no matter what.

Am I the only one who thinks a fighting game should be the very hardest genre ? I mean there is nothing too complex in itself, but most fighting games I played for the NES (such as Best of the Best championship Karate, Karate Champ, Karateka, Kung Fu, TMNT Tourament Fighters, Double Dragon in mode B, etc...) just plain shucked. Yes, Punch-Out is great, however it's definitely not a traditional fighting game.
I havent played really fun fighting games until the PS1 was out (even if I'm not a fan of the genre). And, yes there is several decent fighting games on the SNES (including SF2 and some others) but definitely they are not fun for a very long time, as moves are always the same and get very repetitive + the CPU is insanely hard to beat.

EDIT : About Sim City, I remember the original wasn't overly complicated, however Sim City 2000 and 3000 were very complicated (and were isometric perspective, while the original was top view). Am I right ? Maybe the (original ?) Macintosh version wasn't very optimized, and that the potential NES version would have been optimised to use less RAM. Maybe it would have used EWROM, but the MMC5 can actually handle 64 KB of RAM (including 32 KB battery backed), so what Tepples describe is possible. Maybe it would have been the only game that actually used the MMC5 well. The SNES verison of Sim City uses a special cart with extra SRAM, too, depsite the fact that the SNES has already 128 kb of internal RAM.

And about Koei, yeah they were just crazy. It's so much a shame that they games aren't as crazy as their hardware. Anyway Koei games make good devcarts no matter what. And they are still crazy today, releasing 2D games on the PS2 :wink:

by on (#26475)
try making the card game War on the NES. the card management is a pain in the ass. keeping all the cards in the same order why swapping them between two players. i am currently using two double sided stacks... though it isnt really a stack... but its the only way i know how to describe it is by comparing it to a stack

by on (#26476)
Bregalad wrote:
Yes - I asked the question for general purpose programming.

I thought so.

Quote:
Of course it also means on the NES, but I guess the NES don't make genre harder to code or to design, it just has some limitation.

Yeah, of course. We're on a NES message board, so it's only natural that we think about implementing those things on the NES. It's just that when comparing game genres with each other, the platform shouldn't matter.

Quote:
Automatic targetting would rock, I guess you just have to automatically target the enemy which is closer to the player (according to the sum of the horizontal and vertical delta of position) this give me some ideas.

Yeah, something like that. But it would be cooler if you could move the cross hair from an enemy to the other... like, hold a button to turn automatic targeting on and the left and right buttons would move from target to target around you. This is much more difficult though, as you'd need to find the relative angle of each target to the player (you'd still use the deltas, aka the legs of a triangle, for that) so that you could sort them to make a "circle".

Quote:
Am I the only one who thinks a fighting game should be the very hardest genre ?

Uh... I find exactly the opposite! =) Classic fighting games such as Street Fighter and Mortal Kombat seem to me like the easiest kind of game to program (just behind single screen puzzles).

I mean, there are no level maps! One of the hardest things to coordinate in a game is the scrolling of the screen with the decoding of compressed maps and metatiles, updating the name tables and attribute tables in small chunks, etc. In a fighting game, with 2 name tables you can just fill them with tiles once before the fight starts and there you go, you don't have to worry about this until the next fight starts. 512 pixels is a big enough arena... You could even animate it with palette cycling and/or pattern cycling.

The absence of a level map also makes complex physics unnecessary. The player are on a flat floor, and most movements can just be scripted. Also, there are very few active elements at a time... usually just 2 players and some occasional energy blasts. That is, very few things to test for collisions.

I don't think programming a fighting game is hard at all, but I do think it is very hard to finish one. First, you have to be very creative to come up with interesting characters with equally interesting and unique moves. You also need a lot of patience to draw the insane amount of sprites that are necessary.

On the programming side, I admit that coding the AI for fighters might actually be very hard, but that's it.

Of course programming such a fighting game on the NES might be a bit more challenging, mainly because of the sprite limitation. A person might try using the background for one of the fighters so they'd look much bigger (like on the SNES or the Mega Drive/Genesis), but trying to come up with an interesting background (even if it's only above and below the fighting area) or a good excuse for the absence of one, that will be a challenge! =)

by on (#26477)
Thought up a way for a shooter. Top view like pokemon kinda then kinda random you could have "shoot-outs" pop up. Then you just have to shoot the enemy's before they shoot you (they pop up randomly to) :wink:

by on (#26478)
Lol, can someone write something for lightgun games? I believe I have the concept down but I'd like to see a nice 1-2 paragraph overview from an experienced 6502 programmer...

by on (#26479)
Quote:
Yeah, something like that. But it would be cooler if you could move the cross hair from an enemy to the other... like, hold a button to turn automatic targeting on and the left and right buttons would move from target to target around you.

Like when you're targetting enemis in Chrono Trigger (SNES) ?

Quote:
I mean, there are no level maps! One of the hardest things to coordinate in a game is the scrolling of the screen with the decoding of compressed maps and metatiles, updating the name tables and attribute tables in small chunks, etc.

Come on, coding the level maps and scrolling should have been the funiest part of the game I'm currently making for me. I love to design maps, but I hate to design enemies. Not really that I hate it, but I just suck at it.

Quote:
I don't think programming a fighting game is hard at all, but I do think it is very hard to finish one. First, you have to be very creative to come up with interesting characters with equally interesting and unique moves. You also need a lot of patience to draw the insane amount of sprites that are necessary.

Yes, that is definitely harder than just code a level map and scrolling code (at least for me). I love drawing sprites, but however I never come up with ideas of sprites to draw. Not to forget you have to make the characters cool and interesting, having them look good *AND* have them with tons of moves and fun gameplay. Maybe programming a bad fighting game is easy, but programming a good one shouldn't.

Quote:
A person might try using the background for one of the fighters so they'd look much bigger (like on the SNES or the Mega Drive/Genesis), but trying to come up with an interesting background (even if it's only above and below the fighting area) or a good excuse for the absence of one, that will be a challenge! =)

Yeah, I'd be ready to code a fighting game only for that ! I love technical challenge such as this. However, even if the game engine isn't overly complicated to code, you have to come up with characters, and a ton of moves per characters ! Not to mention that you have to come up with AI to have CPU controlled enemies which give some challenge to the player, but still let them a chance...

Oh, and by the way when desiging BG big enemies that moves, remember that background is possible if there is a pattern that repeats each x pixels and that the big BG enemy moves by increment of x pixels (like in Mega Man 2's game over screen). The problem is that this doesn't really help in this case, as if the characters moves by big chunks it will look bad. However, characters don't move that much vertically, so maybe it'll be possible to make some horizontal line to not make a big chuck of one solid color as the background, and when the character jumps, well, I don't know... Of course you can come up with no jumping, making everything much simper. Just A=Punch, B=Kick, up=block up attacks, down=block down attacks, up+A = High punch, down+A=Low punch, etc... Then button combos could make special attacks. I don't know if this would be fun enough for the player, but it sounds decent.

by on (#26482)
Bregalad wrote:
The problem is that this doesn't really help in this case, as if the characters moves by big chunks it will look bad. However, characters don't move that much vertically, so maybe it'll be possible to make some horizontal line to not make a big chuck of one solid color as the background, and when the character jumps, well, I don't know...

Maybe parts of the fighters that jump that go above the fighters' "horizontal line" can be drawn using sprites, but that may not be plausible if the fighters are more than 8 tiles wide.

For a fighting game, I was thinking that to draw a normal background (not blanked at all) along with BG fighters, the game could use MMC5 with ExAttributes. Parts of fighters that cover whole or almost whole tiles would be rendered to the BG, and parts of fighters that take up half or less of a tile would be rendered with sprites. The game would need to turn off some scanlines (maybe a little more than 16?) to update more tiles than usual for updating the fighters. Since there's no level data and very little objects to check collision for, it might be plausible to set up this data to render without slowing the game down.

by on (#26483)
It doesn't matter if there is the MMC5 or not, as the MMC5 has the ability to show more tiles at once on the screen and to bypass the 2x2 normal color limit to implement a new 1x1 limit, it doesn't allow multiple backgrounds to scroll one on the other, so you'd still have to have the area behind both fighters blank. Unless of course one of the fighters doesn't move, which is just stupid.

by on (#26484)
The method I was thinking of allows background tiles behind the fighters, although it won't allow multiple scrolling backgrounds behind the fighters' action area as a disadvantage. This could be resolved by using the animating parallax tiles method as mentioned before, but the tiles would likely be repetitive like that. The ExAttributes could help have more fighter tiles rendered to the BG so that the background and fighters' attributes don't collide, and less sprites to fill for missing fighter areas that take up less than half a tile (since only fighter tiles that take up nearly whole tiles are rendered to the BG in my method). Although this method could also be done without ExAttributes, but that would require some more sprites for the fighters' missing areas.

by on (#26485)
He was suggesting a method to have big fighters while still having a background.

I think he meant that tiles that are fully occupied by the players (both of them) should be drawn to the background, while tiles with transparency would be rendered as sprites, surrounding those other tiles.

I think this is a good idea, but there are some problems. first, motion would not be very smooth, because when drawing stuff to the background you have to respect the 8x8 pixel grid, so it'd probably feel like some fighting games programmed for the Mester System. Also, even if we're just using sprites around solid tiles, there are many frames of animation where there aren't many solid tiles, and almost everything would have to be sprites anyway.

The "blank background" way can provide smooth animation for both players, since only one is drawn to the background and this background can be scrolled freely. I'd probably use 1-screen mirroring for that, with one of the name tables used for the background (with a blank area) and the other name table is exclusive to the other fighter. The screen would have to be split twice during rendering, to insert the background player in the blank area.

I'm still thinking of a good way to "fake" a more complex background while still having one player fully rendered with background tiles.

EDIT: Oops, too late! =)

by on (#26490)
Well, what you describe is quite insteresting, while it seems not doable.
This would work if both players moves by 8 pixels increments (both vertically and horizontally) AND if the mapper is MMC5 so that each tile get independant banking adressing and color, which is great. Then the game would have to redraw those tiles each times one of the fighters changes it's position or moves 8 pixels ahead, mazing the background back, and re-mazing the player further. I think it could look good if the player are really enormous, but then the graphics won't look too good either if the characters are just too big. Alternativly, you could duplicate each sprites (but decaled of 4 pixels and get 4 pixel increment, which is more decent, and quadruple all sprites (each time decaled of 2 pixels) to get 2 pixel increment, which would look good enough. Then each fighter for each poses has all it's "interior" made of background with 8 different variants (in function of the horizontal position), and both fighters moves horizontally by 2 pixels increment, and vertically by 8 pixels increments (they won't move much vertically anyway exept when they jump and when they fall). Additionally to this, both fighter's palette (assuming they use one) are redundant with the background, leaving 2 palettes for the background. Since the background is selected in function of one of the fighters (typically) this helps a lot. This sounds definitely doable, but only with the MMC5, and with a lot of CHR ROM. It can be done with another mapper, but then everything would have to be the same color (grayscale) and would look terrible, or have to move in 16 pixels increment, which is even more horrible.

I better like the idea of one figher BG and the other sprites, and this can be done easily, but with BG only above and below the fighters, which can definitely look decent. Honnesly, I already see the street background with houses on the top, a road in the middle which is made of solid grey where the guys fights, and a barrier with some people watching the fight below. Or even better, a beach where you have palm tree, etc.. on the top, solid yellow on the middle and the sea on the bottom. Seriously such backgrounds are easy to made. Additionally you can have the bottom scroll more than the top and give the game a 3D look. This would be done with vertical mirroring, and would work very well.

If jumping (or vertical moving) is allowed, this make things more complex, not only for collision detection, but also for animating the player themselves, especially if one is made of backgound. Additionally to this, as long as jumping is featured, the players can jump over the other and face another direction. If jump isn't featured, you can just assume player 1 is watching right and player 2 is watching left.
As for the size of the characters, they can definitely not be higher than 8 tiles : Because when they fall, the sprite player cannot be "longer" than 8 tiles, and it would look bad if he suddently become shorter because it fell. Maybe if he passes from 9 tiles to 8 this won't look too bizzare, but more difference will be noticeable. Of course, the CPU could automatically exchange the sprite and the BG player when needed (so when one fall, it automatically becomes the BG one to be more long), and I guess it would be rare that both player fell at the same time (depending on the game engine). I don't know if this would be doable.

Tokumaru : Are you really sure fighting game are that much easy to code ? Becuase I never trought about it seriously but now... I couldn't think about anything else the whole day ! I might do a fighting game after my current game is out if I get inspired for enough characters (and moves) ! And the advantage is that you can take your characters from other games you already did (you just have to add details to them). Maybe even stole characters from existing games : Imagine a NES fighting game called Capcom vs NESdev !! Wouldn't it rock ?
As for the AI of fighting game, I think having the CPU attempt random moves at regular intervals (and no nothing if the player blocks those moves) might work well enough, and making it so that normal mode have the CPU act slightly faster than easy modes where the CPU only kick and punches once in a while. Hard mode can have the CPU try to avoid and/or block kick and punches from the player more often (additional to quick attack when it get the chance to), but still do it with enough delays betwen actions to give the player a chance.