If you haven’t been following along, you might have missed that there’s been a rather large discussion in the RTA community with regards to mapping digital inputs to analog outputs. Simply uploaded a great video detailing the different viewpoints and issues with this mapping, and if you haven’t yet seen it, I suggest watching before reading on.

In the past, any changes to leaderboard rules have been decided by the RTA Discord moderation team (a group of about 15 members with various backgrounds, all very knowledgeable about the game and the community). However, until now we hadn’t run into a situation where both the moderators and the community were so divided on what changes should (or shouldn’t) take place. To combat this, we held the first community-wide poll to determine the fate of the rules regarding input re-mapping. This document was included in an announcement and members of the community were given one week to vote on which of three options they preferred. The poll used a ranked voting system called Instant-runoff, which I’ll dive into more later. It had voters rank the following three options:

• Option 1: Allow the use of analog stick to button remap functionality. No restrictions on using or swapping between control schemes mid-run, including schemes where multiple inputs correspond to analog output. Macros and turbo functions are still not allowed.
• Option 2: Force consistent mapping. In order to maintain accessibility, re-mapping of controller inputs/outputs in SM64 is allowed, but it has the following restrictions:
  • The re-mapping scheme at the beginning of the run must remain for the entirety of the run. That is, a runner using a controller that maps buttons to analog inputs (e.g. Boxx) must use a controller with that re-mapping scheme for the duration of the run. Swapping controllers to ones with the same re-mapping scheme (e.g. swapping from OEM N64 to Hori Mini Pad) is acceptable.
  • There should be no overlap in mapping analog to analog inputs or analog to digital inputs. (You cannot map analog up to both a control stick and the “A” button.) Digital inputs can be mapped to multiple buttons as it does not provide a competitive advantage. (The hori has two Z buttons, but only one press is registered if both buttons are pressed simultaneously.)
• Option 3: Ban the use of mapping analog stick ranges to buttons. This option bans the use of analog stick to button remapped control schemes. GC controller on raphnet adapter is allowed, however you cannot map an analog stick to a button. This would effectively ban controllers like the Boxx.

Results

Following the poll, the votes were tallied (all 116 of them), and I present the following update to the RTA leaderboard rules:

For runs submitted after September 6, 2019 at midnight GMT, the following addition to the rules will apply:

Re-mapping of controller inputs/outputs is allowed, with the following restrictions:

• The re-mapping scheme at the beginning of the run must remain for the entirety of the run. That is, a runner using a controller that maps buttons to analog inputs (e.g. Boxx) must use a controller with that re-mapping scheme for the duration of the run. Swapping controllers to ones with the same re-mapping scheme (e.g. swapping from OEM N64 to Hori Mini Pad) is acceptable.
• There should be no overlap in mapping analog to analog inputs or analog to digital inputs. (You cannot map analog up to both a control stick and the “A” button.) Digital inputs can be mapped to multiple buttons as it does not provide a competitive advantage. (The hori has two Z buttons, but only one press is registered if both buttons are pressed simultaneously. This is acceptable.)

Transparency

For those of you who just cared about the results of the votes, you can stop reading now. However, I wanted to make sure to provide as much transparency as possible so there’s no SM64 Illuminati rumors spreading about.

First, here’s a graph of the overall responses:

You’ll find that Option 3 (ban mapping outright) had the most votes for first choice, but did not win the poll. This is due to how Instant-runoff works, and I assure it’s by design. Notice how many people ranked Option 2 as their second choice. In short, the way Instant-runoff works is that you tally all of the “first choice” votes, and if there is not a majority winner (>50%), then you eliminate the lowest-voted option (in this case Option 1) and for every voter that had Option 1 as their first choice, you apply that voter’s second choice to the totals of the remaining options. After that tally, you end up with two options remaining, one of which has a >50% majority.

Here’s a table denoting all of the relevant vote counts that led to the result:

Poll results	Number of votes	Number of votes post-runoff
Allow re-mapping (Option 1)	31 (26.72%)	0 (0%)
Consistent mapping throughout run (Option 2)	38 (32.76%)	63 (54.31%)
Ban re-mapping (Option 3)	47 (40.52%)	53 (45.69%)

Instant-runoff Thought Experiment

There’s a chance the results above still don’t make much sense to you, and that Instant-runoff might be unclear. I’ll try to explain this vote a different way:

Imagine that instead of one vote with ranked results, we instead decided that we’d have up to two votes. The first vote would be whether re-mapping should be banned in some way (either completely or by forcing consistent mapping throughout the run), or whether it should be allowed altogether. Then, after that vote, if “ban in some way” won, we’d hold a second vote with the same group of voters on whether we should ban re-mapping completely or whether we should force consistent mapping throughout the run.

Given the above voting practice, we can use the data we’ve already collected to see how it would play out. Anyone who made Option 1 as their first choice would vote to allow re-mapping, while anyone that made Option 2 or Option 3 their first choice would vote to ban in some way:

First vote	Number of votes
Allow re-mapping	31 (26.72%)
Ban in some way	85 (73.28%)

Now that “ban in some way” has won, we hold the second vote with the same group of voters. In this case, the votes for “force consistent mapping” would contain all people who made Option 2 their first choice in the original poll plus all people who made Option 1 their first choice and Option 2 their second choice (these people are still voting in this poll, but they can’t vote for Option 1 anymore because it lost the first poll). Likewise, the votes for “ban completely” would contain all people who made Option 3 their first choice in the original poll plus all people who made Option 1 their first choice and Option 3 their second choice. We have all of these numbers from the original responses:

Option 2 as first choice	38
Option 1 as first choice, Option 2 as second choice	25
Option 3 as first choice	47
Option 1 as first choice, Option 3 as second choice	6

And with that data we can see the results of our hypothetical second poll:

Second vote	Number of votes
Force consistent mapping	63 (54.31%)
Ban completely	53 (45.69%)

You’ll likely notice that these results look exactly like the results of the real poll that happened. That’s because this two-poll system is how Instant-runoff works mathematically; it just gives us the benefit of handling the primary poll and the hypothetical second poll in one go.

Vote Reasoning

If you voted, you might remember having to provide your reasoning in your ballot. You can view a spreadsheet with a list of votes and their reasoning right here. The “name” and “relationship with community” fields have been removed to keep the votes as anonymous as possible (although plenty of people are quite vocal about their choice).

Voters with No Background

Some voters might be concerned that since the poll was public, we’d receive votes from people who, while they might be able to write a reasoning, don’t really have very large ties with the community and aren’t actually affected by the results.

The moderation team also considered this and we marked some votes that were from people who we felt were not really a part of the community (There were 20 of them). If we did decide to not count those votes (note: all of the data above does count these votes), then the final results would have been the following:

Poll results (from reputable community members)	Number of votes	Number of votes post-runoff
Allow re-mapping	26 (27.08%)	0 (0%)
Consistent mapping throughout run	33 (34.38%)	54 (56.25%)
Ban re-mapping	37 (38.54%)	42 (43.75%)

Conveniently, we found that including or excluding these votes had no effect on the results, and a very small effect on the actual percentages.

Conclusion

Hopefully this provides all of the insight you were looking for into the first community-wide vote in the RTA community. If you have any questions about the poll results, re-mapping, or SM64 RTA in general, then I definitely recommend joining the SM64 Speedruns Discord. You can also reach out to me on Twitter or DM me on Discord (minikori#0001).

minikori