Intro
One evening, I found myself in a stream with many community members I knew apart from the lead moderator and the streamer himself who was playing a custom branch of the Wind Waker Randomizer. With the assistance of j_im, I was able to translate my understanding of Python for Maya (PyMEL) to general scripting, as well as a better grasp of GitHub. Through this, I have learned much about cooperation, communication, and conceptualization through reading the preexisting scripts, the raw base game PPC assembly, and aid from others, like CrainWWR and tanjo3. This is how the project originally named v_im was born.
A Brief Overview of Game Randomizers
A randomizer is a class of game modification that changes some aspect of gameplay in an unexpected manner, often checked by a system known as logic. Action and adventure titles often get something known as an item location or check randomizer, in which collectables and their locations are shuffled among each other, creating a new and often unique gameplay experience through many of the same forms of engagement as metroidvanias or roguelikes. Logic, for this kind of randomizer, is a set of rules that define what collectibles are then required to reach a specific item location. For example, in The Legend of Zelda: Ocarina of Time, players must have a Deku shield and a Kokiri blade before they can access any location within the Great Deku Tree. Using logic, the randomizer would then decide nowhere within the Great Deku Tree is a valid location for either the Deku Shield or Kokiri blade but would be for the Fairy ocarina or any other number of items.
Kindling
DGod63 is a Twitch streamer known for playing randomizers of The Legend of Zelda franchise, who I found one night on which sometime in late May 2020 because of lost hours during the early SARS-2 pandemic. However, he was running the randomizer from source, allowing him to make additional modifications which in the past were denied by the sole developer of the randomizer. The modifications to the code enabled him to change the required number of dungeons for race mode, a setting which made all non-required dungeons illogical, effectively empty in the eyes of the player, locations and made required dungeons end in a hard-required item, an item needed to beat the game. At the then-current official 1.8.0, players either played without race mode or could only have 4 dungeons, not upwards of the 6 possible dungeons in the game or fewer.
Also around this time, another popular randomizer was transitioning its community season from 3 to 4, changing its hint policies making them less helpful. In the next official update of Ocarina of Time Randomizer, hints could only be set to this more conservative option, forcing players to either use an older build or use this new policy. A forked build, known as the Roman Build or Roman Branch, rapidly gained popularity as it allowed for either hint policy without disabling other newer features. The Roman Build acted, up to this point, as a testing ground for features that were highly requested, but that the main developers didn’t want to provide. Often the course of action was a feature being added to the Roman Build, it would be brought to the main branch, then the Roman Build would switch to the more concise version created by the main developers.
A Spark of Energy
I sought answers as to how I could also do variable race mode in the Wind Waker Randomizer, I had some knowledge of Python so it wouldn’t be too terrible, right? When I messaged DGod, his answer was simple, having only edited one number in the code as instructed by j_im, the community moderator. I followed the trail and j_im told me much the same, edit this number on this file to the desired amount. I, while now having my answer, was dissatisfied with this solution, as it would not provide easy access to anyone who wouldn’t or couldn’t run from source. I began testing and playing with a piece of software attempting to edit the Wind Waker Randomizer’s UI. But I began to realize why LagoLunatic, its dev, omitted this option, at least up to 6 dungeons; the higher number of required dungeons increased the number of hard required items that would be called up. In cases where players start with the full Triforce of Courage and were playing swordless, that would only leave the three progressive bows and the hookshot to be pulled instead. 4 items for 4 dungeons. This list would need to be extended to encapsulate the 2 additional requirements. However, in side effect of increasing the number of required dungeons, the number of hard required items also increased. As such, the power bracelets and iron boots were also added to the list, as they each only locked Earth and Wind Temple respectively.
I was coming to finalize this rough idea of a small update to 1.8.0, but I felt lacking a name, would be forced to be associated with my name. Another concern I had was competing with Lago’s main branch. It would effectively create a self-cannibalizing market between the two branches, which is not what I would want. I simply wanted to push Lago to add this feature to the randomizer. Without much thought, the name v_im was selected, a basic portmanteau of j_im’s and my screennames. Between d_im and v_im, the answer was fairly obvious, and I felt it best represented the amount of work that each party had made towards this idea. Before I released this on the world, I checked to make sure I wasn’t saying something terribly offensive, only to find that “vim and vigor” was a turn of phrase. Vim means with, of, or pertaining to energy. However, I was not prepared for what would happen.
An Open Flame
DGod was not much larger than other streams I was watching at the time, but as the pandemic continued, his audience grew. A small project intended to make a few peoples’ lives easier was now on display for a large audience. A direct link at the command input of “!v_im”. As the idea that there was more to the Wind Waker Randomizer, more people began airing ideas they felt was missing or lacking. I had not completed a small task but checked a small box on a much larger list. It was known I was effectively unemployed and capable of basic level programming/scripting. Despite what I had thought originally, it was a good feeling, helping bring joy to people. A new version but not many changes in retrospect, it was becoming more clear v_im was becoming more the community and me and less j_im. It was a great name but it was lacking, at least in terms of representing my brand. The answer was a simple rebranding.
An additional “d” was prefixed to the existing name, it would prevent confusion as v_im is just dv_im prior to 1.8.0d. This naming schema matched my other scripting projects, at least on an internal naming level. All my script files up to this point were named “dv_” followed by its function (eg DV Artistic Material Generator is dv_artistic_material_creator). With a subtle name change, also came an imagery change. The use of Hyrule Warriors: Definitive Edition’s Sail of Red Lions might have been a bit vain, effectively treating dv_im as a level up to its source branch which uses the Swift Sail, which acts as the level of weapon proceeding the Sail of Red Lions. However, the sail itself I found hard to read at lower resolutions like in-game, so a question mark was used in place of its imagery.
Playing with Fire
Luckily, I was kept grounded by my shortcomings. I am not a programmer by trade or study, errors and oversights were not an uncommon sight. That still didn’t stop the steam of desired features, one I had been longing for some time. The unedited the Wind Waker Randomizer logic is what can be called a glitchless or trickless logic set. Every expectation it had of the player was that in base game. Players would never be expected to store the item-get cutscene hitbox to sneak around an area. However, all prior attempts of glitched logic came with one tradeoff, they only would exist in place of standard logic. I needed to find a solution that would leave regular logic usable. The UI would be easy, but the backend would be difficult. I found two points where logic could best be edited before it was loaded and towards the end of loading. I decided to go for the latter, referring to it as “logic injection” as it would interrupt and replace some bits of data, requiring the least editing and redundant information for anyone creating a custom logic type.
This caught the attention of community member CrainWWR, who was a the Wind Waker HD speedrunner. The logic sets I had implemented all were fairly basic, representing a scale from standard to what most randomizer players do already. However, Crain had a different idea, what is the fewest required items to get to any particular check. Sure, no logic existed, where there were no checks, but what if there was a checking system, but it only ensured the seed was beatable, but just barely. It was a bad idea due to high risks of bottlenecking, but my primary drive was player options. I was going to play this, but someone might. Though this may have been what brought Crain onboard, he is still a large part of the team and a heavy hitter for dv_im coding.
Throwing Shadows Forward
This project naturally spun to be much bigger than the sum of its parts, dv_im still represents somewhat of a success story. In my eyes, it is still not finished. Going forward, there are a few things Crain, Tanjo, and I have in mind: alternative game modes, alternative objectives, more checks, retooling, and player choice. The next project I am looking at is rebuilding entrance randomization, increasing a player’s ability to choose which locations are included or omitted. As is now, players can only choose to do all cave entrances, dungeons, both, all together, or none. While this is fine and dandy, this means a player would be expected to visit Star Island even if they have combat caves disabled, which is odd in comparison to most other things in the randomizer.
As a long-term goal, Crain was hoping to implement “pot rando”, a sort of alternative to the current boat navigation system. This system is far from even usable; however, we have created a system to create stable branching graphs that will be the core of this. Crain designed it first in Java, I recreated it in Python, and Tanjo optimized and improved it.
dv_im exclusive features:
- Starting Conditions:
- Dungeon Mode
- Editable base health
- Hints
- Randomizable dungeon number
- Randomizable starting Triforce number
- Randomizable starting items
- Text kerning
- Randomization:
- Additional boss rewards
- Editable item pools
- Logic Types (including custom)
- Not Logic
- Randomizable Wind Waker, Ballad of the Gales, Wind’s Requiem, Song of Passing, and Swift Sail
- Remove dungeon nonprogressive items
- Removable health increase items
- 28 Additional Checks
- Customization:
- Animation editing
- Disable parts of model items
- Editable spoiler log output
- Sail choice