Progress Thread -- Super Smash Bros. NES

I've been working on this game for about 6 months, on and off. I just graduated college, so I'm back to working on it. It's using the Kirby's Adventure cart (MMC3 512K PRG, 256K CHR) for maximum graphics space, but I don't intend to ever make cartridges because of copyright issues.

It's a demake of Super Smash Bros. for the NES. The character roster is all Smash Bros characters who had NES games:

• Mario, as seen in Super Mario Bros. 3
• Green MarioLuigi, as seen in Super Mario Bros. 3
• Peach, as seen in Super Mario Bros. 2
• Kirby, as seen in Kirby's Adventure
• Link, as seen in Zelda II, Link's Awakening
• Samus, as seen in Metroid
• Mega Man, as seen in Mega Man 1-6
• Marth, as seen in Fire Emblem: Ankoku Ryuu to Hikari no Tsurugi

I have a working game engine with platform collisions and a lot of art, but that's about it so far.

I want to stay true to the style of the original games as much as possible. However, Samus and Marth were designed for pure black backgrounds, so I had to modify their sprites quite a bit. Working around the NES limitations, I came up with this scheme:

The palettes are allocated like this:

• Palette 0: Player 1 colors
• Palette 1: Player 2 colors
• Palette 2: Player 1 accent color, Player 2 accent color, white
• Palette 3: Black, item accent color, white

This means that the player sprite could use 4 arbitrary colors plus black and white, without affecting the other player. For example, Mega Man's face uses palette 2, for tan skin and white eyes. Marth's sword uses palette 3 for black and white. If it doesn't create too many sprites per scanline, he may also have light blue accents. The accent sprites need duplicates for player 1 and player 2 versions. Sprites have two layers, but otherwise the ordering is undefined.

The MMC3 can bankswitch 4 separate banks of the sprite tileset. Each player gets one, the interface elements get one, and the current item gets one. The stage can also bankswitch its halves to have animated backgrounds.

There are a lot of graphics that need to go into the game. I manually created metasprites for all of Peach's frames with a tool I created, but that's a difficult process. I draw the characters in a graphics program, so I need to separate each frame into sprites, eliminate duplicates, define the position and attributes of each sprite, etc.

I have automated a few things: every image I want to convert to NES format has an extra row along the top for palette information. The first 4 pixels define a palette. I automatically map the RGB color to the nearest NES color in a LAB color space.

I use Aseprite to create the animations. This lets me use layers and assign tags to frames. Aseprite converts the .ase file into a sprite sheet png and JSON file with information about each frame, layer, and tag. Certain names are special: the layer name "Accent" will have the accent palette, for example, and the frame tag "Common" can contain projectiles which should appear in each of the player's banks.

I'm working on turning that information into metasprites and image data. Each frame can have multiple layers, and I need to find a good decomposition of them into 8x16 sprites which minimizes the number of sprites total and number per scanline. I don't even care about getting an optimal solution, but getting a good one is hard.

Since you use copyrighted sprites and characters, I think this runs foul of the compo rules?

I was thinking of demaking smash bros myself, but everytime I started thinking about it in depth, I never could map the controls to be comfortable.
I wish you luck, as I'd like to see this completed.

@calima, no, he can still submit it for 2nd category, "anything goes".

If it does, that's fine. I have an idea for an original NROM game that I might work on for a while for the cartridge category.

And if you make the source available, you can bring on another artist to replace all characters.

In 2014 rules, the copyright rule applies to both categories, not just the for-cart one.

Also, if you're advertising it as 'Smash Bros', it doesn't matter if it has new sprites, it's still kind of a violation. Call it something else. ... Ultra Punch Sisters

I will definitely make it clear that I'm not affiliated with Nintendo, probably by including "fan game" in the title.

If people want, we can move this to the Homebrew Projects board.

On your palette setup, one thing you could do for projectiles is flicker between palettes for unique colors. A good example of this is Rose's fireball in Street Fighter Alpha Game Boy Color: https://www.youtube.com/watch?v=kiZgy8Vv1xo (1:37). Of course YouTube is affecting the framerate here, but for fireball effects it can work quite well.

As for the project title and legality, you should look at Super Smash Land by Dan Fornace. One nice thing about that project was the unique title. I think you should consider a sub-title or changing it up a bit, like: "NES SMASH BROS", or "SMASH BROS ZERO". Maybe if you used unique art it would be less likely to get shut down too. But I see that Tepples isn't complaining, so you must be doing something right.

It's hard to complain with my hands and mouth full of popcorn.

(seriously) For now I'm sitting on the sidelines, hoping it'll be moddable for original characters.

I have to be honest here; I do not like seeing the word Zero on any completed game title, where Zero is the chronological number in the series of games. I remember reading lists of games in development that had these in their working title, and they were always sure to change...

but one studio decided to break convention, and ever since then it became a trend.

There is only one prefix I'm sure of for NES, so it'd have to be "Family Smash Brothers".
After all, the GB game is Super Smash Land, after Donkey Kong Land, Super Mario Land…

Street Fighter in Japan goes Street Fighter, then Street Fighter Zero, then Street Fighter II in story order. In North America and Europe, it makes slightly more sense: Street Fighter, then Alpha, then II. (II was released before the interquel Alpha.)

Besides, the prequel to Super Smash Bros. already has a title. It's Kart Fighter.

And then it all goes down the drain anyway when the sequels for SF2 go in the following order: 4, 5, 3.

Updates:

I now have a system that converts my animations in aseprite to chr files and metasprite definitions. I spent a long time trying to optimize the conversion, but it is a difficult computational problem. My first try at mostly brute force worked great for images that need at most 3 sprites, but 4 sprites took ~3 minutes. Exponential growth is no joke. So, just to get things going I made the simplest solution that could work: each metasprite is a non-overlapping grid of sprites, aligned with the top-left edge of the image. I don't do any deduplication of images either. This will cause it to use a lot of chr space and a lot of sprites on screen at once, but I can always optimize it later. For now, my 256K of chr space makes it a non-issue.

My metasprite definitions are pretty simple. They are a list of 4 bytes sprites, in a similar format to the oam memory, but in a different order. The bytes are attribute, x, y, and tile. The attribute byte is first as a marker: I set bit 2 of each attribute byte, which is otherwise unused. I know when the metasprite is done when I find a byte equal to zero, the null terminator.
I will need to add a header to the metasprites though. It will include the bank number of the chr data and pointers to the palettes it uses, most likely.

I have the ability to perform a lot of updates to the PPU each frame. I don't use it for much now, but I think it will be useful later on. I use the trick of putting all the data to draw on the stack and performing a bunch of pla, sta PPUDATA operations for general drawing. I also rewrite all of the palettes every frame using self-modifying code. I have a routine in ram which uses load immediate instructions, so all the bytes of the palettes are sent to the PPU in just over 200 cycles. The palettes probably won't change too often, so it might be a waste of ~10% of vblank, but I figure it is better for the time taken to be consistent, that way I don't miss a combination like Kirby transforming, changing his palettes, another character with a power star, and the stage reconfiguring all at the same time causing me to miss the end of vblank.

Here's a ROM that people can try. Warning, there's not really any gameplay implemented. You'll see the layout of the menu screen, but it's not functional yet. Press start on the controller to play as Peach on Final Destination. Ignore the fact that Peach is offset from her correct position. That's because the automatic metasprite generation doesn't yet know the center point of the player sprite. I'm working on a way to define that easily for each frame. The damage and stock indicators simply increment every frame for now. If you fall off, press select to reset.

The shadow on Final Destination is on the background layer. I have some bytes in RAM reserved for the shadow data, and I perform bitwise or operations on them to place shadows. I only needed 12 tiles for all the combinations of possible shadows.

I think that self-modifying code is a little overkill for palettes, but the fact that you used it shows that you really want to do this as fast as possible, so here are a couple of optimization tips that will make palette updates even faster:

1- The NES doesn't have 32 active colors, only 25. Unless you want to use the trick where you point the VRAM to $3F04, $3F08 and $3F0C when rendering is disabled to show those colors (something I personally can't think of many uses for in an actual game), you can cut the update time down by 14 cycles if you simply don't load those 7 bytes that don't mean anything. Even if you do want to use that trick, you can still get rid of 4 load operations, saving you 8 cycles.

2- Start updating from $3F01 instead of $3F00. Writing color 0 to $3F00 is redundant, since it has a mirror at $3F10, that you will be writing to later. This means you can save 4 more cycles by not writing a byte that will be overwritten later anyway.


That's 186 cycles, which would reduce a bit the impact of doing palette updates every vblank.

Using self-modifying code is definitely overkill, but I might as well do it since it's easy enough. Thanks for the tips -- that's exactly what I do. I start at $3F01, and only perform 3 loads per palette. I said just over 200 cycles because I was counting the cost of the jsr to the code, a bit PPUSTATUS just to be sure the latch is in the right state, and the rts instruction.

Just noticed this thread. Can't wait to watch the progress on this game. Exciting concept to see being taken on for the NES.