github/Shipwright
1
0
Fork 0
mirror of https://github.com/HarbourMasters/Shipwright.git synced 2025-07-06 04:51:30 -07:00
Code Issues Projects Releases Packages Wiki Activity Actions

Updated Home (markdown)

Malkierian 2023-09-13 18:57:57 -07:00
parent 1455fdf363
commit 9ea4ce0edd
1 changed files with 83 additions and 63 deletions
Download patch file Download diff file Expand all files Collapse all files

146
Home.md

@ -34,69 +34,89 @@ This would mean renaming the check names internally, ala the `rcSpoilerName` "To
3DS Rando doesn't support German at the moment, and with PAL ROM support done, NTSC and the eventual Japanese translation will be next.<br> 3DS Rando doesn't support German at the moment, and with PAL ROM support done, NTSC and the eventual Japanese translation will be next.<br>
Also, we should be able to make it so that the hints and such can be created on file create, or even on the fly, instead of relying on hint text in the spoiler, that way people who share spoilers across primary languages can still get the rando texts in their language. Also, we should be able to make it so that the hints and such can be created on file create, or even on the fly, instead of relying on hint text in the spoiler, that way people who share spoilers across primary languages can still get the rando texts in their language.
Wishes v3/v4/etc # Wishes v3/v4/etc
Figure out the state of leggett’s rework. split it up and/pick someone to get that across the finish line - Figure out the state of leggett's rework. split it up and/pick someone to get that across the finish line
https://github.com/leggettc18/Shipwright/commits/rando-refactor-dedup https://github.com/leggettc18/Shipwright/commits/rando-refactor-dedup
## Logic
Logic Rewrite logic to work based on a "room by room" basis with clear indications as to what is needed to beat the room. E.g. rooms which need certain enemies defeated to progress will have Can\_Defeat(ENEMY\_STALFOS, numEnemies).
Rewrite logic to work based on a “room by room” basis with clear indications as to what is needed to beat the room. E.g. rooms which need certain enemies defeated to progress will have Can_Defeat(ENEMY_STALFOS, numEnemies).
General Rework: ### General Rework:
Currently certain sections of dungeons, particularly in Master Quest, will have logic which assumes you already have certain items or are adult/child at that point in the dungeon and will not include logical conditions for these items anymore (already currently an issue in fire temple with trick logic)
Logical item conditions will often not use the CanUse() in cases where it should, or does but is not clear that IsAdult or IsChild is a necessary condition but is implied through the item conditions use - Currently certain sections of dungeons, particularly in Master Quest, will have logic which assumes you already have certain items or are adult/child at that point in the dungeon and will not include logical conditions for these items anymore (already currently an issue in fire temple with trick logic)
This is absolutely necessary for the introduction of glitch logic - Logical item conditions will often not use the CanUse() in cases where it should, or does but is not clear that IsAdult or IsChild is a necessary condition but is implied through the item conditions use
This is also necessary to allow for inclusion of timeless equipments, but also for the significant rework that more easily implementing equip swap would require - This is absolutely necessary for the introduction of glitch logic
Ice traps -> traps - This is also necessary to allow for inclusion of timeless equipments, but also for the significant rework that more easily implementing equip swap would require
Support latest DJ formats for sequences (i think they allow custom samples now?) - Ice traps -\> traps
Playthrough Rework - Support latest DJ formats for sequences (i think they allow custom samples now?)
Refactor rando code to align with n64 code patterns/structures (not features)
One example is playthrough calculation/multiworld considerations so that things like Archipelago or multi-world are easier/free thanks to n64 kicking things off ### Playthrough Rework
Built-in multi-playthrough logic support (multi world)
Enemy Defeating Rework: - Refactor rando code to align with n64 code patterns/structures (not features)
This is not necessary for glitch logic - One example is playthrough calculation/multiworld considerations so that things like Archipelago or multi-world are easier/free thanks to n64 kicking things off
Currently the code is very inconsistent as to the clear conditions for rooms based on what enemies are in them, and often this makes it very difficult to understand the logic as well as know what to write for certain sections - Built-in multi-playthrough logic support (multi world)
The aim here is to standardise the conditions for beating a room and make clear when certain oddities arise e.g. fire temple bk loop has a chest requiring adult but is not made clear by the code as only adult is expected to beat the flare dancer in other sections of the code.
My personal hope for this is to potentially help a future for seeded enemy rando logic ### Enemy Defeating Rework:
Eventual Glitch Logic:
Currently have notes up to fire temple but holding off until the general rework is implemented - This is not necessary for glitch logic
V1 glitch logic aims to include all major glitches excluding wrong warping/void warping/text transfer glitch/item manipulation/srm etc. - Currently the code is very inconsistent as to the clear conditions for rooms based on what enemies are in them, and often this makes it very difficult to understand the logic as well as know what to write for certain sections
Unlike the current n64 glitch logic (which is currently undergoing a rework) individual glitches will be toggleable with difficulty tags for each, as is done in trick logic currently - The aim here is to standardise the conditions for beating a room and make clear when certain oddities arise e.g. fire temple bk loop has a chest requiring adult but is not made clear by the code as only adult is expected to beat the flare dancer in other sections of the code.
V2 would aim to have closed/challenge option where woth items are delayed in the playthrough - My personal hope for this is to potentially help a future for seeded enemy rando logic
General Gameplay
Don’t start twinrova flight until we get into the room ([GH issue](https://github.com/HarbourMasters/Shipwright/issues/707)) ### **Eventual Glitch Logic:**
Allow dpad boots in all situations ([GH issue](https://github.com/HarbourMasters/Shipwright/issues/623))
Hints - Currently have notes up to fire temple but holding off until the general rework is implemented
Hint distribution/options parity with zootr (I’m not super familiar with this, but people always complain “our hints arent like zootrs”) (something to consider is Peperoni is trying to do something around this) - V1 glitch logic aims to include all major glitches excluding wrong warping/void warping/text transfer glitch/item manipulation/srm etc.
Why are gossip stones considered checks in some contexts? - Unlike the current n64 glitch logic (which is currently undergoing a rework) individual glitches will be toggleable with difficulty tags for each, as is done in trick logic currently
Dynamic hint - dynamically finds a woth item within reach - V2 would aim to have closed/challenge option where woth items are delayed in the playthrough
1. Source Interaction
Different approach for giving items, one that can be used for all (most?) checks - rando changes branch is the proof of concept for this ## General Gameplay
Piggy-backing on the above ^ attempt to be less invasive on vanilla code paths in every way possible
^ Also a piggy back. Cleaner ways to hook/replace original code functions for rando code paths (less in line changes, and more of a patch/redirect to handle the rando ideas) (ala 3ds rando patch system maybe?) - Don't start twinrova flight until we get into the room ([GH issue](https://github.com/HarbourMasters/Shipwright/issues/707))
Developer Experience - Allow dpad boots in all situations ([GH issue](https://github.com/HarbourMasters/Shipwright/issues/623))
json junk hints (possibly loaded from soh.otr during seed gen?)
Text box custom syntax ([GH issue](https://github.com/HarbourMasters/Shipwright/issues/1002)) ## Hints
Logic testing framework? (n64 does snapshot testing for example)
Improvements to custom message system: - Hint distribution/options parity with zootr (I'm not super familiar with this, but people always complain "our hints arent like zootrs") (something to consider is Peperoni is trying to do something around this)
Most messages should be created on the fly (also means not adding them to the spoiler - Malk) - Why are gossip stones considered checks in some contexts?
Messages expanded to support 4 languages (japanese) - Dynamic hint - dynamically finds a woth item within reach
Auto line break based on length
2. Data Optimization/Unification ## 1. Source Interaction
Unify all randomizer data structures under one umbrella (ala CheckTrackerData to CheckData)
De-duplication - Creating a new option, check, item, etc should be as seamless as possible, I should only need to define things in one centralized place, one time - Different approach for giving items, one that can be used for all (most?) checks - rando changes branch is the proof of concept for this
Do we really need extendedVanillaGetItemTable? I get how those items are different, but is there any benefit to doing what we do now instead of them all just having a custom item entry in the randomizer table? - Piggy-backing on the above ^ attempt to be less invasive on vanilla code paths in every way possible
Internals of randomizer playthrough utilize gSaveContext to simulate game playthrough (this will have benefits post-generation, and simplify some of our code, i think) - ^ Also a piggy back. Cleaner ways to hook/replace original code functions for rando code paths (less in line changes, and more of a patch/redirect to handle the rando ideas) (ala 3ds rando patch system maybe?)
Convert rando code to utilize SoH data structures (target: live playthrough for check availability)
Extensible language support (more than just “OoT” languages) ## Developer Experience
Spoiler file generation becomes optional
Spoiler file settings section 1:1 with randomizer setting cvars - json junk hints (possibly loaded from soh.otr during seed gen?)
Change spoiler logs to have both human friendly data, and computer friendly data, so we don't have to worry about doing parsing. Or at least have the "strings" be defined once so that typos aren't possible between parsing and spoiler log generation. - Text box custom syntax ([GH issue](https://github.com/HarbourMasters/Shipwright/issues/1002))
Name parity with Archipelago (for spoiler file loading) - Logic testing framework? (n64 does snapshot testing for example)
UI/Menu Interaction - Improvements to custom message system:
Move/refactor settings collision logic/setting group randomization to one place (think of indicating in the UI that a setting can't be toggled, but also the logic doing that for us. Currently 3ds does some safeguards for example) - Most messages should be created on the fly (also means not adding them to the spoiler - Malk)
Randomizer settings UI is data driven (title, description, and combobox options come from tables, not hardcoded) - Messages expanded to support 4 languages (japanese)
Graceful handling of seed generation errors (ideally with useful error messages to help people adjust settings so it won’t fail next time) - Auto line break based on length
Possible stretch goal: have pre-generation validation of settings?
MUCH better error handling and messaging around seed generation and failure ## 2. Data Optimization/Unification
Full starting inventory options ([GH issue](https://github.com/HarbourMasters/Shipwright/issues/726))
- Unify all randomizer data structures under one umbrella (ala CheckTrackerData to CheckData)
- De-duplication - Creating a new option, check, item, etc should be as seamless as possible, I should only need to define things in one centralized place, one time
- Do we really need extendedVanillaGetItemTable? I get how those items are different, but is there any benefit to doing what we do now instead of them all just having a custom item entry in the randomizer table?
- Internals of randomizer playthrough utilize gSaveContext to simulate game playthrough (this will have benefits post-generation, and simplify some of our code, i think)
- Convert rando code to utilize SoH data structures (target: live playthrough for check availability)
- Extensible language support (more than just "OoT" languages)
- Spoiler file generation becomes optional
- Spoiler file settings section 1:1 with randomizer setting cvars
- Change spoiler logs to have both human friendly data, and computer friendly data, so we don't have to worry about doing parsing. Or at least have the "strings" be defined once so that typos aren't possible between parsing and spoiler log generation.
- Name parity with Archipelago (for spoiler file loading)
# UI/Menu Interaction
- Move/refactor settings collision logic/setting group randomization to one place (think of indicating in the UI that a setting can't be toggled, but also the logic doing that for us. Currently 3ds does some safeguards for example)
- Randomizer settings UI is data driven (title, description, and combobox options come from tables, not hardcoded)
- Graceful handling of seed generation errors (ideally with useful error messages to help people adjust settings so it won't fail next time)
- Possible stretch goal: have pre-generation validation of settings?
- MUCH better error handling and messaging around seed generation and failure
- Full starting inventory options ([GH issue](https://github.com/HarbourMasters/Shipwright/issues/726))