Rivals 2 Wiki: Move Cards

When I originally joined Dragdown, there were two games. One game was Super Smash Bros. Ultimate, the most popular platform fighter by a long shot. That's what the wiki was originally built for. The other game was Rivals of Aether II, an indie title that was funded by a big kickstarter earlier in the year, and it had basically released a month ago.

I was originally there as a writer. To help write about system mechanics for a game that I could understand thanks to my background in Melee, as well as having more experience than your average platform fighter player in communicating information succinctly. Then I started helping writing for characters, because I was dissatisfied with the lack of writing for them. One thing after another, and for some reason, I end up writing code for the wiki as well.

The most notable thing of all that countless people have seen is probably this single module. It's titled "RoA2 Move Card", and it looks like this.

A screenshot of Clairen's Back Air from Rivals of Aether II, as presented on Dragdown Wiki.

It's written in Lua, a language nobody would willingly write code in, with this library of other functions from Scribunto that helps to write HTML and CSS. About a thousand lines of code.

The design looks clean, and it's probably one of the most reliable resources in platform fighters. With that said, it took months to get here.

Dustloop

A screenshot of Ky Kiske's 6P from Guilty Gear Strive, as presented on Dustloop.

Dustloop is probably the pioneer of fighting game wikis when it comes to modern presentation. It's a big wiki for Arc System Works fighting games. Compared to other wikis, its layout is more direct and doesn't obfuscate as much. In fact, Dragdown's layout is directly inspired by it, partly with many of the same members who initially started Dragdown having crossover in terms of content.

Traditional fighters are relatively easy to discern when it comes to moves -- they present hitboxes, and if the hitbox connects, the character is launched a certain way. It's really nice when Dustloop does it this way.

Let's look at Dragdown.

A screenshot of SSBU Mario's Forward Aerial, as presented on Dragdown.

A few notes:

The multiple rows here represent different timings of the same move. Unlike traditional fighters, concepts like "sweet and sourspots" are common place, where the move will send differently depending on the hitbox that connects, even if it belongs to the same move. Also, different hitboxes will appear on different frames of the move, meaning that timing also matters. This isn't unheard of in traditional fighters, but it's not common enough to warrant something like this.
There's no indication on how the move itself behaves, just the hitboxes. The player still has to calculate endlag, startup, and there isn't anything for landing lag.
The total frames column is being repeated. It's really redundant.

Ultimately, though, this is an older game, and a lot of its use has been superceded by Ultimate Frame Data. What about Rivals 2, the wiki's new game? Everything for that was done in October 2024, so how was that set up?

The old Rivals 2 cards

Wrastor's D-Tilt, from RoA2 on Dragdown. Old screenshot from November 2024.

Now we have several columns being redundant and repeated. We even have a useless "landlag" column taking up space right now. In fact, for each row, we have to input this data separately, which causes a whole slew of issues with manual input error. Half the data is timing-based, the other half is hit-based. In fact, we're beginning to observe a pattern where move timing and hitboxes are actually somewhat separate when we treat how we think about moves.
As it turns out, the active frames column was something that was constantly confusing users who inputted it in the data pages. Some would input "7-9", some would do "3" to indicate the amount of frames, some would do "7-9 (3)" to add both.
The timing of the move is being conflated with how the hits behave -- there's a distinct separation between the right side columns (knockback, angle) and the left side columns (startup window, active frames, endlag, IASA, landlag).

This is an issue on several moves. I could tell you that there's a mistake in the following table, but there's just so many numbers on the screen. After staring at hundreds of these numbers, they just all blend together. A screenshot of an incorrectly inputted Clairen D-Strong data. This is just an egregious amount of repeated numbers. Clairen F-Air data. There's also moves without hitboxes. Grabs are an example where you only care about the timing and when it is active, but if the system is built around all these other things, we just end up with a bunch of blank cells. Clairen Grab, using the old move card. Half of the cells are just empty.

Change

I got sick of this about a few weeks in, and I started becoming more vocal about changing this, especially once I got handed charge of the project.

January 2025 was when I started mentioning explicitly the idea of separating move data and hit data. In my mind, startup/active frames/endlag were completely independent from what a hit would do when it connected with the opponent, and it should've been treated that way.

Feburary 2025, I made the following statement: "We need to figure out a way to show frame data and hit data on a move elegantly." Very bold. This is what I was working with. alt text

This is what was prototyped in March 2025. alt text

A few things stand out immediately.

In the old move card, the endlag and other related columns had three rows of text, and that's because the move behaved differently on hit, on whiff while grounded, and on whiff while airborne. Now, these three behaviours are treated separately for the reader to understand. These are internally called "Move Modes", clickable tabs that will display different information depending on how many different behaviours the move can exhibit.
Additionally, instead of one large table of hits and frame data lumped together, there are now three sections: frame data (timing), the frame chart (visual representation), and hit data.
Frame data being separated into its own separate display eliminates the redundancy of five different endlag values, or whether endlag is referring to the move or the hit.
Frame chart is a visual representation that the previous move card was sorely lacking. This gives users a quick way to discern the timings of the move.
Because there is more space for columns, there's more hit data we can show off now, including safety on shield.
Most importantly, it just feels so much less suffocating.

A principle I got from working on Pokemon calculators is that the fewer numbers to read and worry aobut, the better. People want to get to good information fast, they don't want to read Excel spreadsheets. Between March and June of 2025, I keep working on it on and off, with getting a lot of user feedback in the meantime. In retrospect, if I learned Lua from the start and used that instead of MediaWiki's parser language, I probably could've gotten it done faster, but after the roadbump of realising that using parser language would cause it to take 15 seconds to attempt to load a page and then run out of memory, I just focused on writing Lua.

Current Version

I released the current version on June 2025, and between then and now, I've made a few tweaks, but for the most part, this version maintains the same spirit of the original card I pushed back in June.

Current version of Clairen U-Air on the wiki.

There's a lot of other features that didn't come up in the initial test.

Initially, CheesyPotato mentioned that it would be nice to know about unique hit properties. This is common in Rivals 2, so originally I opted for adding a cell on the right, but I ended up putting this below each row. A long list of text does not fit in a single column, and this is nice to only show up when necessary.
ZeusDahGoose had proposed the idea of an angle indicator -- in most platform fighters, every hit has its own launch angle which can be further influenced. While reading "30" is certainly useful, it is much easier to see what angle 30 degrees is than imagining.
Danzello had also mentioned ways to further delineate colours in the frame chart (the meter with a bunch of colours). This ended up being alternating colours on the frame chart, which is really useful for attacks where you charge in the middle of them to make them more powerful.
There's also some important cells like shield safety, tumble percents, and crouch cancel percents. These are actually all automatically calculated -- the benefit of having two separate databases for frame data and hit data is allowing for flexible calculations like these, and giving the ability to work in exceptions where needed. A lot of the philosophy centres around decreasing the possibility for human error. Ease of access both for inputting and reading data is essential.

The Future

I'm pretty happy with the move card as it is right now. There is a big update I want to make to it, but there are some obstacles with performance that have to be addressed first. MediaWiki is a finicky system that doesn't handle loading images well as well as loading data efficiently. I want to eventually push this full scale to the other games we're working on as well, like P+ and NASB2 (and other games, further down the line), but addressing that first is going to be my priority. It's harder to say for certain for fixing the Ultimate frame data cards, since it's fallen to the wayside due to Ultimate Frame Data, and I don't have the internal data to create new tables for it.

Still, I think this project is really cool. It's probably really cool when someone like the arguably most notable Rivals 2 streamer, Coach Zeke, says "I owe you my life" in response to something like this.

This project wouldn't have gone anywhere without the wonderful people who helped me along the way. Thank you to everyone who I've talked to about this, and with distinct mention:

CheesyPotato, for the uniques row, that thing was awesome to build.
Zeus, for the angle indicator -- this idea gets flown around as the coolest thing about the card, I even saw it got mentioned in the Dustloop server once. In case people wonder, it's just three images on top of each other with CSS rotation on the middle image.
Danzello, for going back and forth with me on how frame data meter should be displayed. Hope you're having fun in Rivals 1!
Pikmon, for the extended condolences about having to write in Lua. Also the frequent teasing about having to write in Lua. Why does Lua count starting from 1 instead of 0? Why?
The thirteen people I DMed at 2AM, asking about what "startup" means (this is a whole separate diatribe), and Clementine for getting me to add "Active On" in the frame meter.
BlueBubbee, for literally handling all of the Lua for modules centred around cosmetics and styles on the wiki so I can focus on writing the frame data stuff. It's so useful.
M, for being the person that heard me talk their ear off about this the whole way. Sometimes, I need to be a 5 year old who came back from school, asking my mother to see my terrible drawing that is fridge magnet material. Seriously though, M has also constantly been there for me to bounce questions off of and sanity check when I need to justify why I'm doing a design decision. A lot of good work is born from arguing in the details.

There's a unique joy in having a chance to make something and be somebody. I plan to keep on making cool things. When years go by, and I'll have made many more cooler things, it'll be nice to look back on this and think about it. A time where I pushed myself to make something that didn't exist before.