Rivals of Aether

Rivals of Aether

Qua Mario
Floral qua Floral  [developer] 16 Nov, 2021 @ 10:22am
Compat for Devs: Floortypes
Floortypes are a purely cosmetic detail that affect the sounds of Mario's footsteps and the particles that appear when he interacts with the floor. Stages can have a default floortype assigned which will be used when Mario isn't standing on special terrain - however if Etalus puts down some ice, or Sylvanos puts down grass, those floortypes will override the default in that area of the stage. You can have Mario apply some of his floortypes to your stage, or create some yourself. Characters can also use floortypes, most realistically for their solid articles. To set up a default floortype that will cover your entire stage, you just need to put the following in your stage's init.gml:
neo_data_compat = { default_floortype: "snow", default_floortype_plats: "wood" };
Now when Mario is on your stage, he'll use the "snow" floortype on the solid parts of the stage and the "wood" floortype on platforms. Perhaps your stage is a snowy area with a cozy wooden cabin that serves as a platform! Qua Mario contains the following floortypes that can be selected using strings:
  1. "block": The default floortype when none is given. Pretty generic stepping sounds from New Super Mario Bros. Wii. I would deliberately select this for surfaces that are just Video Game Blocks, like the Tower of Heaven stage.
  2. "dirt": Used on dirt, grassy stages, and also on any terrain covered by Sylvanos grass. Has different sounds from NSMBWii and uses a more translucent, dark brown dust sprite.
  3. "rock": Used on stages made of rocks and bricks. Sounds very similar to "block", but the sounds are slightly different. The dust particles also start out dark and get lighter as they animate.
  4. "wood": Makes pleasant wooden footsteps from the Airship levels of NSMBWii. Uses the same dust as "block".
  5. "sand": Sandy footsteps from NSMBWii. Creates "droplet" type particles that are smaller than the normal sprite and yellow instead of blue.
  6. "snow": Snowy footsteps from NSMBWii. Uses the "dust" particle type but with a unique sprite made to resemble glittering snow rather than actual dust. Instantly makes Frozen Fortress one of Mario's best stages objectively
  7. "tree": Planty footsteps from NSMBWii. Uses the same dust as "block".
  8. "cloud": Uses the footstep sounds from "snow", but the skid sounds and dust from "block".
  9. "metal": Uses some footsteps snipped from a stock sound clip of a person walking up metal stairs.
  10. "puddle": Uses water footsteps from NSMBWii. Mostly only used for Orcane's puddle, there's also a little bit of this floortype on the top plat of the Lovers of Aether stage.
  11. "ice": Plays the squeaky slippery ice sounds and has no ground-interaction particles. Because this is just the floortype, it doesn't actually affect Mario's physics at all.
  12. "agent4_ink": Plays the footstep sounds from "puddle", but with the skid sounds and dust particles from "block". Intended to serve as a compatibility feature for another character I was working on a while back, Agent 4 from Splatoon 2. I had to shelve the project indefinitely because I can't make the sprites for it. If you'd be interested in doing that for me, let me know please?
  13. "invalid": This is the floortype it will default to if you enter a string that isn't on this list. Please don't use it intentionally, it's loud and makes ugly particles. If you enter an invalid string, this floortype exists to make it very obvious you've made a mistake.

For Advanced Users: Floorzones
If your stage has multiple types of floors (for instance, Fire Capital's lower plats are wooden crates, while the upper plats are stone slabs), you can also use the Floorzones struct to tell Qua Mario to create custom articles that will temporarily change his floortype when he stands in them. These are designed to be performance-efficient, so don't worry too much about including them. The format is relatively straightforward. As an example, here's what an appropriate set of floortypes and floorzones might be for Flophawk's stage Steam Gardens:
neo_data_compat = { default_floortype: "metal", default_floortype_plats: "metal", debug_floorzones: true, make_floorzones: [ { type: "rock", x1: (room_width / 2) + 80, y1: get_stage_data(SD_Y_POS) - 175, x2: (room_width / 2) + 270, y2: get_stage_data(SD_Y_POS) - 145 } ], symm_floorzones: [], centre_floorzones: [] };
The Neo Data Compat struct above will make it so the majority of the stage is metal, but the rightmost platform is a rocky surface. Note that "debug_floorzones" is also included, which makes it so that the floorzone will be visible as a green box when you enter the stage as Qua Mario: this is useful so you can tell at a glance whether you've put the floorzone in the right place without having to test. Make sure to either remove that line or set it to false once you've got the right place, since you don't want these to be visible in actual battles - they're just cosmetic, so there's no need for Mario to be able to see them! 😅 x1, y1, x2, and y2 represent coordinates of the floorzone's corners; it's not important whether or not x1 < x2, nor whether y1 < y2; Mario automatically uses the minimum of the pair when setting up the floorzone.
The symm_floorzones and centre_floorzones arrays are very similar and exist just for convenience. Entries in the symm_floorzones array use exactly the same format, but when processed they'll create another identical floorzone mirrored across the stage's center (which is useful for stages like Fire Capital, which has two floorzones with exactly mirrored positions to represent the two wooden crates). The centre_floorzones array is only slightly different; it is intended for stages like the Trouple Pond, where the top platform is a tree while the rest of the stage is wooden. Entries in centre_floorzones use a variable halfwidth instead of x1 and x2, which represents how far from the exact centre of the stage the floorzone's edges are. It still uses type, y1, and y2 as normal.
A note on floorzones: They're only active when Mario's feet are within their box. So if it's floating slightly above your ground, it won't work. It doesn't matter how high it goes above the floor, though - even if Mario is falling at terminal velocity he'll always get the floortype before landing. If you're putting your floorzone on a platform, though, it's wise to ensure it goes at least 20 units below the surface of the platform. This will ensure that Mario will play the correct landing sound if he wavetwirls onto it (a technique similar to wavelanding).
Floorzones don't move and can't be attached to objects. If you have a moving platform or other stage element that'll follow a small fixed path, you can just make your floorzone big enough to accomodate all its possible positions. You can also just emulate Floorzone behaviour by setting Mario's floortype_override variable when he's standing on your article. You can set it to a string or to your own custom floortype struct, the same way it works for default floortypes and for floorzones. You'll have to apply it on every frame that Mario stands on your object - but the good news is that means you don't have to worry about resetting it after he hops off.
Floorzones, and manual floortype overrides, will be overridden by any floor or status effect that change both Mario's physics and the sounds of his footsteps. An example of this is Sylvanos's grass, which improves Mario's traction and gives him the "dirt" floortype.

For Advanced Users: Custom Floortypes
It's also possible to make your own floortypes. A floortype is just a struct, so you can create a struct and assign it to be your stage's floortype instead of using a string. As an example, a stage like Muno's Half-n-Half Showhall might use ethereal, crystalline sound effects for its platform. Its init could look something like this:
neo_data_compat = { default_floortype: "wood", default_floortype_plats: { name: "crystal", adjective: "crystalline", footstep_sfx: [sound_get("qm_crystal_footstep_1"), sound_get("qm_crystal_footstep_2")], land_sfx: sound_get("qm_crystal_landing"), skid_sfx: sound_get("qm_crystal_skid"), skid_sfx_freq: 8, ground_particle: "dust", ground_particle_sprite: sprite_get("qm_crystal_sparkles") } };
Then, of course, you would put some sparkly crystal footstep/landing/skid sounds into your stage and a 4-frame sparkle animation in your sprites, with names corresponding to those in the struct you coded.
  • name: A string that just says what kind of floor this is. Not technically necessary nor used for anything but it fuels my crippling addiction to linguistic metadata.
  • adjective: A string that just describes the nature of the floor. For example, the adjective for the ice floortype is "frozen". no this is not used for anything i just like doing this okay just let me have this
  • footstep_sfx: An array containing two sound indexes. They're played in alternating order every time Mario takes a step.
  • land_sfx: The sound index that plays when Mario lands from an aerial state.
  • skid_sfx: The sound that's played repeatedly when Mario is skidding to a stop, or sliding while crouching.
  • skid_sfx_freq: The interval, in frames, at which the skid_sfx is played while Mario is skidding.
  • ground_particle: The type of particle that Mario creates on interaction with the ground. This type determines when particles will appear, how many, their motion, etc. The only two currently implemented types are "dust" and "droplet". "dust" is used for the vast majority of floors and spawns particles that animate through four frames before disappearing. "droplet" is used for puddles and sand, and spawns large numbers of particles that obey gravity and don't animate. "none" is also an acceptable value which is used to prevent any ground particles from spawning when Mario is on ice. If you want to add a Floortype
  • ground_particle_sprite: A sprite_index that is applied to particles spawned by the ground_particle type.
Unlike with most previously described compatibility features, every variable is necessary for this or you will get errors. (the name and adjective values are never checked and therefore won't actually cause errors, but values are never substituted in so if something does end up checking for them it would theoretically cause an error... please just include these it would make me happy)