Tasks

Tasks to consider in later passes

These are tasks we might want to do at some point. They are written down here to make sure we don't forget about them until we decide whether (and how) to do them.

Junctions

Reorganize the nodes and logic to use junctions, assuming the idea is deemed usable

Normalize techs

Take a look at techs, add notes for them, and make sure they are used consistently in the logic across all regions

Handle resource costs

Find a way to add relevant information with regards to resource costs (most likely in health and power bombs) of different strats between nodes. Notable concerns for health:

• Heat run damage
• Shinespark damage
• Required damage off spikes
• Required damage boosts

Handle resource regen

For the logic to chain rooms together properly, our format should help it know where resources can be regained, making it possible to continue despite total needed resources being higher than the max.

Handle out-of-room requirements

Some things in a room are possible because of actions in another room, usually adjacent

• Gaining momentum and jumping through a door (e.g. invisible bridge)
• Being able to enter the room with a mockball of sufficient speed (e.g. ice escape)
• Gaining momentum and running through a door (to get a spark in the other room)
• Charging a spark and bringing it through a door (with x time remaining)
• Shinesparking through a door transition

This information could be represented in the format in some way.

Related to this, charging sparks might need a rework where we ditch the specific techs and instead just specify the number of tiles available to charge a spark. Options could then be used to know whether a spark should be expected by logic.

Add more basic techs to allow easier modes

Adding basic techs would give the option to programs reading our model to make their project accessible to a wider range of players. Techs that could be added to the logic:

• Easier wall jumps
• Crouch jumps
• Down grabs
• MidAir morphing

Note that when adding a basic tech that is assumed across the logic, it is important to also add all other alternate requirements that are not in logic because using basic tech there made them redundant.

Handling requirements to see an item without being able to get it

This has no value for actual logic, but would be very useful for a tracker type of program.

Defining the "Kill all enemies" format

We currently have different ways of handling doors that require killing enemies in a room. Of note:

• Kill all enemies is probably incorrect. Some rooms have more enemies than you need to kill, so we should probably do something {"killEnemies": 4} instead.
• A json definition of enemies is being worked on. This includes immunities and weaknesses. If we can figure out a way to place enemies properly in the rooms (accounting for access), then we probably won't need to define the actual requirements to kill those enemies in the room - it can be defined directly on the enemy.