Was there ever an attempt to create a really good fighting game for the NES?
Apart from some very basic pre-"Street Fighter II" games like "Yie Ar Kung Fu", there is only one actual fighting game in the "modern" sense: "Turtles Tournament Fighters". It's a bit stiff in my opinion.
Then there are countless pirate games and most of them are crap.
So, has anything like that been attempted in the homebrew scene or am I missing some licensed game? (Apart from that one with the robots where the arms and legs only exist of separate balls.)
After all, the Game Boy had a whole bunch of good fighting games. "Mortal Kombat II" was a very good port. And the games by Takara ("Battle Arena Toshinden", "King of Fighters"). "Street Fighter II" was total shit, though. But "Street Fighter Alpha" for the Game Boy Color was very good again.
I know that the NES has the problem with more than eight sprites on the scanline. But, well, you don't necessarily have to create a game with huge, screen-filling characters. 16 x 32 or 16 x 40 should be big enough for detailed characters. Then you still have two more sprite widths per character for punches and kicks as well as a projectile. So, the flickering would only be an issue when a fighter is lying on the ground.
(Besides, I'm not so fond of the idea to create one fighter as the background since I prefer backgrounds that look interesting and not too plain.)
What I have no idea of: How do you implement the computer AI in a fighting game, so that it doesn't suck, but actually behaves like the real games?
And are there any other problematic things?
I think the problematic thing is that it's the NES.
There's nothing I can think of that theoretically prevents a game with Street Fighter II calibre gameplay on the NES, but it's just not a great target platform in general. The question is, why build a good fighting game on the NES when you could do it on almost any other platform and have an easier time of it?
I mention Street Fighter II specifically, because it was really the first fighting game of real quality, ever, in my opinion. When it came out, the 16-bit era had already begun, so by the time we had a model of what a good fighting game should even look like, NES development was already on its way out. The money for better games was mostly being sunk into the new platforms instead. (GameBoy, on the other hand, was strong while the 16-bit era of home consoles was taking place.)
Pirate games are crap because pirates don't care about quality. Quick cash-in ports have the same motivational problem, good ports are rare (and it's usually because they randomly got some passionate+competent developer assigned to them by accident). The amount of homebrew devs who can make a quality game is tiny, and probably none of those people wanted to make a fighting game for NES yet. That's basically it.
DRW wrote:
Apart from that one with the robots where the arms and legs only exist of separate balls.
You seem to have dismissed
Joy Mech Fight because of its graphics, but I think it might have been the best fighting game on the Famicom.
rainwarrior wrote:
The question is, why build a good fighting game on the NES when you could do it on almost any other platform and have an easier time of it?
Because if I want to have a good fighting game on the Super Nintendo, it literally takes 0 seconds to create one: They are already there.
But a good fighting game for the NES, that would really be something new.
I'm not sure whether it should be a port of an existing game, though, or a completely new one. "Street Fighter II" on the NES that plays exactly like the Super Nintendo version (apart from fewer attack methods due to the buttons) would probably be amazing. But it could be a bit too much and end up being undoable.
rainwarrior wrote:
The amount of homebrew devs who can make a quality game is tiny, and probably none of those people wanted to make a fighting game for NES yet. That's basically it.
Personally, I don't see creating the game physics as
too much of a problem if it's an original property and the characters are therefore designed around the graphical limitations. (Why do all the fighters have to do flips when they jump forward? Even Zangief does this in the arcade version.)
The one thing that I have absolutely
no idea of is the AI. Is there anything on the internet that explains how the computer opponents in fighting games were done?
rainwarrior wrote:
You seem to have dismissed Joy Mech Fight because of its graphics, but I think it might have been the best fighting game on the Famicom.
Not the graphics per se, more the strange fighters with their dislocated hands and feet. It's just not the same as playing with actual human characters like in "Street Fighter" or "Mortal Kombat".
There's one pretty decent and entertaining game you didn't mention: Joy Mecha Fight. It's Famicom-only but nothing prevents it from working on an NES. This game got around the sprite limit by making all fighters robots with disjointed limbs, à la Vectorman.
There are also a few fighting games for the Datach Famicom add-on (which apart from the barcode reader, was just a regular mapper), the most notable being Dragon Ball Z and Yuu Yuu Hakusho games. The sprite limit wasn't much of an issue due to the small size of the characters.
EDIT: Joy Mecha Fight was mentioned.
rainwarrior wrote:
The question is, why build a good fighting game on the NES when you could do it on almost any other platform and have an easier time of it?
To get included on the next collaborative NES multicart perhaps?
Quote:
The amount of homebrew devs who can make a quality game is tiny, and probably none of those people wanted to make a fighting game for NES yet. That's basically it.
I gather from previous topics on this forum that a lot of people
want to make a fighting game. They just lack the ability to draw 100 frames of animation for each character's moves.
Make a pencil test of Little Red Riding Hood and some furfag doing all their moves, and we'll talk.
I am currently making a game with a "large" (18x37 during idle) main character that has 69 unique animation frames. (Though a few are only one sprite different from other frames.) It's... not all that much fun to manage all that data. The code of a fighting game is not really tough (on a basic level. All the design stuff like preventing infinites could be), but managing the graphics, and managing the graphics around the sprite limitations is not all that fun. Edit: There are single frames that exceed the sprites per scanline limitation, and that's a single character. If you do things not with sprites, it gets harder for other reasons.
I've certainly considered making a fighting game with tinier characters, but like rainwarrior stated I may as well not do it on NES.
I would mention
Street Fighter III but it's a pirate game. It's the only pirate one that has physics even remotely resembling that of most fighting games though (everything else is lousy as fuck), and has some pretty damn good graphics. The biggest downsides are the music (
ugh) and sprite flicker (it uses overlaid sprites a lot).
Once I had a magazine including all the special moves for the characters in that game (this variant was that popular over here). It took up two pages to list them all =P
That Street Fighter III game is hands down the best pirate fighting game on the NES. It's almost commercial quality, IMO. Despite the flickering, the sprites look amazing. Had Capcom decided to release Street Fighter II on the NES, that would be the way to go.
It got some game magazine coverage here in Brazil back in the day too.
Another example of a good fighthing game (on my opinion) is
Ultimate Mortal Kombat 3. Despite the repetitive music and some flickering, the sprites looks pretty nice and the characters can be controlled quite well. But the game is an unlicensed one.
tepples wrote:
Make a pencil test of Little Red Riding Hood and some furfag doing all their moves, and we'll talk.
What an
odd coincidence! I had just animated such characters a few days ago, for a friends' furry porn game, as side characters! Furfag away!
Their inclusion was a silly joke, on my part.
(The game itself, is a beat-em up styled fighting game.)
Today, I found out that there is actually another fighting game for the NES called "Street Heroes". It's an unlicensed title by Sachen and pretty crappy, but the interesting thing is: It's actually a game with original characters, not a pirate version of an existing franchise like "Street Fighter", "Tekken" or that "Super Mario Kart"-based game.
So, my question: Since I never really checked those unlicensed and pirate or Chinese games, is there any other fighting game for the NES or Famicom among the list of unlicensed games that is an original property with its own characters that aren't taken from other games?
Of course, I'm only talking about the "modern" "Street Fighter II"-inspired fighting games. Not "Way of the Exploding Fist" or something like that.
Another original property fighting game: "Fighting Hero III". (But not the first "Fighting Hero". That one is a rip-off of the original "Street Fighter".)
Just as crappy as the rest, though.
tepples wrote:
Make a pencil test of Little Red Riding Hood and some furfag doing all their moves, and we'll talk.
Coincidentally, I had a concept for a fairy tale-themed fighting game that would include Little Red Riding Hood and the Big Bad Wolf. It would also have Alice and Dorothy Gale.
Now if only I could have some time off from work once in a while to do some sketches...
DRW wrote:
I know that the NES has the problem with more than eight sprites on the scanline. But, well, you don't necessarily have to create a game with huge, screen-filling characters. 16 x 32 or 16 x 40 should be big enough for detailed characters. Then you still have two more sprite widths per character for punches and kicks as well as a projectile. So, the flickering would only be an issue when a fighter is lying on the ground.
(Besides, I'm not so fond of the idea to create one fighter as the background since I prefer backgrounds that look interesting and not too plain.)
"Jang Pung 3" on Sega Master System is visually pretty impressive. Characters are very big and I guess they're all made of sprites.
Maybe a game like this could be possible on Famicom/NES (with less colors, of course).
The Master System has a few decent looking fighting games, some using the background (Mortal Kombat, Street Fighter) and some using sprites (Masters of Combat), but both techniques work much better on that system, due to tiles being 4bpp instead of 2bpp like on the NES.
On the NES, I'm of the opinion that the best approach is that used by the pirate Street Fighter III game. Sprites using multiple palettes with some overlaying. Sprites have to be carefully designed to reduce flickering, but the increased amount of colors per character makes all the difference IMO.
tokumaru wrote:
On the NES, I'm of the opinion that the best approach is that used by the pirate Street Fighter III game. Sprites using multiple palettes with some overlaying. Sprites have to be carefully designed to reduce flickering, but the increased amount of colors per character makes all the difference IMO.
Yes, due to their over the top designs, characters from games like Street Fighter or Jang Pung 3 would require overlaying on the NES to look good- no doubt about it.
However if I *had* to use sprites without overlaying I would carefully design "NES-optimized" characters with a few details and colors. Bruce Lee/Liu Kang sprite from "The Dragon" is a good example:
A guy with black pants, black hair, no shirt and no shoes (despite he had shoes on MK1). Sounds so simple but the result is very good for a NES character. He even had some of that photorealistic feel from the original Mortal Kombat.
So before starting with overlayed characters I believe it would be interesting (at least try) to design a team of fighters with 3-color optimized outfits (still preserving human proportions on them). Something like a realistic version of Yie-Ar Kung Fu.
The problem is that everyone needs a skin tone, and another one to shade it. This Bruce Lee guy turned out so well because black clothes need no shading, but you can't have every single character in the game wear black and have black hair, otherwise that will be one very dull-looking game. I don't think what you propose is impossible, but finding good 3-color schemes that will allow you to shade clothes and skin will be a challenge.
Contra and Kart Fighter use multiple palettes per character, just not overlaid. Can you have two palettes for player 1 and two for player 2 in this manner?
That's better than a single palette, but with all the crazy poses and moves a fighting game character has, it might be hard to stitch the tiles properly every time. And you'll most certainly have to repeat at least one color in the second palette to help with the stitching too, reducing the benefits of having a second palette.
But even if you repeat one color that's still five colors to play with... certainly a lot better than three colors for the entire sprite. So I'd say that yes, it's still very useful. Just beware that if you ever do fireballs or the like, they'll have to use one of those two palettes.
I would take a mixed approach: Do whatever you like. Overlay, no overlay. Just make sure that no sprite ever has more than four tiles per line. Then you can decide the style on a character-by-character basis.
I also don't think that fighting game sprites need to be huge. 16 x 40 should be good enough. This makes two tiles for the width and then you still have two tiles for attack animations and general color stuff.
This is the main character for my upcoming game. It's not a fighting game, but I could imagine her in one:
Attachment:
Amy.png [ 1.15 KiB | Viewed 2034 times ]
Two palettes, no overlays. And a design that would, as far as I can see it, make it easily possible to design a kick animation without exceeding the four tiles.
tokumaru wrote:
The problem is that everyone needs a skin tone, and another one to shade it.
Depends on your art style. Honestly, I think the best art style to go with would be, black, flesh (when applicable), and accent color.
Project LinkThese are stylishly well executed, and very similar to the comic work of David Aja.
In fact, I'm using a similar color scheme for a character in an upcoming NES project.
Although I didn't use black (My current style set for that game is: black outlines and shadows in the background, no black on sprites.), it is still basically: dark, flesh, accent.
So, if I were to do a fighter on the NES, I would have characters roughly the size of the one above (a bit smaller than most fighters) and letterbox the screen to put HUDs, etc. out of the main combat (and to reduce the amount of dead area that needs decorating with background art.
If I wanted 8 colors per character, I wouldn't be making games for the NES, and I honestly think folks jump too quickly to "we can overlay sprites" or "we can use MMC 5" when they start to hit their limits instead of getting creative.
M_Tee wrote:
I honestly think folks jump too quickly to "we can overlay sprites" or "we can use MMC 5" when they start to hit their limits instead of getting creative.
Overlaying sprites IS creative when done properly. Good overlaying actually keeps overlaying to a minimum.
M_Tee wrote:
These are stylishly well executed, and very similar to the comic work of David Aja.
I'm glad that psc is still working on his MK demake. He's very talented.
Yeah, I've been impressed since he first showed it to me. It totally knocks any pirate fighter out of the water. I didn't think a MK game would ever interest me. haha.
And, he uses some multi-palette characters as well (Jax, Shao Khan), but still subtly done.
M_Tee wrote:
If I wanted 8 colors per character, I wouldn't be making games for the NES, and I honestly think folks jump too quickly to "we can overlay sprites" or "we can use MMC 5" when they start to hit their limits instead of getting creative.
The main difference is that in fighting games the only sprites are player related, and since there are four sprite palettes, that means we get two palettes per player. So in this particular situation yes, using two palettes for player sprites makes perfect sense without even trying to stretch things, there just happen to be enough palettes to spare.
M_Tee wrote:
In fact, I'm using a similar color scheme for a character in an upcoming NES project.
Just a little note, a little piece of knowledge that I learned from watching my graphics artist do the sprites: This leg movement needs work. You should definitely draw some diagonal lines for the second animation frame and not just move the sprite up and down.
Thanks for the feedback, DRW. I'll keep it in mind.
Two palettes per character isn't horrible. Especially if you maintain rough divisions like pants/torso, Contra style.
Jax in the above image uses black, brown, grey for torso and black, red, grey for legs. It adds a single extra color, and by reusing two colors, prevents the need for excessive sprite overlapping. If he were to try to use six unique colors, he'd be overlapping frequently to hide the palette borders.
However, you'd need to keep in mind projectiles/ impact graphics, etc. as well. A lot of characters' projectiles and whatnot could simply use one of their palettes without the darkest color. But I imagine there will be times when you'd want certain characters to have projectiles/effects that don't share their main palette, in which case, maintaining a simple enough style that a single-palette character wouldn't stand out.
Where the Street Fighter III pirate looks good in screenshots, it's overkill in regards to flicker. I'm just saying that in my opinion, a more streamlined style like psc's MK3 is a better solution than the SFIII posted above.
EDIT:
I just noticed this post which hits the same beats, and yeah. I agree.
Sik wrote:
But even if you repeat one color that's still five colors to play with... certainly a lot better than three colors for the entire sprite. So I'd say that yes, it's still very useful. Just beware that if you ever do fireballs or the like, they'll have to use one of those two palettes.
M_Tee wrote:
Thanks for the feedback, DRW. I'll keep it in mind.
What kind of game will this be, by the way?
M_Tee wrote:
However, you'd need to keep in mind projectiles/ impact graphics, etc. as well. A lot of characters' projectiles and whatnot could simply use one of their palettes without the darkest color. But I imagine there will be times when you'd want certain characters to have projectiles/effects that don't share their main palette, in which case, maintaining a simple enough style that a single-palette character wouldn't stand out.
If you don't try to port a game, but create an original property, then the problem doesn't really exist: You simply design projectiles in a way that they work with the two character palettes.
Unlike in a port, you're not forced to let a red character use a blue fireball. You could just design the red character to use fire-based attacks in the first place and the blue and white character to work with energy-based projectiles.
Sure, Blanka's electricity could be a problem in an NES game when you already used up all six colors for his regular sprite. But if you program your own game, you can just decide not to invent a character like Blanka in the first place.
That's the way NES games should be designed: You don't design a character and then ask yourself later: "How can I force him into the NES limitations now?" Instead, you design a character by asking yourself first: "What is the NES capable of, so what should I pay attention to in my designs?"
Dhalsim wouldn't work so well in an NES fighting game. But if Dhalsim had never existed to begin with, nobody would have asked: "Hey, why doesn't "Street Fighter II" have a fighter who can stretch his limbs?"
Likewise, nobody will miss a certain character design aspect that you decided not to include in your game at all.
Yeah, man. You and I are totally on the same track: design the characters and their abilities to the restrictions.
As for the game that character's from: point and click adventure, hence the relatively large sprite. I think the programmer plans to announce the game in a few months, closer to completion. All graphics assets for the first of six chapters have been completed so far.
M_Tee wrote:
Yeah, man. You and I are totally on the same track: design the characters and their abilities to the restrictions.
I'm playing with the thought of actually making an original property NES fighting game when my current game is finished and published. The problems: I wouldn't be able to convince my graphics artist to draw me 10 times the graphics that she did for the current game.
Oh, yes, and computer AI: That's also something where I have no clue yet. Everything else should be pretty easy. And music.
A different question:
Let's say I want to do a fighting game and I want to use one of the very common mappers. I.e. nothing too obscure. I would need one of the mappers that were used frequently for games, so that I would be able to easily find a donor cartridge.
The only thing that the mapper really needs to be able to do is letting me copy graphics from any place of the ROM into the pattern tables.
Other than that, I wouldn't need anything mapper-related. No interrupts, no 8 x 8 background attributes. And if I want to do parallax scrolling, I would use the nine sprites overflow flag for the status bar plus the sprite 0 flag for the parallax, like I do in my current, mapper-less game.
The speed of the copy process isn't critical.
My idea is that every fighter with all its animations and projectiles fits into 128 tiles.
Likewise, the background could use 256 tiles minus the general stuff like text and status bar. Of course, some of the tiles would be for animating the background.
So, during the action, nothing in the pattern tables would be changed.
So, what limitations would I encounter?
Let's say the game logic occupies the standard 32 KB.
How many fighters and backgrounds could I include?
By the way: No battery would be used.
DRW wrote:
How many fighters and backgrounds could I include?
Are you honestly asking this question hoping someone here can answer it for you?
To know what you can include in your game, plan out your space and make an estimate. That's an important part of making a game when you don't have unlimited resources.
To geta meaningful answer, you need to plan all the data formats needed (how to store sprites, how to store animations, how to store backgrounds, etc.), and create size estimates for these. You also need a comprehensive plan of character control (how many sprites needed, how many animations, etc.). There's no standard answer to these questions that someone could use to estimate it for you; you need a thorough design plan.
Once you have all that work done, it's really just simple arithmetic at that point to figure out how many will fit.
Of course, you can go at it the opposite way to, and say "I want 7 characters" and then figure out how much space you have for each, then design everything to fit in that space. A good approach is probably to do a vertical slice, implement all of or most of a single character, and then see how much it takes up. Test compression methods, if applicable, etc. (Does that sound like too much work just to answer this question? Yes, of course it is, which is why nobody can or will answer it for you. In a professional setting answers to this kind of question cost a lot of money to get.)
TLDR: 5. You can have 5 characters and 5 backgrounds. No more, no less.
DRW wrote:
My idea is that every fighter with all its animations and projectiles fits into 128 tiles.
Good luck with that, unless you'd be happy with animations comparable to those in
Pro Wrestling.
rainwarrior: Given what DRW wrote, the CHR size estimate for a fighter is 2K and the CHR size estimate for a background is 4K. On top of that, you'd need extra backgrounds for the title screen, the fighter select screen, and each fighter's ending.
rainwarrior wrote:
To know what you can include in your game, plan out your space and make an estimate.
Isn't that exactly what I did? I said if we assume that the game logic is 32 KB and each character is 128 tiles and a background is 256 tiles minus some general stuff: How much would I get into the game if I want to use a really common mapper?
So, I never asked for subjective game design decisions. I laid out a very clear model and now I just want to know: What mapper can do this and how much space would I have? (Assuming that I want to use a mapper that is very common and there are countless donor cartridges, so I don't have to search for some really obscure or rare stuff.)
tepples wrote:
Good luck with that.
What do you want to say with that?
tepples wrote:
On top of that, you'd need extra backgrounds for the title screen, the fighter select screen, and each fighter's ending.
That's some of the subjective stuff that I'll figure out myself. In the moment, I just need to know which of the suitable and common mappers give me how much room to do this.
128 tiles is too little for all frames of a fighting character, unless it's really small, has few attacks/moves, and doesn't suffer many types of damage. This would make the game feel nothing at all like Street Fighter II, which is the epitome of 16-bit fighting games.
32KB of code + graphics won't get you very far, seeing as each fighter's graphics would occupy 2KB. Each Fighter would also need a reasonably sized set of meta-sprite definitions. There's also A.I., physics, and many other things to account for. 32KB might be enough for a barebones proof of concept with a handful of fighters, but not much else, IMO.
UNROM, one of the simplest and most common mappers, would probably be a good choice for such a game, if you really don't plan on switching tiles during gameplay, which I honestly wouldn't recommend in a fighting game.
tokumaru wrote:
128 tiles is too little for all frames of a fighting character, unless it's really small, has few attacks/moves, and doesn't suffer many types of damage.
I would probably use a size of 16 x 40 for the standing character.
tokumaru wrote:
This would make the game feel nothing at all like Street Fighter II, which is the epitome of 16-bit fighting games.
I'll think about that when I actually get to plan the game. In the moment, it's just general curiosity.
tokumaru wrote:
32KB of code + graphics won't get you very far, seeing as each fighter's graphics would occupy 2KB. Each Fighter would also need a reasonably sized set of meta-sprite definitions. There's also A.I., physics, and many other things to account for. 32KB might be enough for a barebones proof of concept with a handful of fighters, but not much else, IMO.
The 32 KB would be just for the game logic (and mabe for the meta sprites). I was talking about 32 KB + an unknown number of KB for graphics.
Is there a list of each mapper that says which games use that mapper? Or rather, the list should be: Which games use which version of the mapper? (In case the same mapper is capable of using different ROM sizes. If a certain mapper is very common in its 64 KB version, but very rare in its 1024 KB version, the fact that the mapper can use 1024 KB isn't so helpful.)
If you consider that even very small characters like Kirby can't fit all their animations in 128 tiles, and that he's in a platformer, which typically need less moves than fighting games, it's safe to assume your fighters will end up really stiff.
For a proper fighting game, something like the MMC3 would be more suitable. It's also very common, and finding donors will not be a problem. From a technical point of view, it can't get any easier: every frame, just swap the tiles for the current animation frame. Drawing all those frames, on the other hand...
DRW wrote:
Is there a list of each mapper that says which games use that mapper? Or rather, the list should be: Which games use which version of the mapper? (In case the same mapper is capable of using different ROM sizes. If a certain mapper is very common in its 64 KB version, but very rare in its 1024 KB version, the fact that the mapper can use 1024 KB isn't so helpful.)
One of the oldest references is
this list. It lists boards but no other details, and doesn't include Famicom releases.
Here you can read the details of each board. And don't forget
Bootgod's database, which contains nearly all games from every region, each having its own page with details about chips, memory sizes, and so on. You can search the database based on various parameters (by mapper, ROM size, RAM size, date, and many many more).
Quote:
Let's say I want to do a fighting game and I want to use one of the very common mappers. I.e. nothing too obscure. I would need one of the mappers that were used frequently for games, so that I would be able to easily find a donor cartridge.
You don't need donor cartridges. They can build new cartridges from scratch these days.
I would pick a common mapper, though.
INL for example has a wide selection of newly made NES boards and mappers.
DRW wrote:
rainwarrior wrote:
To know what you can include in your game, plan out your space and make an estimate.
Isn't that exactly what I did?
No, I outlined what you
didn't do in my response.
If your question is "how many times will 128 tiles fit into CHR ROM/RAM of size X" I would recommend finding a calculator with a working division key.
I suppose the real question was probably "what mapper should I use", but that's not really a simple question either. (Though I'm sure people here will oblige you with 100 different answers to that one.)
There's some useful comparison of mappers here:
http://wiki.nesdev.com/w/index.php/Comp ... do_mappersAnd some data on which mappers are most common here:
http://bootgod.dyndns.org:7777/stats.php?page=6Aside from common ones, most "discrete logic" mappers are easy to build. Some less common ones have been favoured for homebrew because they're practical (e.g. BxROM).
Personally I'd probably want to use 32k of CHR-RAM with at least 2k banking granularity (i.e. one for each active character). Probably MMC3 compatible subset of banking features, with iNES 2 header specifying CHR RAM size. Emulator support for that might be a bit dodgy, though; iNES 2 is a work in progress.
You'd have a maximum of 14k (896 tiles) per character, and could use compression too.
Many kind of ideas are possible such as vertical fighting game instead of horizontal (which can partially work around sprite limits), and it can depend on other things too. I happen to like VRC6 and the advanced CHR features (many implementations are incomplete though) may help with game having so many characters (although other mappers may also be suitable; much depends what game you are making). Another idea if you want double blinds you can do: Push "A" button and then the directions corresponding to which character/command/etc you want (one combination may be assigned to mean random selection), and then push "B" button; opponent will not know which selection you have made. If you push too few or too many directions, or an incorrect checksum, then it will not accept it and you must try again.
zzo38 wrote:
vertical fighting game
That's what
Punch Out's mapper was designed for. Though Punch Out is also relying on having one fixed character (little mac).
Another CHR-RAM option that would work with easy/common mappers (i.e. no banking) is just uploading a whole sprite every frame, possibly with "letterboxing" black bars at the top/bottom, and possibly with double-buffering and a lower framerate (e.g. 30hz or 20hz would double or triple your bandwidth). Only the sprite transitions need to be at the lower framerate, you could still move characters around at 60hz; they just might have to wait 2 or 3 frames before the sprite changes. (I think this might have been suggested in an earlier thread...)
rainwarrior wrote:
Another CHR-RAM option that would work with easy/common mappers (i.e. no banking) is just uploading a whole sprite every frame, possibly with "letterboxing" black bars at the top/bottom, and possibly with double-buffering and a lower framerate (e.g. 30hz or 20hz would double or triple your bandwidth). Only the sprite transitions need to be at the lower framerate, you could still move characters around at 60hz; they just might have to wait 2 or 3 frames before the sprite changes. (I think this might have been suggested in an earlier thread...)
In other words, what
Battletoads and
Haunted: Halloween '85 do. A moderately unrolled NMI handler can copy 128 bytes (8 tiles) without letterboxing and without crazy unrolling, meaning that a sprite cel taking 16 tiles can be pushed in 2 frames for an overall animation frame rate of 15 fps for both players. And if you know that a particular cel is most likely to follow the current cel, you can preload the next cel when nothing else is animating, reducing lag for the next frame to appear.
Curious? Read
details in another post.
tokumaru wrote:
If you consider that even very small characters like Kirby can't fit all their animations in 128 tiles, and that he's in a platformer, which typically need less moves than fighting games, it's safe to assume your fighters will end up really stiff.
Yeah, I had a look at "Battle Arena Toshinden" for the Game Boy today. Even this game uses much more, so I would probably need/switch the tiles on demand and had to use another technique.
tokumaru wrote:
Drawing all those frames, on the other hand...
That's the reason why this is nothing more than a thought experiment now: The graphics would be plenty. As of now, I would need eight or nine characters, five backgrounds and intro and ending scenes for each fighter.
I can't draw myself and I doubt anybody would do such a huge work for free.
Well, my graphics artist agreed to do the graphics if I get enough money from Kickstarter to pay her $50000.
The only good thing is that I would use smaller characters. Not huge ones like in "Turtles Tournament Fighters", but more like in "Kung Fu", to minimize flickering.
About the mapper list: I guess the only way to list the mappers in the way I need (each version of each mapper together with all games for this specific mapper version) is to write a little parser for the Bootgod XML files.
dougeff wrote:
You don't need donor cartridges. They can build new cartridges from scratch these days.
Sure, but I like the thought that I could put the game on a common cartridge that was actually released back in the day, even if the actual cartridge is created from all-new pieces.
zzo38 wrote:
Many kind of ideas are possible such as vertical fighting game instead of horizontal (which can partially work around sprite limits)
What do you mean with vertical fighting game?
A game like "Punch Out"? (Meh. If I ever did an NES fighting game, it would be a typical one in the tradition of "Street Fighter II", not something totally different.)
Or a game where you have to turn the TV on its side? (Not really acceptable for an NES game that could be played anywhere, like an LCD TV. This only really works for arcade games.)
Quote:
pay her $50000
I'll do it for only $39999
Hmm. But are you able to do very high quality graphics? I know that my graphics artist can do this. So, what reference graphics can you show me?
Is there anything from your graphics artist that you can post? It better be good for a year's salary.
I guess it was more a joke since I'd never make 50000 for an NES game. But let me show it to you anyway:
By the way, I consciously asked her to create simple-styled characters because I wanted the game to look like one of those first generation black boxart NES games, so she definitely could also use a graphics style that's like the later games.
She also drew me an anime-styled artwork for my main character that I put into the title screen, but I won't spoil this until the game is out.
And I have seen her hand-drawn work and it looks professional.
I'm assuming you're using line scrolling because of the gray area? I'd think the construction site would be red or gray instead of green. If the crane is using the green color, you could have it start over the trees and end right before.
Espozo wrote:
I'm assuming you're using line scrolling because of the gray area?
If line scrolling is parallax scrolling, then yes.
Espozo wrote:
I'd think the construction site would be red or gray instead of green.
Doesn't work since it shares the colors with the trees.
Espozo wrote:
If the crane is using the green color, you could have it start over the trees and end right before.
Huh? What do you mean?
DRW wrote:
Huh? What do you mean?
Have it to where the top and side of the crane are in separate attribute areas than the building, so no part of the crane overlaps the construction site.
I don't much care for that dither pattern on the buildings... reminds me of Christmas sweaters.
Do you mean the pattern of the fog?
How would you design the fog then?
DRW wrote:
Why should I do that?
In order not to make the construction site appear green but still have the crane.
I don't have a problem with a green construction site. We already have a red/brown factory and some chimneys. Also, the foreground is red/brown.
There's totally nothing wrong with the green construction site. Tediously holding onto local color restrictions is completely unnecessary. (By local color, I mean, "It's an apple. It must be red. The table next to it must be brown.")
In terms of color theory, there are two completely valid reasons to deviate from such restrictions: the first is
relative color (In this example, it could be that the color is cooler than necessary because its perception is affected by the water molecules in the atmospheric between it or the viewer, the representation of which is referred to as atmospheric perspective.) The second is merely
aesthetic, aka
it looks better. This could be justified in the use of green for complementary contrast (according to the traditional painters RYB color wheel) to the red next to it while the blue in the sky and the background provides the same contrast to the orange in the foreground.
So, long story short: no, a red apple does not always have to be red, and the background graphics in the owl shooter posted earlier are a prime example of embracing that.
@DRW
K-Han Games uploaded a video of an in-progess preview of the point-and-click adventure we were discussing earlier.
http://www.nesworld.com/?fn_mode=comments&fn_id=224 (forgive the cheeky self-promotion).
EDIT:
For clarity.
Also, that mockup seems to have an Urban Champion successor feel to it.
M_Tee wrote:
@DRW
K-Han Games uploaded a video of an in-progess preview of the point-and-click adventure we were discussing earlier.
http://www.nesworld.com/?fn_mode=comments&fn_id=224 (forgive the cheeky self-promotion).
Looks pretty nice.
M_Tee wrote:
Also, that mockup seems to have an Urban Champion successor feel to it.
I forgive you this statement because you were just referring to the graphics. I wouldn't have forgiven you if you had referred to the gameplay.
Because "Urban Champion" is shit.
Well, yes, it's a game that plays in an urban setting. And it's a pre-"Super Mario Bros."-style game with graphics like in the black box games. But we didn't get our inspiration specifically from "Urban Champion".
By the way, that's not a mockup. That's an actual screenshot from a working ROM. The game is nearing its completion. We need one more boss character, some small, non-challenging stuff (like including the story texts and creating an intro scene with the sprites) and a good bunch of cleanup (simply because I want clean code). And that should be it.
That's rad. I didn't read all of the last couple of pages carefully, so I must have missed that it was from the ROM. Regardless, it looks solid. And, yeah. I was referring to Urban Champion's aesthetic and definitely intended as a compliment along the lines of "That era seems to be the look you were going for, and in doing so, it's successful."
As for gameplay, would have to play it or at least see a video before I could comment on that. But it looks like it'd be fun
M_Tee wrote:
As for gameplay, would have to play it or at least see a video before I could comment on that. But it looks like it'd be fun
Yeah, well, I plan not to release any videos until the game is actually finished.
But I can generally tell you what the gameplay looks like:
It's an arcade-like platformer game. The levels are randomized (height and length of the buildings, width of the gaps, opponents) with the randomizer picking potentially more difficult platforms, gaps and opponents in the later levels.
There are four levels where the background changes from day to evening to night. (That skyline is always the same, but the colors change.)
It's a highscore game, so after the fourth level, it loops with more difficult enemies.
But from a story perspective, the plot ends after the fourth level and you get a little "cutscene" and then a text description of the story's ending with an ending song.
The second loop is the hard mode, but it doesn't have any story relevance like in "Kung Fu" where the game implies that Sylvia was kidnapped again.
I even programmed the game in a way so that the character dialogs, the cutscenes and the ending text only appear in the first loop, to emphasize the fact that the other loops are not "Amy fights the evil gang
again", but that they're just gameplay and don't "happen" within the plot.
The screen is auto-scrolling. If you get caught by the left side, you lose a life.
Your movement is totally tight. If you press the d-pad, you start moving instantly. If you release it, you stop. You have full horizontal control during jumps. But you cannot control the height of the jump. That one is fixed.
The game is pretty hard because there are always three opponents on the screen: Two people and one flying drone. If one of them falls off the screen, the next one immediately appears. So, if you want to have a little rest, you can stun an opponent with your taser, so he cannot hurt you anymore. And then wait until the screen catches up with him. As long as he's on the screen, no other opponent will fill his slot. (This doesn't work with opponents who fall off the screen when being attacked, though, since their disappearance immediately triggers the next opponent.)
DRW wrote:
How would you design the fog then?
I made a noisier pattern. Not perfect, but I don't see Christmas sweater when I look at it.
The only part I edited was between the white building and the crane.
Thanks for the suggestion. But I guess we'll leave it as it is.
The reason: If I include an irregular pattern like in your example, this implies that the fog actually has such a pattern.
The way it is done in our case, the pattern just means that the fog gets thinner and thinner. It goes from 100% fog to 3/4th fog to 50% fog to 1/4th fog. It's not actually supposed to be a pattern like if you had a surface of sand where irregularities make sense.
If this game was on the Super Nintendo, it would be a transparency effect from full gray to full background color. Since we don't have transparency here, the simulation of that effect is a completely regular pattern where the amount of gray just gets smaller and smaller.
Anybody thought about using tile-based characters? Make the characters fit inside a 8x8 grid as much as possible, and make backgrounds mostly pastel colors so the color clash isn't very noticeable.
I'm not really sure what you mean. (I assume you talk about the fighting game again, not about Dougeff's comments about my screenshots.) Do you mean that characters should consist of background tiles? Otherwise I don't know what you mean with tile-based characters since everything on the NES is tile-based anyway.
Like Golden Axe on the SMS, where the characters themselves are drawn on the backgrounds and move 8 pixels at once.
It works on the SMS because tiles are 4bpp, it'd never look on the NES.