Current Public Version: 3.02
Current Developer Version: 15733

3.5 Blogpost #6: Ledge Invincibility


Hello everyone, sorry for the delay!


The Project M Dev Team has been spending a great deal of time and effort this time around touching up individual characters, and there is certainly a lot to get excited about there. Of course, there has also been a lot of work on improving the universal gameplay mechanics and engine. A number of changes have been implemented to make interactions more fluid and dynamic. This blogpost and the following one will go into detail about these mechanic changes.


As you may know, we’ve put out a few blogposts last month regarding character recovery and tether ledge mechanics. For 3.5, we’ve taken a good look at many ledge mechanics to properly balance offstage gameplay. One such mechanic is ledge invincibility. In previous Smash titles and versions of Project M, the ledge has been a controversial position, conceptually being a poor place to be, yet in some cases allowing stalling by abusing the invincibility granted upon grabbing the ledge.


Fox stays entirely invincible from attack while simultaneously protecting the ledge from would-be grabbers with hitboxes of his own.


We’ve implemented a solution meant to curb abuse of ledge invincibility for stalling purposes. After a character regrabs the ledge five times without touching the ground, that character no longer receives invulnerability for grabbing the ledge again (except for a few frames during the initial ledge snap) until he or she either lands on the stage or gets hit.



After grabbing the ledge 5 times, Fox and Ganondorf become quite vulnerable to attack.



Even with a Special that grants invincibility, Sheik leaves herself open to punishment if she fails to go onstage quickly.


Five ledge grabs is a relatively high number that should guarantee that this will only affect players looking to stall the game, so very few players will ever see this limit come into play.


We’ve done a lot of internal testing and asked high level Melee and Project M players alike what they think. Even in talking with top level players who have put a lot of time into practicing ledge tactics for the specific abuse of this mechanic, we still received positive feedback. We hope that this change will allow all of the common existing ledge interactions to remain unchanged while preventing the exploitation of the ledge purely for stalling purposes.


With this new ledge counter in place we hope to see tournament matches filled with even more action and interaction, reinforcing engaging gameplay that keeps both players and spectators on the edge of their seats... rather than on the edge of the stage.


The next blogpost will discuss a few other mechanics changes we have been cooking up for you.

Until next time,
-The PM Dev Team

3.5 Blogpost #5: Debug Mode Pt. 2


Greetings everyone,

Yesterday we announced our Debug Mode and went into detail about its main features we expect the majority of users to want to take advantage of. Today we'd like to go over some of its additional features that we're sure everyone will love. Like yesterday, we'll be describing any additional input commands assuming a GameCube Controller is being used.


With Debug Mode active, on top of all of the features mentioned yesterday, press Y + Dpad Right to enable ledgegrab box view, similar to Melee's. This box is used by the game to determine whether or not your character is able to grab the ledge at any given time.



Captain Falcon, the true hero of our story, Falcon Dives to the ledge.

This feature was present in Melee's Debug Mode as well and we've been using it to more easily fine-tune ledgegrab boxes, as a small addition to the recovery changes we spoke about last week. This should help you practice your edge sweetspots more easily!



Additionally, pressing Y + DPad Left enables a display of the game's Stage Collision Detection (SCD) system. How does the game handle movement and collision detection? Well, at its most fundamental level the Smash engine treats a character like a single point in space. By reading controller inputs and applying corresponding force vectors to the point it can be made to move around in ways that look like running and jumping once a character model and animations are rigged up on top of it. This all-important point is referred to as TopN, and it’s visualized below the character with a white circle graphic.


Beyond movement, the game also needs to make the character collide with the stage or other opponents in a realistic manner. In order to do this economically, the Smash engine just looks at certain key bones (usually the neck, hip, shoulders, and knees) to create a simple but dynamic, diamond-shaped collision box. In any given frame the height of the diamond’s top point corresponds to the height of the highest SCD bone, usually the neck, and the outer edges are determined by the current outermost SCD bones, usually the shoulders. While on the ground or during the first 10 frames of air time TopN is always the diamond’s bottom boundary, but after 10 frames of air time the Smash engine dynamically tracks the lowest SCD bone, which is usually one of the knees. The current top, bottom, and side points of the SCD diamond are shown in Debug mode with yellow circle graphics.


This SCD diamond is important in many ways. While falling, the game tells a character to land when the bottom SCD point intersects with the plane of the stage. During recovery the diamond’s side point often rides up against the wall or lip of the stage. If you slowly walk into another character the SCD system starts pushing the opponent away when your horizontal SCD points touch.



Left: Link pushes a lazy Dedede to show off his collisions. Right: Link does a Neutral-Air to show his landing detection.

Unfortunately this display has a minor limitation: Brawl has a limit on the number of Graphical Effects it can render at the same time, and as you can imagine having 5 extra GFX rendered every frame eats into that quite a bit. With multiple characters on the screen, some GFX may occasionally fail to display or may flicker briefly while using this feature. We hope you understand and still make use of this mode for research purposes.


Of course, we wanted to give the competitive community as many tools as possible to develop their skills. A new feature to Debug Mode not present in Melee’s Debug Mode that we're very pleased to announce is Hitstun Display.



Left: Kirby Up-Tilts a low-percentage Wolf, causing non-tumble hitstun. Right: Kirby does the same to a higher percentage Wolf, causing him to suffer tumble hitstun.

When your character is hit, he or she suffers hitstun and is unable to act, allowing things like combos and tech-chases. With Debug Mode active, a character suffering from hitstun will have a colored overlay. For non-tumble hitstun (hitstun in which the character isn't knocked over and forced into a knockdown, often occurs at low percents), the character receives a yellow overlay. For tumble hitstun, the character receives an orange overlay.


Additionally, on the last frame of hitstun the overlay opacity drops by 50%. This makes it easier to measure combo frame advantage windows using Frame Advance.



Left: Luigi uses his Forward-Tilt against a low percentage Meta Knight. Right: Meta Knight gets some payback with his Down-Tilt. The last frame of hitstun in each is paused and highlighted.

We're excited to not only use this tool to better develop the game and balance the cast, but to see it empower the community to advance the metagame faster than ever before.

If you would like a demonstration of this mode please tune into Low Tier City 2 this weekend, which is being held in Dallas/Fort Worth, Texas. It will be streamed by our friends from VGBootCamp on Twitch.tv. Project M Dev Team Members Sethlon and Strong Bad will be doing a demonstration of our new mode immediately preceding the Top 8/Finals on Sunday.

See you then!
-The Project M Dev Team

3.5 Blogpost #4: Debug Mode Pt. 1



Good news, everyone!


We've got something exciting for you today! Veterans to the Smash Bros series may remember that Super Smash Bros. Melee has a debug mode accessible via Action Replay. This debug mode has a lot of features, from frame advance, to hitbox/hurtbox display, to invincibility and vulnerability display, and more.



Left: Standard Melee. Right: Melee with Debug Mode and Hitbox/Hurtbox Display enabled.


For years we have sought to implement something similar for Project M, not only for our own developmental uses but for the community's use. Today, it brings us great pleasure to announce that due to the efforts of our lead coder, Magus, we have succeeded in bringing a new Debug Mode to Project M 3.5! To be clear, this is not an official development tool mistakenly left on this disc and later uncovered as Melee's Debug feature was. Rather, this new Debug Mode was constructed by Magus from the ground up after countless hours of hard work.


Here we will be going into detail about the features of this debug mode. This mode is very feature-rich; while it may not have EVERY feature that its predecessor does, it introduces a few new touches that Melee's didn't that we're sure you're going to love. Please bear with us, as this blogpost may be quite lengthy and technical. If you're new to the series' inner workings and don't understand everything immediately, don't worry. All will be clear when the mode gets released.


Please note that the following commands assume a GameCube Controller is being used. We hope to put out instructional materials for all supported controller setups in due time, but for now we'll be sticking with the trusty classic from the 2000s. All images and animated gifs are captured on WarioWare to ensure the lowest filesize. With the formalities out of the way, let's get right into it!



This new Debug Mode has an unusual input combination, R + L + Dpad Down, to avoid accidental toggling during regular gameplay. Of course, Debug Mode comes stocked with a fully functional Frame Advance mode in order to gather frame data, test punishes, and find new combos to make use of. Press Start with Debug Mode activated to freeze gameplay and then advance frames with your Z button (normal start function is performed with X + Dpad Up). Input buttons by holding them before pressing Z. That's all well and useful, but the real magic happens when you press R + Dpad Right.


Immediately available to you after inputting R + Dpad Right are the following features:
Hitboxes displayed in red (almost all hitboxes display properly). Pressing R+ Dpad Right a second time will enable a representation of hitbox interpolation. Interpolation is a term used to describe the phenomenon that hitboxes undergo when active for more than 1 frame; the hitboxes are present where they are the current frame, the previous frame, and everywhere in-between.



Sheik Forward-Tilts under different settings. Hitbox Display Off | On | Interpolation Enabled


Grab collisions displayed in purple and inert collisions (usually ones that trigger something by proximity) displayed in grey.


Snake's Up-Smash Mortar utilizes an inert collision to trigger the explosion on contact in addition to activating when it hits the ground. Meanwhile, Snake shows his grab-boxes.


Respawn-type invincibility represented with a green overlay on the character. This type of invincibility is hittable, but unaffected. Regular type invincibility (intangibility, granted by actions such as air dodge, spotdodge, and rolls) represented with a blue overlay on the character. This type of invincibility is unhittable.


Marth Forward Smashes a Mario who undergoes both types of invincibility.


Armor display. Super armor displays in a light blue, Knockback-based armor displays in cyan that varies in intensity based on its strength, Subtractive KB armor (such as Yoshi's Double Jump) displays in violet, and Damage-based KB armor displays in red.


Ike's Fully Charged Eruption has true Super Armor, while his regular Eruption just has Knockback-threshold armor. Yoshi demonstrates his Subtractive Armor.



Bowser shows off his varying Armor levels while in Debug Mode: 80, 140, and 200 KB.

That's all we've got for you today. We know you're eager to get your hands on this incredible new tool but please be patient for now. We are deep in 3.5 development, and have been developing Debug Mode within the 3.5 code set. Taking time to test, polish, and publicly support Debug Mode for a 3.02 release update would unfortunately take too much precious time away from 3.5 development. However, please stay tuned tomorrow for our second blogost on Debug Mode... we've got a few more features to reveal to you!

See you tomorrow,
-The Project M Dev Team