Melee Controller Ruleset Proposal 2024

By The Controller Ruleset Team

Executive Summary

General Info

  • This document proposes an addition to Super Smash Bros. Melee tournaments’ controller rules, outlining a set of limitations on controller-side firmware
  • This proposal will only take effect if Tournament Organizers decide to use and enforce it
  • The proposed date for this ruleset to come into effect is January 2025
  • If the proposal receives widespread approval, we will seek to facilitate enforcement via a program which can read SLP files and detect non-compliant controllers by their inputs
  • Non-Nintendo-licensed controllers must make the portion of their source code which controls inputs and outputs related to Melee available for public viewing

Controller Specific Requirements

  • Third-party GCC-like controllers are permitted with the following restrictions:
  • Banning Goomwave u-tilt rounding and other techniques made easier by increasing the size of ranges that are difficult to consistently hit quickly on OEM GameCube controllers
  • Banning Goomwave easy dash back out of crouch and other techniques made easier by increasing the timing leniency of inputs that are difficult to consistently hit quickly on OEM GameCube controllers
  • Official Phob firmware and Adewotta’s/Rienne’s Goomwave firmware rewrite (tentative, pending source code review) are permitted.

 

  • Rectangle controllers are permitted with the following restrictions:
  • Neutral SOCD (both x- and y-axis) to prevent easy, instant changes of direction
  • Limits on modifier buttons including limits on L/R changing control stick output
  • Travel time simulation equal to the input speed of very fast analog sticks
  • Control stick output fuzzing which has almost no effect on the vast majority of gameplay but prevents consistent targeting of single coordinates
  • Limits on available target coordinates/angles that are difficult to consistently hit quickly on GCC-like controllers, such as Peach’s 2-frame no-setup Parasol Dash
  • Timing lockouts to prevent rapid burst SDI and instant pivot/crouch tilts
  • All of these requirements have been tested by rectangle controller players across the skill spectrum and found to be, in the ruleset team’s opinion, reasonable to play with.
  • Compliant firmware is available for all commercially available rectangle controllers that run HayBox firmware (all except Frame1 and SuperSlab); we are in contact with both teams to facilitate the development of compliant firmware for their devices.

Changelog

2024-10-01

  • Updated c-stick clustering rule

Updated clustering rule to allow use of a 5-button thumb cluster with partial remapping: C-down must be below the other C-buttons, but A and the other C-buttons may be placed anywhere as long as that restriction is satisfied. Also added optional Smash Stick grandfather clause.

2024-09-26

  • Changed proposed start date to January 2025

 With the proposal and firmware finalized, the proposed start date has been changed again.

  • Added c-stick clustering rule

At the request of tournament organizers, we have added a rule that requires the C-stick buttons be clustered together either on their own or surrounding the A button. Most existing rectangle controllers already comply with this rule in their default layouts, but this will make some custom layouts illegal.

  • Updated banned coordinates to include y=+-0.3

Tap jumping then targeting y=0.3 while in jumpsquat enables behavior similar to the “0.2875 up short hop macro” for Ice Climbers. This results in a Popo full hop and Nana short hop.

  • Reverted from cubic to linear travel time
  • Reverted reduced travel time for <45 degree rim motions

After testing, we have concluded that cubic travel time does not have a significant impact on controller output. Considering this and its higher computational cost, we have decided to revert to linear travel time. Additionally, after testing, we have found that reducing travel time for short rim motions has an unintended side effect of also reducing travel time for longer rim motions (as they are frequently made up of multiple shorter motions), so this is being reverted as well.

  • Added non-dedicated modifier exception for angled c-stick fsmash

Clerical update to clarify that the commonly used NDM of control stick up/down + modifier + c-stick left/right for angled fsmash is permitted.

2023-12-08

  • Changed proposed start date to May 2024

As a start date of January 2024 would no longer provide enough time for players to acclimatize to the proposal’s changes, we are instead proposing that tournament organizers use the start of 2024 as a non-enforcing trial period for the ruleset, before beginning to enforce the rules at tournament starting in May 2024. This start date is proposed under the assumption that the firmware will be available in a feature-complete state early enough that players are able to acclimatize by May 2024.

  • Replaced ban on L/R changing control stick output with angle lockout on L/R
  • Replaced 23 degree universal angle limit with 27 degree limit while pressing L/R and 20 degree limit otherwise

We received extensive feedback that the ban on L/R changing control stick output, and subsequent unification of angles for wavedashes and firefoxes, was simultaneously too restrictive for directional up-Bs and too lenient for wavedashes. We originally believed that it would be possible to balance rectangle controllers with these angles being unified, but the feedback suggests that we should not do this. To resolve this, we have partially restored the L/R NDM as an angle lockout, limiting L/R presses to allowing only angles at least 27 degrees away from the cardinal. If the user is holding an angle less than 27 degrees away from the cardinal and they press L/R, their angle is immediately placed 27 degrees away (or more, if desired) from the cardinal without incurring travel time. This implementation avoids the non-deterministic travel time issue that would occur if L/R were an unrestricted NDM, without granting control to use L/R as an NDM in other situations. It also allows us to provide a buff to the maximum angle range without pressing L/R, to 20 degrees away from the cardinal. This maximum is more in line with the values that gcc players can hit with notches. Thanks to Altimor for his assistance here.

  • Permitted a combined actuator to be used to activate a single analog stick axis

This is the “guitar hero controller” exception: one oversight in the initial proposal was that since it required the control stick to be split into 4 digital buttons, it banned the use of a combined digital actuator, such as a guitar hero strum bar, from acting as the left and right control stick inputs. This is clearly not necessary to ban as long as the actuator is used for a single axis (it activates left and right, or up and down, but not e.g. left and down), and has been corrected.

  • Permitted replacing one analog trigger with a digital button without replacing the other

We are removing the ban on replacing one analog trigger (lightshield) input with a digital button and simultaneously leaving the other as an analog trigger with full control. As written in the MIOM controller addendum, if you replaced one analog trigger with a digital button, it was mandatory to also replace the other. We investigated potential abuse cases that would justify this restriction, and considered removing the restriction but requiring that digital lightshield buttons have travel time, but ultimately decided that the rule isn’t necessary to keep.

  • Replaced linear travel time with cubic travel time
  • Reduced travel time for <45 degree rim motions to 9 ms (from 12 ms)

Linear travel time was initially chosen, despite not being the best simulation of gcc stick motion, partially because we were not confident that more complex motion would be feasible to implement on the lowest-power rectangle controllers. After a travel time reimplementation and benchmarking of a variety of options, it was determined that trigonometric motion was not feasible but non-linear speed was. Travel time has been reimplemented with cubic motion, which improves simulation of gcc stick motion. Thanks to Adewotta and Rienne for their assistance here. Additionally, we received feedback that 12 ms of travel time to slight diagonal rim coordinates was unnecessarily high in some cases; for example, if a player is dashing and moves their control stick slightly down, it does not need to incur the same travel time as if they use Shine then try to hit a shallow wavedash. Control stick rim motions starting from either a cardinal or diagonal then moving to a rim coordinate less than 45 degrees away have had their travel time reduced from 12 ms to 9 ms.

  • These changes have been reverted after testing

Please see the 2024-09-26 update for more details

  • Added reverse neutral-B timing lockout
  • Added diagonal dash pivot u-tilt/d-tilt timing lockout

Some rectangle firmwares include a reverse neutral-B lockout which forces a side-B in the case where the user attempts to press B while in the non-deadzone neutral-B region. This forces rectangle players on these firmwares who wish to perform a reverse neutral-B to ‘flick’ their control stick input, release it, and press B. This lockout was initially not included in the proposal, but has been added after testing verified that using the non-deadzone neutral-B region is a significant buff for characters who want to use neutral-B while retreating. Additionally, it was brought to our attention that it is possible to perform a diagonal dash (i.e. dashing above or below the y-deadzone) to turn off tap jump/u-smash then perform a pivot u-tilt. This is possible and much faster on rectangle controllers despite the existing pivot u-tilt lockout (which attempts to force a tap jump or u-smash). To rectify this, a 5-frame lockout has been added specifically to diagonal dash pivot u-tilt/d-tilt which instead forces the control stick to a coordinate which outputs pivot f-tilt. This is in line with the gcc failure state where the player presses A too quickly, before they have rotated their stick into the u-tilt/d-tilt region from the diagonal dash region.

  • Added TO’s discretion clause for accessibility

We have received a few requests around allowing foot pedals or other accessibility aids to players. The initial proposal prohibited potentially useful aids for players with limited mobility. Rather than attempting to carve explicit exceptions to these rules, after receiving positive feedback from major Melee TOs, we have added a clause which states that exceptions can be made at the discretion of the tournament organizer.

  • Added Addendum for proposal philosophy and detailed justifications

Though the initial release included some justifications for specific requirements, it has become clear that a section on the overarching philosophy of the proposal is desired for public consumption. This has been added alongside additional details for the individual requirements where that has been deemed to be valuable.

2023-10-29

  • Initial release

The proposal as initially released can be found here.

General Info

This is a Summary

  • This is a summary of the controller ruleset, containing only key points relevant to players, and is not its full wording. In the event of ambiguity between this document and the full ruleset (found here), the full ruleset takes priority.

 

Enforcement

  • We propose that this ruleset come into effect in January 2025.
  • Players using controllers with reprogrammable firmware must declare the firmware they're using upon request of a TO or their opponent.
  • We will seek to facilitate enforcement via a program which can read SLP files and detect non-compliant controllers by their inputs.
  • Enforcement of these rules is the responsibility of TOs. The ruleset team has no power to enforce the rules or require TOs to use them. TOs have sole discretion to ban non-compliant controllers and penalize players who use them.

 

Source Code Requirement

  • Source code for core functions specific to the pipeline of inputs to GameCube communication must be available for inspection on request by any party. Non-core code, such as code used to update controller firmware, must be isolated from input-affecting code if a manufacturer wishes for it to remain closed-source.

 

Input Layout

  • Controllers which replace analog inputs with buttons are legal (controllers which replace every analog input are colloquially known as rectangle controllers).
  • Any placement of inputs on a controller is legal, with one exception: if the c-stick is split into buttons, all buttons must be on the same plane/face of the controller (which must be flat or nearly flat across the area where all c-stick buttons are located).
  • You may not use an add-on which lets you manipulate the controller with more than 2 limbs, i.e. a foot pedal or similar is prohibited unless you have no use of an arm.
  • You may not overlap independent buttons to make it difficult or impossible to activate one without another.
  • You may not attach an additional actuator to an input, such as a string to hold the c-stick down.

Accessibility Exception

  • At a Tournament Organizer’s discretion, exceptions can be made to allow potentially useful aids for players with limited mobility.

Updates

  • Changes made since this ruleset’s initial release are written in red.

 

Controller Specific Requirements

The following rules apply to controllers which use analog inputs:

Analog Stick Rules

  • Analog remapping, such as for notch calibration, is allowed. Analog remapping may change a coordinate’s angle but not its distance from the center. Angle remapping must be static and cannot change under any conditions within a match. You may only remap by defining new output positions for the 4 cardinals, the 4 diagonals, and 8 mid-octant (1 per octant) coordinates, then linearly interpolating between those points to calculate the output of any other input coordinate. There is a maximum angle change that remapping can apply, to prevent mods that make it significantly easier to hit single coordinates or small angle ranges. Separately, remapping to make 1.0 cardinal easier to hit, up to a range of 6 units on each side of a given cardinal axis, is permitted.
  • It is permitted to filter or process control stick input in certain ways, i.e. to reduce snapback and time spent in the tilt turn range via simulating PODE. This filtering must ignore all other inputs. This filtering must not "run ahead" of the stick, i.e. inferring the player's intent to dash out of crouch and outputting a successful dash without the actual stick reaching the output that would perform it.

Analog Trigger Rules

  • If both digital and analog parts of a trigger are active simultaneously, the digital and analog functions must correspond with the digital and analog outputs of one GCC trigger (can't use it for a separate output).
  • “Trigger plugs”, i.e. hardware modifications that limit the depth to which a trigger can be pressed, are allowed. Trigger plugs which directly modify the trigger’s electrical signal (instead of physically restricting the trigger) must not be able to pinpoint lightshield values lighter than Z-lightshield.
  • Analog triggers must not output coordinates read as "no shield" between coordinates read as "shield" (you cannot get multiple attempts at an L-cancel within one trigger press).
  • It is permitted to filter or process trigger analog input in certain ways, i.e. to remove noise. This filtering must ignore all other inputs. This filtering must not "run ahead" of the trigger.

The following rules apply to controllers which replace analog inputs with buttons:

Analog Stick Output General Rules

  • If you replace an analog stick with buttons, you must replace the entire stick with 4 digital or 4 analog buttons (up, down, left, right) and may not retain the analog stick. You may also combine both halves of a given axis (up + down or left + right) from a single stick into two buttons triggered by a connected single actuator, as long as the default position of the actuator is a neutral input. If this is done for one axis, you do not need to do the same for the other axis. If you replace one analog stick with buttons, you do not need to replace the other.

Analog Trigger Output General Rules

  • The previous rule prohibiting replacing one analog trigger with a button that pinpoints single-coordinate analog trigger output while retaining continuous analog output on the other shoulder trigger (i.e. having both a digital lightshield button and analog lightshield trigger at the same time) has been removed.

Analog Stick Simultaneous Opposite Cardinal Direction (SOCD) Cleaning

  • An analog stick axis replaced with buttons must resolve the pressing of both buttons at the same time (i.e. left + right or up + down) as the sum of both inputs, i.e. always neutral if the buttons are digital, and the difference between button magnitudes if the buttons are analog. Existing rectangle controller firmwares commonly use second-input priority (2IP) SOCD cleaning instead of neutral SOCD. Under 2IP, if the player is holding left and presses right, the left hold is ignored and a right press is sent to Melee. This enables easy, instant changes of direction, with no equivalent motion to that of an analog stick. Neutral SOCD slows down these changes of direction if performed imprecisely, as the player can only go directly from full left to full right if they release right and press left on the same frame. Neutral SOCD also enables some strong options, such as dashing right then pressing left and right 1 frame apart in order to pivot. The controller ruleset team considers these acceptable to allow. In many cases, 2IP and other SOCD cleaning methods enable equivalent or stronger options.

The following rules apply to controllers which replace the control stick with digital buttons: Firmware containing all of the following has been made available to a large group of testers and found to be, in the ruleset team’s opinion, reasonable to play with.

Modifiers

  • Dedicated modifier buttons are permitted if the control stick has been replaced with digital buttons.
  • Modifier inputs may not change the zone of an output coordinate (moving between neutral, cardinal deadzone, or diagonal)
  • If the C-stick has been replaced with digital buttons, these buttons may be used as modifiers for control stick inputs.
  • If digital C inputs are used as modifiers, you may have up to 2 dedicated modifiers, with up to 1 active at a time.
  • If digital C inputs are not used as modifiers, you may have up to 3 dedicated modifiers with up to 2 active at a time, or up to 6 dedicated modifiers with up to 1 active at a time.
  • If more modifiers are pressed than allowed active, 1) either excess modifiers must be ignored or all modifiers must be ignored (i.e. unmodified stick output is produced) at the firmware author’s discretion, and 2) this may cause C buttons to output D-pad output.
  • The B button may be used as a non-dedicated modifier (NDM) for control stick inputs. When used as a modifier, the B button must not decrease the radius of analog stick output (increasing the radius is permitted), nor materially change the output angle.
  • You may not change the coordinates output by digital buttons in the middle of a match.
  • Other digital inputs may not be used as modifiers for other inputs. A partial exception is allowed for L/R inputs, which must modify angle inputs to only allow angles at least 27 degrees away from the cardinal if the control stick is not already undergoing travel time. As an angle lockout, this allows for differentiation between wavedash and directional up-B angles without granting user control to use L/R as an NDM in other situations.

Travel Time Simulation

  • Digital buttons must apply travel time simulation to control stick inputs. This nerf is meant to restore parity of input speed between digital buttons and analog control sticks. The decreased actuation speed of a button relative to an analog stick effectively lowers the user’s reaction time; if the user is attempting to be precise, the difference can be multiple frames in duration. The specific timings chosen were picked to be similar to the fastest GCC-like controllers.
  • When moving to a cardinal or diagonal point (defined as an angle between 41.5 and 48.5 degrees) on the rim/edge of the Melee unit circle, travel time is a linear 6 ms. In any other situation (moving to an interior point, moving to a point on the rim that isn’t a cardinal or diagonal, or moving back to center), travel time is a linear 12 ms.
  • To avoid being polled in the “uncrouch” zone while attempting to dash (back) out of crouch, specific cardinal and diagonal coordinates outside the Melee unit circle are permitted to be targeted. If these coordinates are used, travel time to these coordinates is changed to keep travel speed roughly the same.

Control Stick Output Fuzzing

  • Digital buttons must apply variance to control stick outputs. For context, the average OEM GameCube controller can output around 30,000 unique coordinates. This level of precision means that it is not viable for a human thumb to repeatedly target a single coordinate, so this nerf is meant to prevent digital buttons from doing so either. Testing has shown that this nerf, when applied in conjunction with carefully chosen target coordinates, has almost no effect on the vast majority of gameplay while directly nerfing digital-only techniques such as Pikachu’s double Up-B edgecancels. Its inclusion also opens up much of Melee’s coordinate space that was previously banned due to enabling single-coordinate techniques, as those techniques are not consistent with fuzzing.
  • When the user targets a coordinate in the x- or y-deadzone that is not a 1.0 cardinal, the resulting output coordinate sent to Melee must be:
  • The target coordinate, at 50% probability
  • 1 unit further from center, at 25% probability
  • 1 unit closer to center, at 25% probability
  • For example, y-deadzone (x-axis) variance looks like this:

  • When the user targets any non-cardinal coordinate, whether on the rim or internal, the resulting output coordinate sent to Melee must be:
  • The target coordinate, at 25% probability
  • 1 unit away from the target coordinate in either the x- or y-axis, 4 options each at 12.5% probability
  • 1 unit away from the target coordinate in both the x- and y-axes, 4 options each at 6.25% probability
  • Wherever it is applied, this variance looks like this:

  • Fuzzing is reapplied only when the user changes their input (i.e. the output coordinate stays the same as long as the user holds their input). If the output coordinate does not match the target coordinate, it must not move to the target coordinate without user input.

Limits on Target Coordinates

  • Digital buttons must not target certain control stick coordinates. If they target a coordinate adjacent to such coordinates, it is permitted to output these coordinates after the effect of output fuzzing. This nerf is meant to account for the fact that individual coordinates are considered too precise to reliably hit on a GCC-like controller. In the below cases where the banned range is relatively large, users will have an alternative way to activate the same game state as the banned range (for example, using Axe/Sung shield drops instead of shield dropping straight down). The remaining cases are select single-coordinate Ice Climber desyncs; if not banned, these coordinates would result in “option selects” where the user targets the coordinate or an adjacent one, and the resulting game state is either the intended desync or a beneficial alternative state (such as either Nana performing a neutral-B while Popo is actionable or both Ice Climbers performing a synchronized neutral-B). As L and R are not permitted to be non-dedicated modifiers, wavedash and directional up-B (such as Firefox) angles have separate limits. As a counteracting buff, the wavedash angle range open to rectangle controllers is intentionally more permissive than some currently available firmware.
  • The following coordinate ranges cannot be targeted:
  • Angles closer than 20 degrees away from the nearest axis (though a target coordinate of 20 degrees or more away from the axis can result in an output coordinate less than 20 degrees away after fuzzing)
  • Angles closer than 27 degrees away from the nearest axis while the user is holding L or R (to limit wavedash and airdodge coordinates)
  • The 2 closest horizontal coordinates to the x-deadzone (which enables Kirby, Jigglypuff, and Yoshi to double jump backwards without turning around)
  • The 2 closest vertical coordinates to the y-deadzone (which enables the “0.2875 up short hop macro”, “slight-angled” f-tilts and f-smashes, and Solo Nana Short Hop with Popo Full Hop.
  • 1-frame turnaround u-tilt and d-tilt
  • The airdodge range that enables Peach’s Parasol Dash (diagonal up airdodge to ledgedash) in a 2-frame window without delaying the preceding ledge grab
  • Shield drop straight down
  • No-buffer aerial up-b without activating double jump
  • Solo Nana Neutral-B while Popo remains actionable
  • Popo and Nana Simultaneous Uair/Fair or Uair/Bair
  • Coordinates which provide larger magnitude outputs than can reliably be targeted on a GCC-like controller’s rim
  • Some other coordinate ranges will become undesirable as they may cross an action state range after fuzzing; while not banned, it is recommended that these coordinate ranges be avoided; a list of common ranges to avoid will be made available on request.
  • The following action must immediately move the target coordinate to the tilt side-B zone:
  • Pressing B while holding the control stick in a region that activates neutral-B outside the x-deadzone. This forces rectangle players who wish to perform a reverse neutral-B to ‘flick’ their control stick input, release it, and press B.

Timing Lockouts

  • When performing certain compound actions with digital buttons at high speeds, the output sent to Melee must be adjusted (either by increased travel time or moving the output coordinate to an “overshoot” of the target coordinate, as described). This nerf is intended to apply limits on target coordinates that cannot be prohibited through an angle range ban (because the target coordinate needs to be accessible for other reasons). The specific timings chosen were picked to be similar to the fastest GCC-like controllers.
  • The following actions must ignore repeated inputs executed too quickly. These lockouts are mandated because it is impossible for a GCC-like controller to reliably perform a rapid “burst” of inputs at the speed that a user with a button can. They specifically target optimal single-direction and quarter-circle SDI.
  • Rapidly tapping the same direction and returning to neutral faster than once every 5.5 frames triggers 1 SDI and ignores subsequent attempts.
  • Rapidly tapping the same diagonal and returning to an adjacent cardinal faster than once every 5.5 frames triggers 1 SDI and ignores subsequent attempts.
  • Tapping a cardinal then rapidly alternating between the two diagonals adjacent to that cardinal faster than once every 5.5 frames triggers 1 cardinal SDI, then 1 diagonal SDI, and ignores subsequent attempts.
  • The following actions must incur an immediate move of the target coordinate to the control stick rim. These lockouts are mandated because it is impossible for a GCC-like controller to reliably, consistently move the control stick at very high speed before stopping to perform a tilt attack without buffering.
  • Moving from crouch to the u-tilt range in less than 3.0 frames (will result in a u-smash if the user attempts to attack, and a tap jump if they do not).
  • Performing a pivot then moving above the y-deadzone in less than 8.0 frames, for example to pivot u-tilt or pivot up-angled f-tilt (will result in a u-smash if the user attempts to attack, and a tap jump if they do not).
  • Performing a pivot then moving below the y-deadzone in less than 8.0 frames, for example to pivot d-tilt or pivot down-angled f-tilt (depending on angle chosen, will result in a d-smash, down-angled f-smash, or down-angled f-tilt if the user attempts to attack, and a crouch, walk, or dash if they do not, depending on the specific angle chosen). The slightly different behavior here, allowing for down-angled f-smash and f-tilt, is specifically because this lockout can be unintentionally triggered when the user tries to quickly dash forward and wavedash back. To avoid unintended negative impacts, this lockout preserves the angle that the user inputs and extends it to the control stick rim, whether the extended coordinate would crouch or not (instead of always forcing a crouch). Note that the user can d-tilt before the lockout ends if they hold down long enough that the game-side smash input buffer expires, so this lockout is inactive once the user has held their control stick in d-tilt range for at least 4 frames.
  • Performing a dash above or below the y-deadzone (to turn off tap jump and u-smash, or turn off d-smash, respectively), then performing a pivot u-tilt/d-tilt in less than 5.0 frames (will result in an f-tilt if the user attempts to attack). This diagonal dash pivot tilt is possible and much faster on rectangle controllers despite the existing pivot u-tilt lockout (which attempts to force a tap jump or u-smash). This lockout forcing an f-tilt is in line with the gcc failure state where the player presses A too quickly, before they have rotated their stick into the u-tilt/d-tilt region from the diagonal dash region.

The following rules apply to controllers which replace the c-stick with digital buttons:

Modifiers

  • A c-stick replaced with digital buttons may be accompanied by dedicated modifier buttons, or an NDM consisting of 2 buttons + 1 dedicated modifier. Modifier buttons may enable the use of up to two different sets of modified coordinates. Only the left and right cardinals may change, and they may cross zone boundaries to allow for angled f-smashes. The only permitted use of c-stick modifiers is for angled f-smashes without requiring a frame-perfect simultaneous press of two c-stick buttons. As travel time and output fuzzing are not mandated on c-stick inputs, modifiers may not be used for other purposes, such as allowing the user to target more than one diagonal ASDI coordinate.
  • A c-stick replaced with digital buttons must have those buttons clustered together, satisfying one of the following requirements:
  • On a standard GCC-like controller, if the c-buttons occupy the same location as the analog c-stick they are replacing, they must be clustered in their natural layout (that is, with C-up at the top, C-left on the left, etc.). This keeps the “c-pad” legal.
  • On a rectangle controller, if the c-buttons occupy the location below and separate from the other face buttons such that they are primarily meant to be pressed with the right thumb (left thumb if the control stick is primarily meant to be pressed with the right hand), they must be clustered together with the A button. The cluster can be arranged in any order with the restriction that C-down must be below the other c-buttons. This rule limits the ability of players to separate C-down from A and the other c-buttons to avoid allowing ASDI down to become more powerful than it already is. Most commercially available rectangles comply with this rule in their default layouts.
  • Regardless of controller, if the c-buttons occupy any other location, they must be clustered together around the A button in their natural layout (that is, with C-up primarily above A, C-left primarily to the left of A, etc.). This allows for layout flexibility while still limiting ASDI down.
  • OPTIONAL GRANDFATHER CLAUSE: As long as it uses an analog stick for control stick outputs and does not change the default layout of its c-buttons, the Smash Stick is legal despite not satisfying the above requirements. Since Smash Stick predates these rules and has a button layout which would be difficult to modify to satisfy them, this provides an optional way for TOs to keep it legal.

Digitized C-Stick

  • An analog c-stick may have its output divided into 9 zones (deadzone, 4 cardinals, and 4 diagonals) where each zone outputs the same coordinate in its entire range. The ranges do not need to correspond exactly to Melee’s analog zones, but they must be arranged in the same order (i.e. you cannot press the c-stick up and left to send Melee a coordinate in the bottom-left diagonal area). Zone mapping must be static and cannot change under any conditions within a match. This provides players with the equivalent of digital c-stick buttons without having to make a hardware modification to their controller.

Limits on Target Coordinates

  • Digital buttons and digitized analog sticks must not target certain c-stick coordinates. This nerf is meant to account for the fact that individual coordinates are considered too precise to reliably hit on a GCC-like controller.
  • The following coordinate ranges cannot be targeted:
  • Popo and Nana Simultaneous Uair/Fair or Uair/Bair
  • Samus’ “slight-angled” f-smashes
  • Coordinates which provide larger magnitude outputs than can reliably be targeted on a GCC-like controller’s rim
  • You may not change the coordinates output by digital c-stick buttons or a digitized c-stick in the middle of a match.

Frequently Asked Questions

  • “Have top rectangle controller players tested a controller that complies with these rules?”

Yes, they have tested and provided their feedback. The most common feedback is that they can definitely feel the nerfs, but can still play in tournaments on a rectangle controller after adjusting.

  • “Do I have to use your team’s firmware on my rectangle controller?”

No. The firmware we’ve written is compliant with all the rules and compatible with most rectangle controllers, but other compliant firmware written by other groups can be used too.

  • “Am I allowed to have a c-down button on the back of my controller?”

Due to the rule that states “if the c-stick is split into buttons, all buttons must be on the same plane/face of the controller”, you can only have a c-down button on the back of your controller if the other 3 c-buttons are also on the back of your controller. Otherwise, you may not do this.

  • “Can I have a rectangle controller that uses an analog control stick?”

Yes, and in this case much of the ruleset does not apply to your controller.

  • “Can I have modifier buttons that impact an analog stick?”

No. if you are using an analog stick (whether on a GCC-like or a rectangle controller), it may not be affected by modifier buttons.

  • “Doesn’t neutral SOCD have some advantages over other types of SOCD?”

Yes, it’s a tradeoff and not a strict nerf. The goal of this proposal isn’t to strictly nerf rectangle controllers, but to remove the parts that are too good – which neutral SOCD accomplishes.

  • “Why do I sometimes get a different wavedash angle than the one I chose?”

This is caused by travel time. You changed your angle less than a frame before the input was read, so your analog output was still moving to the target coordinate when it was polled by Melee. Some players have noticed that this allows them to try to hit very steep wavedash angles, which is an allowed consequence of travel time.

  • “Can I still do the rectangle controller left-right moonwalk under these rules?”

Yes, this is a 2-frame input and can still be done through travel time and neutral SOCD.

  • “Do the timing-based nerfs work everywhere?”

Yes, all nerfs work everywhere.

  • “What nerfs were tested but ultimately not included in this proposal?”

Several options were considered that did not make the final proposal. Other SOCD options were discussed, including 1st-input priority (which was discarded without testing). Multiple travel time implementations were tested. Increased fuzzing radius was also considered but would have been too restrictive on target coordinate choices. Travel time and input fuzzing on c-stick inputs were declined and replaced with limits on c-stick modifiers and coordinates, respectively.

Addendum: Philosophy and Justifications

The existing state of controller rules in Super Smash Bros. Melee tournaments is practically the Wild West: many controller manufacturers understand that their devices are capable of significantly better performance relative to even the best OEM GameCube controllers, and so willingly nerf their devices; there are no broad requirements that any of these nerfs be applied, since most tournaments lack any level of comprehensive controller rules; and despite lacking enforcement ability, the remaining tournaments use a ruleset that sorely needs updating. This proposal seeks to be that update, modernizing Melee’s controller rules and leveling the playing field for all controller types.

The philosophy behind this proposal stems from the belief that the following are true:

  1. Given a finite supply of first-party OEM GameCube controllers, it is important that third-party controllers be allowed, with restrictions such that they don’t obsolete OEMs
  2. It is important that rectangle and gcc-like controllers be closely matched in strength, such that players of either controller type do not feel that they are immediately at a disadvantage relative to players using the other controller type
  3. Rectangle controllers, in both their completely unconstrained state and with the nerfs that some firmware manufacturers apply to their own devices, have significant enough advantages over GameCube and gcc-like controllers that they are overall the superior choice at this time (after accounting for gcc-like controllers having a 15-year head start)
  4. Given restrictions around game modification, it is not possible to buff gcc-like controllers to the point where they match the overall strength of current rectangles

Thus, this ruleset proposes to nerf third-party gcc-like controllers to bring them in line with high-quality OEMs, as well as nerf rectangle controllers to bring them in line with gcc-likes.

Expanding on point 1 above, the proposal considers certain behaviors seen in third-party controllers to significantly exceed the capabilities of OEM controllers:

  • Goomwave controllers have toggles which drastically increase the range of certain inputs; for example, making u-tilt easier by carving out a significant part of the controller deadzone
  • Goomwaves have toggles to make the windows of certain inputs easier; for example, making dash back out of crouch easier, which triggers on a motion that is interpreted to be an attempted but failed dash back out of crouch, and instead delivers a 1.0 cardinal input to Melee which will be read as a successful dash back out of crouch
  • Goomwave notch calibration code allows for drastic magnitude changes far beyond what a reasonable OEM could achieve without negatively impacting performance

These capabilities, and more, do not emulate any behaviors seen in OEM GameCube controllers. They result in a controller that is far stronger than an OEM, and for this reason this ruleset proposes that the official Goomwave firmware be banned and that users with Goomwaves flash their devices with compliant firmware once one is available. Furthermore, this ruleset proposes that these restrictions apply to all third-party gcc-like controllers, though no other controllers are known to have firmware which cannot be configured to be compliant.

Expanding on point 3 above, the proposal considers the following areas to be significant, core advantages of rectangle controllers under the current status quo:

  • The ability to easily, instantly change direction due to 2IP SOCD.

2IP is pretty clearly an overall improvement over an analog stick for Melee - it allows you to change directions faster, more precisely, and with a smaller execution requirement. You can act and react quicker, and thanks to digital output you will never need to sacrifice input accuracy for speed. Neutral SOCD maintains several of these advantages, but crucially increases the execution requirement to bring back some parity with gcc-likes. This ruleset does not aim for the honestly unreasonable goal of bringing every single aspect of rectangles in line with gcc-likes; the neutral SOCD requirement of releasing left to press right doesn’t have a direct analog on gcc-likes, but neither is there a rectangle analog to the gcc-like failure state of losing precision when attempting to perform quick motions. Additionally, some current rectangle firmwares use a very specific exception to their modifier rules to make ledgedashes easier: when left and right are both pressed while a modifier is held, the modifier is ignored and a 1.0 cardinal output is retained. This behavior has absolutely no analog to a gcc-like, greatly simplifies the execution of a ledgedash, and is only possible with 2IP. For these reasons, this ruleset proposes that neutral SOCD be the only permitted SOCD method on rectangles. Neutral SOCD also comes with some advantages, most notably easier ways to perform dash back out of crouch, but 1) this proposal is meant to bring rectangles in line with gcc-likes, not strictly nerf rectangles, and 2) nearly every neutral SOCD execution technique has a similar method on 2IP.

  • The ability to skip the control stick coordinate grid on the way to a target coordinate.

GameCube controllers are always at the mercy of analog polling. If you move your control stick and press A at approximately the same time, a gcc-like controller will always risk outputting a jab, f-tilt, or f-smash; if you try to dash jump and nair on the first frame possible, a gcc-like will always risk outputting a fair instead. Rectangles lack this weakness - when you press a control stick button, you will always output your intended value on the next frame. We performed multiple high-resolution tests on the speed of very fast analog inputs relative to buttons, and determined that buttons hit their actuation threshold roughly 5 ms faster than you’d get to the dash threshold on a gcc-like with a very fast analog stick. Similarly, releasing a button is roughly 9-10 ms faster than allowing an analog stick spring to propel it back to the deadzone. This actuation speed advantage manifests itself in gameplay as a reaction speed buff - the same user will have a higher reaction techchase rate, faster dashdance away from an opponent’s move, and more, given the same practice time on a rectangle relative to a gcc-like. The current status quo and rulesets which lack travel time simulation will always grant rectangles this advantage, and the proposal team does not agree that this is an advantage that cannot be neutralized - indeed, this ruleset proposes travel time simulation, directly to neutralize this advantage. The specific timings were chosen to closely match the very fast analog stick motions we benchmarked, which is still a slight advantage to rectangles as they still don’t lose precision on the target coordinate. This advantage is most notably seen when targeting internal coordinates, as these often take multiple frames to settle to with an analog stick. Attempting to match control stick speed here was determined to be unacceptable for the overall performance of rectangles. We have also adjusted the proposal to speed up short “rim roll” motions of fewer than 45 degrees, which the original proposal treated the same as longer, less accurate motions. One valid criticism of travel time is that the user does not receive feedback that their controller has reached the target coordinate, but given that the alternative is the retention of the ability to skip the coordinate grid, we felt that this was still necessary. By the time a player with a gcc-like is able to sense the new position of their stick following a motion, a rectangle’s coordinate output will have long since settled to its target position.

  • The ability to target a specific coordinate with 100% accuracy.

Both on the rim and internally, gcc-like controllers are not capable of pinpointing individual coordinates - the output always risks shifting by 1 or more units. This does not impact the ability of gcc-likes to be used to play Melee, but it does limit certain techniques or make them unreliable. It also prevents players from targeting specific optimal coordinates, for example needing to notch a rim a few units away from the maximal coordinate instead of directly on it. Rectangles lack this weakness - you can target the best coordinate for your needs, no matter how close it is to a failure state, and never risk overshooting. Again this is not strictly necessary to play Melee, but it allows rectangles to be consistent where gcc-likes never could be. For example, this allows rectangles to access Ice Climber single-coordinate desyncs, which are not reliable on gcc-likes, and so some rectangle firmware developers have self-banned these coordinates and released firmware without them accessible. Shifting inputs by even 1 unit makes these specific targets unreliable again. For these reasons, this ruleset proposes coordinate input fuzzing, i.e. sometimes shifting output 1 unit away from the intended target in either or both axes, in order to partially negate these advantages. 1 unit movement, in the form of a 3x3 grid, best approximates holding a value against a gcc rim. It provides an advantage relative to gcc-likes while targeting internal coordinates, but 5x5 and 7x7 grids were investigated and found to not work on a practical level as they result in angle outputs too large to be consistent. In theory, with poor coordinate choices, you could see collateral damage in the form of the same target coordinate outputting two different action states, one of which the player doesn’t want. In practice, with good coordinate choices, fuzzing has no unintended impact and indeed is not detectable from the player’s perspective.

It is the proposal team’s opinion that even with neutral SOCD, travel time, and fuzzing, that rectangle controllers still have plenty of advantages over gcc-like controllers. Even with all three active, players can still perform tighter dashdances than the fastest gcc-likes while not risking leaving the y-deadzone and slowing down; can still reliably perform 1-to-2 frame direction switches which are practically impossible on the best gcc-likes; and can reliably pinpoint an optimal angle which grants them a near-maximal wavedash without risking overshooting and suffering an additional frame of airtime if they airdodge a frame late. Overall, we believe that these controllers are competitive with, and some players will still find them superior to, gcc-likes.

The other parts of the proposal, primarily lockouts and limits on target coordinates, are necessary because rectangle controllers can perform certain complex inputs significantly faster than gcc-like controllers. This is known even among rectangle firmware developers, as some have implemented lockouts and self-banned target coordinates; some of these lockouts and coordinate bans are similar or identical to lockouts and bans implemented by this proposal. These restrictions have been tested over several months, and corrected or removed if they had unintended impacts. The specific timings were tuned based on the fastest gcc players we could find who were familiar with these motions. The often-repeated criticism that “wank SDI” is superior to SDI methods available to rectangle players is irrelevant, as the closest analog to “wank SDI” on rectangles is not locked out under the proposal - it is a form of sustained SDI, and the lockouts only target burst SDI (where rectangles are strictly superior to gcc-likes).

The original proposal banned L and R from being used as non-dedicated modifiers (NDM), with the justification that gcc-like users are not able to adjust their notches depending on whether or not certain buttons are pressed. The existing implementation of a general L/R NDM was also incompatible with travel time, as it resulted in a non-deterministic wavedash/airdodge angle output (from the player’s perspective - this is because the angle output depended on the exact number of milliseconds between the button being pressed and the console polling the controller, and so it could be anywhere from the initial pre-press angle to the final post-travel-time angle). As a consequence of removing the L/R NDM, the proposal both nerfed directional up-B angles and buffed wavedash angles relative to the status quo. After releasing the initial proposal and receiving additional feedback from players, we agree that this consequence, while intentionally chosen at the time, is not ideal for proposal. As such, we have partially restored the L/R NDM with an angle lockout. This sidesteps the travel time issue (as lockouts require an instant movement of control stick output), restores differentiation between directional up-B and wavedash angles, and doesn’t give players control over L or R to use them as an NDM for other purposes. This solution works equally for all rectangles and is enforceable. For these reasons, we are comfortable modifying the proposal to provide a solution for players that’s closer to the status quo. We have also included a slight angle relative to some firmwares which restrict output angles, to bring rectangles more in line with notched gcc-likes. I (PracticalTAS) am not afraid to admit that my original decision here was flawed and that the proposal is better now that we have incorporated feedback on this point.

In conclusion, the proposal team believes that this proposal represents a significant improvement over the status quo in Melee by bringing third-party controllers in line with OEM GameCube controllers. We believe it bans advantageous behavior among third-party gcc-like controllers and nerfs significant core advantages of rectangle controllers. For both controller types, we believe that the status quo results in these controllers having enough of an advantage over OEM GameCube controllers that make them overall superior choices, which is dangerous for the long-term health of Melee. We believe that the resulting playing field under this proposal will be more even, without harming the ability of players to play Melee on their preferred device. For these reasons, we recommend that this proposal be implemented as a controller ruleset addendum at all major Melee tournaments once it is ready.