Progress Thread - Super Tilt Bro.

Here is my entry: Super Tilt Bro.

This is a demake of the Super Smash Bros. series aiming to offer the accessible, yet rewarding to master, "versus platformer" gameplay. All this, adapted to the little NES gamepad.



Implemented features:

• One fighter available
• Core gameplay elements (collisions, hitboxes, hitstun, damages, ...)
• Full game flow (title, menus, game, gameover)
• Basic sound engine, playing basic music and sound effect
• Some eye candy, notably the screen shaking on strike
• Complete moveset for the available fighter
• Possibility to shield against attacks (using d-pad down)
• Two players mode (No single player)
• Animation engine able to flip character while keeping the weapon in the good hand

The project began in April this year as a way for me to learn 6502 assembly and NES' internals. One thing leading to another, it became one of my longest lived pet projects. As luck would have it, exactly now, when the game begins to be really enjoyable, it is time for the NESDev Compo

The Super Tilt Bro. project itself is free as in "do WTF you want with it" and forkable on github. As I am not a good artist, I reused some assets (and learned a little also):

• The tree comes from Matt Hackett of Lost Decade Games and is CC-BY
• The fighter sprite is derived from human sprites in Surt's twin dragons which is CC-BY/GPL
• The fighter character is Sinbad, the Ogre3D's mascot, by Zi Ye and is CC-BY-SA
• The music is from Ozzed and is CC-BY-SA (original track is far better than what's in the game, go check him)

I'll attach the ROM to this thread. Now and after the compo, the latest ROM version is available on the Super Tilt Bro. page on itch.io.

I progressed more than expected and already done more than my goal for the compo.

What's new in ALPHA-5:

• Implement the missing moves
• Fix the bug causing characters to get stuck between the stage and the bottom blast line.
• Fix the crash caused by partially entered Konami code
• Flip animations on the fly instead of storing it in double

I'd like to discuss the animation flipping. It seems trivial at first, just set the sprite attribute to flip horizontally and, maybe, move a little the sprites themselves. While not a lot more hard, it was interesting to realize that the main character is actually a 3D model made of voxels!

The character is indeed an orc holding a big scimitar in its left hand. Simply mirroring horizontally a frame would result in making him hold the scimitar in the right hand. So depth is quite important here, when the orc is watching left, the scimitar must be foreground and when he is watching right, the scimitar must be background. This distinction is not limited to foreground/background, but technically there is one layer by sprite drawn on top of another. So, we can consider each sprite drawn on top of another a layers of voxel, as illustrated here:



All this to make a stupid point: our favourite PPU is a 3D voxel engine!

Anyway, it may be actually useful to simulate 3D by taking inspiration on techniques like this one.

I appreciate the detail to differences in horizontal flipping. It's more detail than Midway ever had with Kano's sprites.

I really appreciate game developers who take their time for attention to details such as flipped characters, especially on restrictive systems with limited resources. In this case it's brilliant, as this gets three things done in a row:
1. Overlapping sprites to increase a character's colour count;
2. Memory saving, as the flipped character is built using the same exact tiles, and also that both directions share the same tile arrangement data; and
3. Character holding the weapon with his correct hand in both directions.

Most commercial developers won't even care about this(until the 3-D era, when this sorta becomes irrelevant), with some exceptions(such as Enix/Chunsoft with the DQ games, AFAIK at least the party characters' sprites are different facing different directions, and Sega with the original Phantasy Star, but this is more due to the limitation of the system, as the SMS doesn't have sprite flipping capability, you either need to store sprites facing both directions anyway, or have to do this in software, and curiously because it could flip background tiles in hardware, NPCs drawn on the bg plane look VERY symmetric). One particular offender is Street Fighter II, in which they tried a lot in making the characters as symmetric as they could(mainly on the text on the costumes), but still, apart from characters changing between left- and right-handed frequently, there are many aspects that don't look right, such as the US flag on Guile's shoulder, the scar on Sagat's body and his eyepatch(!).

Unfortunately, overlapping sprites may become less practical when there are more stuff on screen, like for example, if it ever happens that this game would one day supports 4 simultaneous players (yeah I am dreaming)! In that case, not only will flickering occur more often, but you'll run out of sub-palettes for use with the weapon.

Thank you.

This is particulary important for this character because the scimitar is not a litle detail that may be noticed by an attentive player. It's almost of the size of the character

Gilbert, I am impressed. You are just so right with your list of advantages! And also the history of flipped chars in video games. Do you have a particular interest on the topic?

And yeah, 4 players was never envisioned, so each character can use two palettes and align 4 sprites on a scanline (I hate flickering). Also, the screen-freeze when a hit connects can be disturbing for a player not in the action. So 4 players support would be somewhat of a challenge. More I think of it, more it seems cool, getting this feel of party game of SuperSmashBros. I'll definitely put it on my wet-dream-todo-list with "adding a second character."

A little more progress on this. I think it is almost ready to be submitted.



Here's what's new:

• Added a shield to punish obvious moves
• Possibility to control jump's height
• Possibility to fast-fall (accelerating falling speed)
• Respawn on a cute little platform instead of being immediately thrown back to battle
• Meta sprites going over bottom screen no more appear on top (fixed after recording of the video)

Most of it is not big code, but have an incredible impact on gameplay. Even knowing it, it is surprising how all (almost invisible) little things are important in the original game design. Example: while sharing major properties with Super Smash Bros shield, my shield is trash. It misses a little stun of some frames when removed. It makes it completely overpowered (in the good hands) because a player that uses the shield for nothing is not punishable while hyper safe. Without that little stun, a player under shield can just wait for the other to come strike him, then punish that.

It is frightening. I saw this game design weakness, but how many do I missed?

Finished!

Real life is hard, so there is not a lot differences between the last preview and the compo entry:

• New font: someone said somewhere that one pixel fonts where bad ... And the original font was ugly anyway
• Fixed a bug: we were able to use grounded attacks at the begining of a double jump
• Changed the version info on title screen: the official name of this version is "nesdev2016"

The ROM is attached to the top post. I hope you enjoy

I added a simple AI as a post-entry enhancement.

I think it missed a lot for the entry, let me know if you (dis)like it. And overall I'd be glad to know what you thought about the entry

Edit: removed the attchment, it was not the intended build. Se below for the good one.

That added a lot!

I think a few more platforms or something would really help -- I want more tactical options. Right now it seems the easiest thing to do is stand there and mash the attack button. (maybe there are some good tactics, but they weren't intuitive to me)

I realized I never commented on this entry before - I really thought I had. It seemed like a really fun idea that I'd really like to see expand. The engine itself felt pretty nice.

I appreciate the addition of single player mode; I never managed to find someone else to play this with me during judging. (Though I'll admit it would have been fun)

Some feedback: (This might be obvious, but I'll say it anyway)
- a few more characters, or even the same ones with different palettes would have helped. Getting into the gameplay felt really abrupt, and it felt weird to not be able to customize much.
- Likewise, more than one arena would be nice. (Even if it was the same level disguised with different graphics - imagine fighting it out on top of a skyscraper in a city or something)
- Platforms in the level would be nice (like gauauu suggested) - especially if you could get them to move or something. I think making the level more dynamic would be a pretty huge win.

It might sound odd, but I think it would have felt more polished if there had been character/level selection screens, too. (Even if there weren't many options) Getting into the game play felt abrupt to me, and that might be why.

I'm not sure if you intend to keep building this game, but I think it has a lot of potential if you do.

Thank you both for the feedback.

As for the platforms. At the beginning I thought this flat one would suffice as it is "Final Destination like", but now that it works it is clear that more platforms/hazards must be an option as not everybody (almost nobody) is ultra-competitive. I will certainly add different levels in a future version. As a bonus we can use it to have a dedicated stage selection screen which will help with the abrupt start ... Even if I tend to prefer start rapidly the real game instead of multiplying menus.

Personally, I find it lame to add character selection to select between one character (with maybe palette swap.) It could do it if it is clear that it is satiric of the huge number of characters in Super Smash Bros and especially other fan games (fan games tend to have a huge amount of characters.) Maybe by having a selection screen saturated of variations of the same character, effectively colorswaping in game. For now, I think that a level selection screen would be sufficient to feel more complete (and it is enough work for the foreseeable future), but I keep that in mind to be refined (thank you.)

Clearly nothing is obvious when we have the hands in code and know the game for too long. Thanks again



Of course I will! I learned about the nesdev compo after beginning the project and I still enjoy developing it. It can be found on itch.io where I will continue to update it until I am very happy with it and I maintain release notes on smashboards. I am not sure if it is worth opening a new topic on nesdev to keep you updated, possibly with more technical details than on smashboards. Is it a good idea?

Story of my life.


The changes sound fun - as for the forum thing, I think it's up to you. I haven't really participated in one of these before, so I don't know how long this forum stays active - not like you have to decide right now at any rate. Maybe you'll get a nice long period to work on it and come out with a bunch of new features, and that's the time to move to a new post.

Oops, I did not sent the good build last time. Sorry for that.

In this build:

• We can select between CPU or Human for the player 2
• The version shown in the title screen is "NESDEV2016 AI"

I was just testing the latest build of Action 53 v3, and the visual glitchiness is kind bad.

Entering the battle options screen will randomly corrupt tiles with a high probability (vblank overflow).
Every hit will blink to the other uninitialized nametable, which can be quite ugly depending what the other games might of put there. Make sure that your scroll values also correctly sets the nametable selection bits in PPU_CTRL ($2000), or if you want solid blue blinking just disable background instead via PPU_MASK ($2001).

Hey thanks for the pointers, I'll try to find some time to fix that.

The blue blinking is not wanted and actually not happen standalone. I was sure that I initialised my two nametables before starting the main game mode. I'll double check that. Do action53 support mirroring or do I have to initialize the four nametables ?

Action 53 supports the same mirroring options as MMC1: horizontal, vertical, or 1-screen mirroring.

I notice there is an (E) in the filename. Is this game intended for PAL only? (Which would explain a vblank overflow in NTSC.)

It's intended to deliver the best experience on PAL (music and gamespeed) but should run on NTSC. Bugs on hardware have two main causes: I am new to NES dev and I have no flashable card to test.

So, on the first point. As I understand it a vblank overflow is when I continue to try to write on PPU's nametable after the end of the v-blank. I am right? It would make sense since the config screen initialization subroutine writes a lot of buffers to be processed by the next nmi. So, to force process it before re-enabling the PPU may be an efficient fix. I'll test it when I will be back home (on monday.)

About my hardware issue, if someone near Paris (France) has a powerpack, everdrive, home-made flashable cart, ... I can offer pizzas, retrogaming and 6502 fun for a day of tests. Contact me

When you have both the background and objects turned off in PPU_MASK ($2001), that vblank availability is extended until rendering is re-enabled.

So the algorithm would be something like:

But then you need to re-enable rendering always at the same time, otherwise the picture will jump. If you're doing this just as a safety measure, it's not so bad to have occasional jumps in the few cases where you extrapolate the vblank time, but if you consistently need more time, you should look into timing the moment you re-enable rendering or the screen-shaking will be unbearable.

Another thing to consider when enabling rendering late is that the scroll can't be set by regular $2000/5/5 writes, because those don't affect the vertical scroll once rendering has begun. In this case, you need a $2006/5/5/6 sequence to properly set the scroll.

The vblank overflow should be fixed. Every time the game changes screen, drawing and NMIs are disabled, an appropriate "screen init" subroutine is called then the drawing is re-enabled (see change_global_game_state subroutine.) So the fix was to process buffers in the "screen init" of the configuration screen instead of relying on the next NMI to do it. Thank you all for the help on this, I definitely learned a thing or two ... Actually four things!

As for the uninitialized nametable used when hitting, this is the behaviour with vertical mirroring. The game expects horizontal mirroring. So with vertical mirroring it initialize the bad nametable and scrolls fully on it instead of using the mirror of nametable 1 when setting scroll_x to 255. Is mirroring an option for the game in a53 or should Super Tilt Bro do something special to activate horizontal mirroring?

Bonus fix on this version: in the configuration screen, the "player 2" option changed when changing "stocks" option from "one" to "five". Saw that re-reading the code while investigating vblank overflow.

Mirroring is an option, but games with a 128 kbit PRG ROM are currently treated specially in the build process (autosubmulti.py), and I have to specify their mirroring in the config file. I'll look at what's causing the wrong mirroring to be used.

EDIT: autosubmulti.py was to blame