Skip to content

Instantly share code, notes, and snippets.

@toasterparty
Last active April 24, 2024 18:52
Show Gist options
  • Save toasterparty/65311bb8344c92176295f77b445d591d to your computer and use it in GitHub Desktop.
Save toasterparty/65311bb8344c92176295f77b445d591d to your computer and use it in GitHub Desktop.

Toaster's Metroid Prime Romhacking Wisdom

Knowledge is knowing a tomato is a fruit. Wisdom is not putting it in a fruit salad Plasma Processing.

This is a dump of my thoughts after spending upwards of 5 months on the Metroid Fool romhack. Coming out of that experience, I've learned several lessons I wish I had known going into this process. Hopefully this helps others seeking to make similar hacks avoid design mistakes - even if this advice is coming from someone whose total romhacking experience is microscopic compared to members of certain 2D game communities. This advice is intended for any Metroid Prime romhacker who intends to increase the difficulty of the base game, however, you could also argue a lot of this is just good game design (in which case you'd be better off reading a book).

All examples used in this guide are fabricated as to not spoil the contents of Metroid Fool.

Lesson 1

Romhacking for a 3D metroidvania game is fundamentally different to other more linear games such that the author is responsible for carefully curating an acceptable level of "feeling lost". In a traditional linear hack the direction of progress is always known (e.g. towards the right of the screen) - but with a game like Metroid Prime, figuring out which direction you need to travel can become part of the substance of the hack. This discrepancy should not be ignored and is where we find our first lesson:

Progression items can either be obscure to find or obscure to use, but never both.

This rule is important because players ultimately can never know what the real "intended" item progression order is for a romhack while they are still inside it. All they can understand is one of the following insights about their current game state:

  • The world has a requirement which I do not have the corresponding item for and thus must seek out that item
  • I have an item which I have not used and must seek out the requirement where it is useful

The 2nd state is distinctly different from a randomizer run where any experienced player has perfect knowledge of all requirements in the game before they even start. In a romhack, a player who doesn't know what item they need in addition to not knowing where to find it is utterly lost. They don't have any context clues as to where they should be searching, and if they manage to find the progression item anyways, they are not garunteed to correctly assume it is the "next" item in the progression chain as the blocking requirement is not immediately obvious.

Here are some examples on how to ensure the player has at least half of this two-piece puzzle:

  • BAD: Wave Beam is hidden inside a crate at the top of Ruined Courtyard and it is used to activate a secret Power Conduit in Chozo Ruins.
  • GOOD: Wave Beam is hidden inside a crate at the top of Ruined Courtyard and it is used to open a Purple Door in Chozo Ruins.
  • BAD: Super Missiles are hidden in the part of Energy Core no one ever goes in and they are needed to defeat hive totem because of a custom vulnerability
  • GOOD: Super Missiles are easily seen in Energy Core (but not necessarily trivially obtained) and they are needed to defeat hive totem because of a custom vulnerability

A good rule of thumb is your player should always be able to answer one of two questions:

  • What item do you need?
  • What item are you trying to use?

Of course, you can still use the engine to make a great linear hack. If you make this design decision, make it unwaveringly so. Never allow your player to do any two things out of order else they may doubt the linearity of the hack.

Lesson 2

Understand what is frustrating and minimize that instead of difficulty

It's deceptively easy to make something difficult in a romhack. The artistry comes in making it right kind of difficult. A good starting place is to reduce frustrating elements as much as possible. The following things increase frustration (roughly sorted in descending order):

  • Softlock
  • Death
  • Feeling lost
  • Backtrack
  • Repetition
  • Bug
  • "Jank"

This list is pretty intuitive on it's own. However, what I didn't understand until recently is that when these frustrating elements interact they don't do additively, they do so multiplicatively. Additionally, softlocks and deaths are exponentially more frustrating the further the player is from their last save.

Let's consider an example. Say we added a grapple point in Metroid Quarantine A and we design the room to require this grapple point to traverse in either direction. Consider vanilla save station locations for this example. Here are different ways in which frustration can be felt in MQA:

  • Slight Inconvenience: Failing the grapple a couple of times while progressing into lower mines for the first time
    • Repetition
  • Mild Annoyance: Failing the grapple a couple of times while progressing into lower mines because the grapple beam is severed due to swinging through a small amount of collision
    • Jank x Repetition
  • Certifiably frustrating: Failing the grapple once due to the beam breaking while backtracking out of lower mines because X-Ray Visor is required to progress further
    • Jank x Backtracking
  • Infuriating: Failing the grapple once while backtracking because of grapple beam jank and dying in the Phazon
    • Jank x Backtracking x Death
  • Rage Quit: Dying multiple times while attempting to backtrack out but the player isn't even sure if this is the correct direction to be heading
    • Repetition x Backtracking x Death x Feeling Lost

Notice how this room can result in the entire range of frustration despite the difficulty remaining unchanged. The context in which the room is being experienced is everything. If you have a section like this in your game, consider all contexts the player might encounter and what it would feel like to be in each of those. Consider every permutation of routing and take measures to mitigate the most "frustrating" ones. In our example, you could:

  • Fix the grapple beam jank so failure isn't frequently unexpected
  • Reduce the risk of death upon failure
  • Eliminate the need to backtrack
  • Communicate the intended path better (Lesson 1)

Lesson 3

Save Stations need to be unmissable

This is especially important when making romhacks with open-ended routing. The player might only be a few rooms away from a Save Station, but if they choose to take a diverging path away from the Save Station, they might stray into unexpectedly difficult sections without a nearby save. Some general suggestions regarding Save Stations include:

  • Take extreme care to never allow the player to access a Save Station through a point-of-no-return (unless that is the intended progression path and the player is guaranteed to have enough upgrades/missiles/energy)
  • Placement of "extra" Save Stations should be both obvious and consistent
  • All branching paths with the potential to lead to death should lead to a Save Station first
  • Never put traps in Save Station rooms
  • Consider placing Save Stations after difficult sections, not just before. You never know when a player wants to be done for the day

Lesson 4

The player must be able to observe difficult sections

In a 2D game, puzzles are presented on the screen in their entirety. The beginning and end can be seen as clearly as the player sprite.

In a 3D game, the author must explicitly create vantage points which the player can use to survey any given puzzle. Here are some tips to achieve this:

  • Be mindful of what vantage angles the player has access to for viewing the section
  • Be mindful to not punish the player with damage for taking time to observe the puzzle
  • For sections with timed platforming, make sure the player has spots where they can rest and observe before proceeding
  • Be careful when using foggy and dark rooms

You can, of course, create blind puzzles and platforming sections. Just make sure to adjust the difficulty to accommodate and test with people who aren't spoiled on the layout.

Lesson 5

Include "skill checks" prior to long/difficult sections

For example, don't put the first required BSJ of the hack inside a hell-run. If you want to have a BSJ in a hell-run, modify an earlier room in the game to require a BSJ with no additional pressure. Some tricks are on a sliding scale of difficulty such as R-Jumps. If you have a particularly difficult R-Jump during a section with lots of pressure (e.g. falling down a tall room), then you should have an equally difficult R-Jump prior to that section.

Depending on the intended difficulty of your hack and the target audience, you should consider front-loading the early-game of your hack with these skill checks. It's better that you loose the players below the target audience's skillset at the very beginning instead of after they've gotten heavily invested.

Lesson 6

The player's tolerance for obscurity is inversely proportional to how much of the game they have access to

Imagine a room with an invincible pirate and metroid. The only way to progress through the room is to kite both enemies towards each other until the metroid kills the pirate which drops the next progression item.

Now imagine the player encounters this room, sees that the enemies are not taking damage, and incorrectly concludes that a beam combo is required to kill the enemies. The player then leaves this room to retread through 4 entire regions looking for something they might have missed. This would be incredibly frustrating and un-fun. Players might even quit from experiences as negative as this.

With an extremely minor tweak, we can prevent this frustration entirely. Imagine the doors lock as soon as the player steps inside the room. This clearly communicates to the player "This is a puzzle and all of it's pieces are confined to this single room". This is much more manageable than the potential provided by standard late-game. Alternatively, you could require that reward item to do any backtracking out of the current region thus limiting the scope of the puzzle to only a handful of rooms in that region.

This also means that you can get away with more obscure puzzles when the player only has access to 1-2 areas such as early Tallon/Chozo.

Lesson 7

Remember that players can run out of missiles in any room

This situation can range from inconvenient to infuriating softlock. Make sure to give the player access to re-loadable missile-dropping crates wherever possible. Removing the missile locks off of vanilla Save Stations is always a good idea for this reason.

Lesson 8

Not all cheese is equal

Cheese - An unintended method of getting through a part of a level, not including getting items out of the intended order (that's sequence breaking)

Metroid Prime's movement system is a beautiful sandbox - especially when you consider all of the techniques held in the speedrunning/randomizer consciousness. For example, what you may have designed as a series of difficult L-Jumps could be partially or wholly circumvented using a dash, BJS, wallboost, damage boost, reposition, etc...

As you and your playtesters explore your rooms, you will find yourself tempted to throw band-aids at everything that isn't your intended route. I implore you to pause before you do that and consider how multiple methods of traversing a room can create gameplay depth. Here are some things to consider:

  • Is the cheese easier/faster than what you intended? If not, why should you care?
  • Is the cheese only possible on later passes through that room with additional inventory? If so, consider leaning into it and telegraphing it more. You can even intentionally add cheese to your rooms to give players a dopamine hit for thinking out of the box and exercising more advanced techniques
  • How janky/punishing is your anti-cheese? A cheap invisible barrier can leave a bad feeling compared to some more intuitively readable geometry
  • Is the cheese only something that would make sense on 2nd playthroughs? If so, why care? 2nd paythroughs will find cheese no matter how diligent you are in your design.

Lesson 9

Beware of the Hell-Run Paradox

When you are designing a hell-run into for your romhack, you are balancing the player's ability to move through rooms quickly against the amount of Energy they have accessible to them. This leaves you with the decision of how you want to place your Energy Tanks leading up to this hell-run.

Due to how complex movement is in this game, hell-runs will always have a wide range of how much time they can be completed in and thus how many Energy Tanks are required. You can place your Energy Tanks as trivially collectable rewards in-between major upgrades (e.g. the Energy Tank after Hive Totem in vanilla), but you may also choose to have some number of "optional" Energy Tanks locked by advanced tricks. If you choose to require difficult tricks to acquire these "optional" Energy Tanks, you expose yourself to the paradox:

Players who are most adept at collecting your optional Energy Tanks need them the least. Conversely, players who need the extra Energy Tanks will have the most trouble collecting them.

If you aren't careful, this can create a reverse pendulum effect situation where some players don't feel any pressure from your hell-run while others are infuriated by it. This is especially true if those extra Energy Tanks require significant backtracking from where the hell-run starts.

Here are some measures you can take to avoid this issue:

  • Make your hell-run shorter thus limiting the difference in minimum required Energy between players of differing skill level
  • Limit the number of "optional" Energy Tanks, and keep them close to the start of the hell-run
  • Make your "optional" Energy Tanks require more than just difficult movement to reach. The best Energy Tank locations require puzzle-solving skills, critical thinking, etc... Save the advanced tech for hard-to-reach missile expansions
  • Make Energy Tanks require coming back to a room with additional upgrades and don't allow expert players to collect them early (do allow expert players to collect missile expansions early, however)

Lesson 10

Gamers don't read

The only way to guarantee someone scans something is to make them see the scan terminal actor in Combat Visor, or lock them in a small room until they scan it. If you don't do this, you must assume the player has not read your scan text. You can even instruct the player to use scan in the README file, but you can't even assume people will read that either. You can replace vanilla scan text on frequently scanned terminals and players still might not notice your modified text.

Also, give players extra time to read custom hudmemos and avoid showing custom hudmemos while other gameplay events are occuring. For example, a pickup which activates custom scripting during a heat-run should ideally do so with a modal hudmemo.

Lesson 11

Playtest until you are numb

For ever room you make:

  • Playtest starting in that room with savestates
  • Playtest starting in that room without savestates
  • Playtest starting from the Save Station prior to that room
  • Playtest with all possible inventory states for that room
  • Playtest in all possible layers of that room
  • Playtest with a player that is not you

And always take notes as you do. You will not remember everything afterwards.

Finally, be sure to playtest at least once from the start of the game, without savestates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment