Enemy count in beat-em-ups

For the Super NES, this practically means eight characters at 2K each, with up to two animated each frame. This leaves time for OAM DMA and a little bit of background animation.

But before design of an original beat-em-up tech demo for Super NES can begin in earnest, we'll need two things. One is finding an artist to draw the player character animation and enemy animations. The other, less obvious job is choreographing how a character would actually fight seven opponents at once.

In many popular beat-em-ups, such as Teenage Mutant Ninja Turtles and Final Fight, the player can move in all eight directions but attack only to the left or right. This allows storing a character's animation cels in only one direction, which was important when Super NES Game Paks were rarely larger than 8 Mbit. But nowadays, memory isn't quite as much of a limiting factor as artist labor.

But enemies couldn't attack up or down either. So it was essentially up and down to choose on which plane to fight and left and right to move on that plane. This reinforced the same sort of "stand around and look busy" choreography described in "6 Absurd Action Tropes You Never Noticed And Can't Unsee" by Saikat Bhowmik, Nathan Wadowski, and Andrea Meno.

The fact is the Md can use all his VRAM for sprites, if you look at the SOR series, you'll can see that only the player's sprites (and maybe some bosses) have dynamic animations, the classic opponents stay in vram,and it's much easy to display 5/6 big sprites on screen, you must only take care of sprites per scanline limit .

The sprites managment is also better on MD, and permit to reduce the sprites flickering more easily .

And then make the backgrounds as detailed as ColecoVision or NES backgrounds, correct? If you use 48K of the Genesis's VRAM for sprites, you're down to one scrolling plane and few tiles for the background.

But that's all beside my point: If you're going to be animating 7 guys at 25 frames per second, you need an animator to draw those 25 frames that will be stored in the ROM and copied into VRAM. And you still need to choreograph each fight in which the cels shall be displayed. Are you volunteering for these tasks?

Yes, but even if the backgrouds are less detailled, can we consider they are at a nes or coleco level ??
And the deal is, detailled backgrounds and poor action, or the opposite ??

If you look at SOR 2 and 3, you can not say they are poor or bad,they only lack color .

And Haunted: Halloween '85 showed that 256 tiles at a time with about 10 colors can go a long way. But the Streets of Rage games also had teams of full-time animators working on their sprite cels. The limit I'm describing is not how much video memory, DMA bandwidth to video memory, or horizontal sprite coverage the system has. It's the "I need 2300 calories a day and a roof over my head" limit, and the "how's one guy gonna fight seven at a time?" limit.

i agree, but it's not a team that permit to displaying 6/7 big sprites on screen .

The final fight case is also a good exemple,looks at the Md version, it's awful on the color's side IMO, but there is 5/6 sprites on screen at same time .


Of course, but less you have to DMAing, and most chance you have to display more sprites because you can clone some of it without to care about if you have the DMA budget .

This why SOR 1 on the boat level can display 10/11 sprites on screen (of course,all sprites are smaller than FF or SOR 2/3)
https://youtu.be/bMsBkXGDix4?t=21m18s

What I'm saying is that I could make a demo of beating up 5 to 7 guys on the screen, provided that you provide a suitable set of sprite cels that I can legally use. My question was "Can I have a set of sprite cels to test with?" and your answer was "Mega Drive is better than Super NES for this application."

Oups sorry

if you want just make a proof of concept or a demo, i think you can use some arcade/consoles sprites rip without any risk .
http://spritedatabase.net/

I made this guy a little too big.

I can scale the sprite using any of several algorithms, but I'll need all movements and attacks animated.

Will sprites for an old obscure PC fighting game engine work?
You may just download any of the KOF91 packages and grab some sprites from the sprites/charlce folder. Also download the RSMAN.ZIP archive from this old page for another character.
These characters are definitely free to be used and butchered because well... I drew them. (The reason Ricesheet Man was not included in the engine package was that it was still of an older version that didn't contain all the required sprites for the new moves introduced in a newer version of the engine and I was yet to update it yet.)

Coffee Crisis (Gen) has up to 6 characters on screen at once (was 7 while in development, but later dropped as it was too hard, among other reasons), two players and four enemies. Even that occasionally has to delay an enemy frame update for a frame or two when running out of DMA budget.

That amount also hit the scanline limit when there were a few breakables on screen + the shadows. So, 8 is not really happening, unless they are small, or instances of the same enemy and with a small enough number of frames to fit the entire sheet in VRAM.

I made a quick rough animation.

I've drawn an awful sprite that I think matches the quality of the gameplay of Double Dragon (arcade).

Muscles, or tumors?

He looks like a Simpsons character.

Taking Streets of Rage 2 for example: A player character like Axel has 91 frames, and a basic enemy like Donovan is 16 frames, each roughly 48x72 pixels (excluding attacking appendage). Multiply by more than one player character and several enemies, and that's a lot for one person to draw.

If I remember correctly, there was a character called Kung Fu Man, from an old fighting game engine called MUGEN.
I think this character and all of his animations are free to use.
Unfortunatelly, I'm not sure...

Is the challenge to get 7~8 large characters on screen or 7~8 large unique characters on screen?
On the C64 I have on my sketch book a beat-emup with 6 characters on screen, but I'm more worried about AI handling the characters rather than the Drawing of them. I feel AI is going to be the killer.

As for how to fight, we could do it the Heavenly Sword way.. ie. stand around you in a ring and then they don't attack you for hours XD

Oh, poppycock!

My last major art commission was a set of sprites for a beat-em up, and I had animated just over 7200 sprite frames, in 3 months.
The characters were about 80x112, if I recall correctly. The hard sprite-frame limit was 192x144.

The final sprites were limited to 16 colors, and were hand-animated, scanned, and manually turned into sprites.

And how much does it cost for 3 months?

That's 80 frames a day.

At full time, a frame every 6 minutes is possible if you draw keyframes using vectors, let the computer make rough in-betweens, and then tweak them all. It's just a lot of money, and someone has to have a vision.

Furthermore, unless this process is done very carefully, you end up with lifeless animation that is extra-smooth, yet the added frames don't clarify the artist's vision.

You tell me! I wasn't paid for labor with this project. I didn't receive a single cent until it was done.

Specifically, the rights to about half the characters were purchased from me, by the developer. (the other character designs existed before I was hired.) This reason alone, is why I consider it a commission.


Heh! Yeah, that sounds about right. The amount of work per day varied, depending heavily on communication.

At one point, I had pulled an all-nighter, and did around 300-something frames of animation in 48 hours, for a large boss enemy.
It wasn't on a time crunch or anything, I just did it for fun!


Yuck. Vectors are by far the worst way to animate complex characters. Vector-based animation always seems to have a certain stiffness to it's motions.

Expensive, really? The project I mentioned, was completed rather quickly, and cost almost nothing to produce. 4 million dollars not needed!


Yeah, this is why I stick with traditional cell animation, and draw every frame out with pencils first.

(Important context: I was personally mentored by a former Gainax artist, when I was animating hentai, several years ago.)

Not every project can get an enthusiastic artist willing to work like you do, sadly. Most such flake, speaking from experience.

Well, I was trying to get something together for when I get done recoding my vram engine to make a miniature beat em up demo, and I decided to rip some graphics from Undercover Cops and use them, because, you know.

But anyway, this isn't very related, but the reason I posted is that, wow, the SNES port looks like shit (especially for 1995!), but damn, the music is surprisingly faithful... (compare "Redtailed Cat" from this http://vgmrips.net/packs/pack/undercove ... j-irem-m92 to this: https://m.youtube.com/watch?v=D3p1aBXLR4o) What really impressed me is that all the voice samples are there, and at nearly the same quality as the arcade version. Sure as hell beats SFII!

Yeah, they didn't even get the color palette right.

And that arcade machine uses 15bit RGB, with even the bits in the same order...

I'm still working on my animation. I'll get done for sure by next week.

By animation, do you mean animation engine, or artwork you've created?

Something I've began to think of is for me, metasprites are going to be a total pain in the ass to create. The problem is trying to figure out how to arrange everything to minimize the number of sprites per line is very time consuming. I don't know how feasible it would be to make a program that if you gave it an indexed picture (color 0 is transparent and would be able to be cut out) and told what you want to be the center point, if it could automatically generate the graphics and metasprite data.

Artwork. I'm drawing a character who is 160 pixels tall.



That was one of the reasons why I ditched the Gunstar Heroes port. I forced every sprite to fit inside a 4 16x16 cells, which got tiring very quickly.

I myself would need the latter. First there needs to be a set of plausible test frames with which a software architect can refine the design of the engine. But the skills to make artwork and an engine often don't coincide. I can volunteer only for the engine.


For The Curse of Possum Hollow, each actor type's sprite sheet was accompanied by a text file listing the coordinates of a set of rectangular slabs that cover each cel. The sprite sheet converter read this file and turned it into a list of 8x16 pixel sprite tiles for each cel, arranged in horizontal strips. Optimizing the slabs was manual but not too difficult or time-consuming. In addition, each cel on of a sprite sheet could have other values and coordinates associated with it, such as the duration of each frame, the position and strength of hitboxes that a sprite deals during each frame, and how it interacts with physics.

I don't think it would be that hard, sprites are not very big, so you could just do a brute force approach and get reasonable times, given you don't change your artwork every build, even if you have to leave it "overnight" it wouldn't really be an 'issue'. For making optimal bounding boxes around 3D objects for collision 'we' use to have a Genetic Algorithm that would "search" for the optimal solutions. Yeah it took all night, but 3D volumes is a lot larger search space than a 64x64 2D array
However I don't think the problem has a single dimension, sure min per line is nice, but you also have to be able to fit them all into RAM/ROM so you might want to optimise the player for example with min per line and min unique tiles. While a boss probably hang the RAM/ROM cost as they will be the only other thing on screen and flicker is your issue, so min per line.

I think there are few enough objects with identical sprites that you could manually make the metasprite. Anyhow, the way I'd do it is by looking for identical sprites first, and then do the least per line.

Hey, psychopathicteen, how are you handling the index registers and direct page in your metasprite routine? I thought I'd ask because I made it to where the metasprite data is indexed by y instead of direct page so it can be out of bank $00, but then I have to switch y back and forth between being a metasprite data offset and a sprite table offset, which is definitely slower than what I had.

I use X for metasprite data, and Y for OAM.

What about the object table then?

Saved to zero page and restored, I assume. Because there are a lot more metasprite and OAM table entries than object table entries, quickly accessing the object table in the draw step of the engine isn't quite as important.

During the move step, I tend to use X for the object table entry and Y for, say, the frame number or the other object's entry.