github/Shipwright
1
0
Fork 0
mirror of https://github.com/HarbourMasters/Shipwright.git synced 2025-08-14 02:27:21 -07:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

Updated Home (markdown)

Malkierian 2023-09-13 21:10:02 -07:00
commit c557beef72
1 changed files with 21 additions and 42 deletions
Download patch file Download diff file Expand all files Collapse all files

63
Home.md

@ -1,14 +1,26 @@
## Rando v2
### Check Data conversion
* merchantPrices, itemLocations unified into current CheckTrackerData structure, to be renamed to CheckData
# Wishes v3/v4/etc
### Convert 3DS rando to utilize SoH data structures (gSaveContext)
* options
* inventory
* check data
* end goal being live-playthrough instance is plug and play with generation playthrough structures, for easy availability checking
## 1. Source Interaction
What this might look like in practice
- Different approach for giving items, one that can be used for all (most?) checks - rando changes branch is the proof of concept for this
- 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?)
## 2. Data Optimization/Unification
- 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)
- 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.
- 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)
- What this might look like in practice
```c
RandomizerCheck rc = Randomizer_GetRandomizerCheckFromActor(this->actor.params, play->sceneId);
@ -25,20 +37,6 @@ What this might look like in practice
}
```
### Name parity with Archipelago
This would mean renaming the check names internally, ala the `rcSpoilerName` "ToT Light Arrow Cutscene" in our code becoming "ToT Light Arrows Cutscene". We can keep the `rcShortName` value for all these changes whatever we decide we want, whether that's how they are now or matching the spoiler name.
### Come up with a cleaner and more consistent way of branching from vanilla code
### Extensible language support system
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.
# 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
https://github.com/leggettc18/Shipwright/commits/rando-refactor-dedup
## 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).
@ -83,12 +81,6 @@ Rewrite logic to work based on a "room by room" basis with clear indications as
- Why are gossip stones considered checks in some contexts?
- Dynamic hint - dynamically finds a woth item within reach
## 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
- 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?)
## Developer Experience
- json junk hints (possibly loaded from soh.otr during seed gen?)
@ -99,19 +91,6 @@ Rewrite logic to work based on a "room by room" basis with clear indications as
- Messages expanded to support 4 languages (japanese)
- Auto line break based on length
## 2. Data Optimization/Unification
- 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)