The in-game timer measures time in frames, which is a fixed 50. The smallest increment it measures is two centiseconds (0.02 seconds), which is the duration of a single frame. Therefore, milliseconds don't make much sense to track (for IL runs), but certainly centiseconds need to be taken into account.

(2/2)

Rebinds, Canceling, Cactusing:

This is a major issue for Campaign individual levels (1-1, 1-2, etc.), but is still a relevant consideration for Campaign any% and Campaign 100% categories.

I Wanna Maker has several rules regarding scripting; for example, multiple shoot keys are disallowed completely, and bans have been handed out for autofiring. However, there remains a rather large grey area when discussing what is permissible and what is technically impermissible but unenforced.

For example, cactusing is almost always performed with a script (usually autohotkey) to allow multiple of the same key on one keyboard, but it is possible to use a multi-keyboard setup, hence avoiding the script. Furthermore, there are many player-created maps that explicitly require cactusing to clear, and to the best of my knowledge, these have never been subject to removal, let alone as a cause for banning.

Then, there is the speedrunning culture of the community to consider. Many of the game's top speedrunners (for player-created maps) rely on tech like cactusing to achieve faster times. The tacit permission these runners have been granted all but ensures that such tech will be used extensively in IL speedruns. While this is not necessarily a problem, it does create an uneven playing field between those who are willing to go the extra mile and those who are not.

As I stated earlier, this is a relevant discussion for the Campaign any% and 100% categories as well. Keeping with the cactusing example, oftentimes the fastest way to increase fall speed is to perform a cactus (or even a double-cactus). More prominently, the tech creates arcs that can be impossible to have ordinarily, potentially making some strategies (e.g. a fast cycle) or skips possible for only the portion of the player base willing to delve into an in-game grey area.

The faster fall speed is clearly an issue over a longer run as well, since theoretically one could cactus (or otherwise cancel) many or all of the hundreds of falls one performs over the course of a run.

I see two ways of addressing this. The first is going for a free-for-all, with the exception of infringements that have been handled punitively in the past by the game's developers (autofire, multiple shoot keys). The second is disallowing all rebinds and concomitant tech; if the player wishes to use binds that differ from the default ones, the player can use the game's control menu to remap, for example, the jump key. No autohotkey scripts would be allowed.

The second option would be my preferred choice, but policing this would, I believe, require a robust and accurate input viewer. There are a few that see regular usage within the community, so perhaps one of those would be an appropriate fit.

Finally, a third approach is to create two subcategories: one that adheres to the first option, and one that adheres to the second option. This is probably best suited for ILs.

Sorry for the long post, but I do feel that all of this is salient. Being proactive with rules and enforcement should help mitigate the issues that have plagued countless speedrunning communities.

(1/2)

Psyched to see the Campaign categories be added.

As for when a run should begin, my vote is to begin the moment the player clicks the "Campaign" button. There are a couple reasons for this:

• It is far more awkward to split accurately while having to actively move than it is to split while simply clicking a mouse; otherwise, the player will be simultaneously holding down jump and right arrow (followed quickly by up arrow), then have to press whatever their split control is. This will produce more frequent errors with splitting, and subsequently more resetting and retiming.
• The opening cutscene requires input from the player in order to optimize, as it can be skipped by holding down the skip button.

The only downside I can think of is the inclusion of two additional loading times (entering and exiting the opening cutscene), but given their brevity—as well as the inclusion of dozens of other loading times in the run—the impact of this should be negligible. (Load-removed times are a consideration for later, perhaps, if the Campaign sees close competition.)

Regarding rules:

Currently (the current version is 1.004), there is a timing error regarding the time displayed upon clearing a level. Prior to having cleared a level, the timer in the lower right-hand corner is not displayed until the player reaches a warp; this time is accurate. However, there is a second time that appears in a separate screen (the one that shows summary statistics of the player's performance in the level, including clear-time, deaths, and gems collected). This timer is frequently inaccurate. Therefore, the region in which the accurate timer appears upon touching the warp (the bottom right) should be kept unobstructed by anything the player adds on the screen (e.g. splits). This is a protective measure for competitive integrity in two ways:

• as a dissuasion again splicing, though doing so is still, I believe, quite possible); and
• as a way to combat doubt against the differing times that appear upon touching the warp and on the subsequent clear screen.