Foreward

After countless arguments, I (kan) have decided to collect my thoughts on this common argument into a single, well-composed essay. This is partly so I can express myself in an emotionless and rational environment, and partly because I am fed up with repeating myself. I speak only for myself, but my views here are shared by many, although sometimes tacitly.

This essay is not up for debate, and I will not defend my reasoning in auxiliary arguments. The entirety of my stance is contained in the text below. Further discussion would only result in me repeating myself in an increasingly annoyed demeanor.

The "Vanilla is Infallible" philosophy

If you're reading this, I or someone else probably sent you here after you suggested or implied the need for a change that was rejected or questioned with a reason along the lines of "That's not vanilla." or "That's too ROM hacky." These often-dissatisfactory answers evolved from an exhausted attitude borne from a clash between the demands of a diverse community and the commonly-held, yet vague, philosophy that we (the Randomizer developers; henceforth "we") should do everything with a gentle touch and leave the game as vanilla (unchanged) as possible. Those outside the development circle may attribute this stance to laziness or ignorance, but that couldn't be further from the truth. We all have an understanding of the game engine (particularly those whose focus is assembly hacking), and what isn't known can be researched from the disassembly or by asking someone else who would know (usually me).

Not for lack of ability, we all follow the same stoic principle aforementioned; however, it is important to note that we are not a hivemind. We are each individuals of similar ilk with our own secondary principles that often don't align with one another. What crosses the threshold to be worthy of a fix or change for one will not always cross the threshold for another. There are many examples of this: the shovel can be used to dig up treasure; the jingle glitch is fixed; and quickswap exists. These are not contradictions. This is what development looks like for large, open projects with developers of various breed who come and go. How we approach a potential change is touch-and-go, and our personal opinions come into play then. The only consistency seems to be that we all have a significantly higher threshold of change-worthy than the vocal of the community.

A tangential philosophy

A guiding principle that goes hand-in-hand with the infallibility principle is that anyone should be able to take what they know from previous experience with the original game and apply it to the randomized games they generate. Whether you're a record-holding speedrunner or a person who just does a casual playthrough once a year, we want your existing experience to matter. Few people will know everything, and nearly everyone gets stuck eventually; but, the more you can bring in from the base game, the better your performance will be in the randomizer. This is a unique aspect of game design for ROM hacks in general. The more you change, the less the original experience matters. We want players to be comfortable in that there's not too much to relearn, and that most of what they do learn can carry over to vanilla, or any other ROM hack.

Vanilla as an axiom

An axiom is an established truth. In mathematics, an axiom is true because it is an axiom. They are the fundamental rules from which everything else is derived. For us, the vanilla game is an axiom because it is the very game we are hacking. Regardless of your opinions on the contents within, the vanilla game is an objective constant. No matter what we do with the randomizer, the vanilla game stays the same. This provides an important baseline to refer to when making decisions.

You are free to disagree with our philosophies, but it is expected that you respect our decision to follow them. Being principled allows us to maintain focus on our primary goal: randomization. We develop this randomizer for free on our own time, and you play it for free on yours. The inevitable hot take that we don't know what we're doing is tiresome. Insulting us for remaining steadfast on our basic principles only cements us deeper, and, at worst, discourages us from continuing our contributions entirely. If a vanilla mechanic upsets you so much that you must berate us, perhaps you should fix it yourself and distribute a third-party application to patch existing games.

We are not here to make a perfect game.

The most common type of "fix this!" bug report is a kneejerk reaction to an inconvenience. This probably isn't pleasant to hear about your complaint, but it's the truth. And these reports likely arise due to the misconception that we are developing a game. We are not. Some of us may dabble or work in game development, but when we are working on the randomizer, we are hacking. We are not making a game; we are editing one. In the default case, we do not see bug versus mechanic; we see behavior. We make no judgement on the validity of a behavior, only that it exists. Glitch or not, behaviors being mildly unpleasant is never enough to be cause for removal.

Where do we even draw the line? Terrorpins have infamously bad AI. Is that a bug? Or is it just bad design? Agahnim's lightning barrier can be destroyed with the hammer if you've turned your sword in to the smiths. Yet we use this exact oversight as an intentional mechanic. Fake flippers is a glitch that many players use to their advantage. Should we patch that? Sure, everyone likes to use it for a sequence break, but it is objectively a problem with the game engine. This raises the question: What gives me, you, or anyone else the authority to decide whether to correct the original developers?

The answer for you to lament is that nothing does. Introducing these wildly subjective decisions is exactly why we proudly refer back to vanilla. Only when a change significantly improves the randomizer experience for everyone does it pass. Our best examples of such are ones you likely take for granted:

These are quintessential changes that improve not only the player's experience, but the randomness of the game itself. More random is good. If a change allows us to randomize more or better, then it's usually a change we want to make. That's what we're in the business of.

Being good at a game involves knowing what not to do just as much as what to do. The alternative to us changing established behaviors is that you learn a lesson and figure out or ask how to avoid the problem in the future. This isn't just some elitist take. The fact of the matter is that knowledge and practice improve performance. You are not entitled to an outstanding performance, and we are not obligated to help you achieve one. Once the game is randomized, our job is done. You, the player, bear the onus of playing well. When something goes wrong, sometimes it is our fault. We recognize issues with the hacks we add and the logic we apply, but we fix them as quickly as we can and use those mistakes to learn and improve. But when the underlying behavior is from the vanilla game, it's only fair to ask that you do the same.