Current Public Version: 3.02
Current Developer Version: 15324

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. We're going to take a break from blogposts until afterward, so we'll see you next week here on our news section.

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

3.5 Design Blogpost #3: Lucas Recovery Overview


Hello everyone. Yesterday we went over what we predict the tether mechanics will look like for the next version. We wanted to give you a look at an example of a recovery that we're re-balancing for the next version in our first blogpost, but without the information on tether mechanics, we weren't able to give you the proper context. Now that you've got that, we can properly give you an in-depth evaluation of a recovery. Today’s subject matter is the beloved PK user from the Mother series: Lucas.




In the early days of Project M development there was a strong push to make Lucas feel unique compared to Ness. In particular, some of us thought that we could differentiate Lucas's offstage game by emphasizing his usage of Z-tether over his Up-Special, PK Thunder 2. Since then, Magnet -> Magnet -> Double Jump -> Air Dodge -> Tether has become his go-to recovery path. Most of the steps are flexible in timing and are quick enough to have relatively little commitment. He's protected by either his Magnet, Air Dodge, or rising aerials, and his surprisingly long-ranged tether quickly reels him in to a perfect sweetspot ledge grab. Additionally, canceling his Tether Hang allows Lucas to threaten the opponent with another quick Magnet, either stage spiking the edgeguarder or otherwise putting them into a disadvantageous position. Variations of this recovery path are so effective that Lucas can largely ignore PK Thunder 2.



As stated in the previous recovery blogpost, a major goal for us is to have characters creatively using all of their options while offstage. The new tether restrictions in place helped to tone down the Z-air recovery slightly, but it still didn't necessitate enough variation. We elected to match the Z-tether range closer to the physical range suggested by his turn grab (50 units -> 35 units). In addition to being more visually intuitive, it creates more scenarios where Lucas needs to utilize Up-Special to have enough range to recover. Z-tether is still an exceptionally powerful tool for both recovering and edgeguarding, but the combination of global tether adjustments and the shorter range of his tether means that it is no longer his best choice as consistently.



We've also adjusted Magnet's stalling capabilities. Most other stalls in the game, such as Marth Side-Special or Mario's Side-Special, lose the majority of their stalling efficacy immediately after the first aerial use. Conversely, Lucas could fire off quick blip after blip of Magnet with little reduction in stalling power. In this way he could wait out more edgeguarding attempts than many other characters, bypassing an inherent disadvantage of fast falling characters. We've now adjusted Magnet such that it no longer appreciably stalls Lucas’s fall speed after the first usage.



Finally, we've made some minor edits to PK Thunder 2 itself. We noticed that the hitboxes weren't working in game quite as predicted by our (admittedly, relatively rudimentary) development software, resulting in less protective disjoint than intended. We've now beefed these up slightly to give him a reasonable but not impenetrable disjoint while traveling. Additionally, we've adjusted the starting momentum and friction values to give it a much smoother, more natural feel overall. Lastly, we've slightly reduced the horizontal air drift control Lucas has after PK Thunder 2 ends -- many other moves which grant drift control so quickly after movement has ended also feature minor restrictions to special fall drift control.



Our playtesting so far has demonstrated that these changes create a much more thoughtful, dynamic, and natural looking off-stage game for Lucas. He retains a hefty number of options to select from, but each option has been trimmed down just enough to put pressure on him to choose wisely. We feel that his recovery is now fitting for such an on-stage offensive powerhouse, and meets our stated design goals. Bear in mind that Lucas received more recovery changes than most cast members, and that some characters only required one or two simple tweaks.

So now that you've learned about our recovery criteria and have seen an example of our process, we hope you can now imagine what types of changes other members of the cast may receive. We have much left to share with you about the next version, but aren't quite ready to do so yet, so please be patient as we work on future blogposts. We hope to have two new ones out for you next week.

Until then,
-The PM Dev Team