Archipelago
Archipelago copied to clipboard
ArchipelagoMW
How can I integrate an existing randomizer?
I made a fork of the Super Metroid & A Link to the Past randomizer. It started out as a way to make a minor change but has grown into a separate, standalone randomizer, and now I'm curious to see how easily I could add Archipelago support to it.
The documentation for adding games mentions something about Python modules and stuff, but I already have a functioning randomizer. The README states “In all cases, presently, Archipelago is also the randomizer itself,” implying it's possible for this not to be the case.
Is this correct and, if so, what else would I need to do beyond implementing the network protocol?
The README states “In all cases, presently, Archipelago is also the randomizer itself,” implying it's possible for this not to be the case.
There is no such implication, Archipelago must be the one to place all items for all worlds otherwise there is no capacity to generate a logically functioning multiworld.
The only one that does something "alternative" is the FFR integration, which produces a YAML of locations for Archipelago to fill with items (but otherwise, AP still randomizes the item placements itself).
There is some documentation, albeit a bit dated/rusty, in the docs/ folder in the root of the repo. To implement a game into AP you would need to create a "World" for it in the worlds/ folder. This essentially functions as a Python package which contains the YAML options, fill logic, item and location definitions, and other necessary info for your game.
For what it's worth, we have an existing SMZ3 implementation based on tewtal/total's work: https://github.com/ArchipelagoMW/Archipelago/tree/main/worlds/smz3
We have an explicit agreement with tewtal that we will not implement features into the SMZ3 integration that are not present in their SMZ3 multiworld. (Other than those features inherent to AP and available to all games.)
Since your work appears to be full on derivative of their work and has existed separately for well over a year now, I do not [personally] believe the above applies to you [but I could be wrong].
You might want to refer to the existing SMZ3 world in worlds/ (as linked above) due to the similarities between your project and tewtal's.
For what it's worth, we have an existing SMZ3 implementation based on tewtal/total's work: https://github.com/ArchipelagoMW/Archipelago/tree/main/worlds/smz3 We have an explicit agreement with tewtal that we will not implement features into the SMZ3 integration that are not present in their SMZ3 multiworld. (Other than those features inherent to AP and available to all games.)
Due to this fact in particular, we'd really like to talk this out with you. Would you be willing to join our Discord server and chat with us? Alternatively, you can DM me ijwu#7209 if you prefer.
To clarify: we don't have multi-world support anymore as we diverged quite a bit. We did recently implement auto-tracking, so implemented some sort of multi-world support is no longer completely out of the picture.
I joined your Discord server, although @MattEqualsCoder did most of the work on implementing auto-tracking so you might have more luck talking to him if/when it comes to implementation.
The only one that does something "alternative" is the FFR integration, which produces a YAML of locations for Archipelago to fill with items (but otherwise, AP still randomizes the item placements itself).
Something along these lines could be acceptable. Our integrated item tracker is pretty tightly coupled to the randomizer, but we could probably add an option to accept a pre-generated list of items that Archipelago could generate, or something like that.
Something along these lines could be acceptable. Our integrated item tracker is pretty tightly coupled to the randomizer, but we could probably add an option to accept a pre-generated list of items that Archipelago could generate, or something like that.
This is not an uncommon approach. You can, during AP's fill/generation, emit a file for your particular world which can contain the item information for your program to work with AP.
So just want to confirm in regards to the FFR integration, you're saying it generates a YAML file with the locations (and items I'm guessing) for archipelago to use to generate the multiworld? Does that YAML file also somehow include the logic for said locations (assuming there even is much logic in FF1 - I haven't played it). And if so, does it account for different combinations of items that can be used to access a location?
FFR prefills some of its locations then outputs a YAML that tells AP what locations and items need to be placed and the logic to reach those locations and that then gets parsed by the FFR AP world. It's by far an outlier and 100% not the preferred method for integrating your randomizer though. You're far better off taking your logic and either exporting it into an easy to parse format to then pass into AP as a whole or creating a wrapper for it as AP being a multiworld randomizer has to be able to fill locations for the randomization logic to work.
So, I've started looking into various ways to do this, and I think I have been able to figure out a possible solution. However, before digging into it too much further, I wanted to run it by you all.
I've found a library which should allow us to automatically convert our C# code for our logic into python files. It's a bit fussy, and the generated python files aren't pretty, but it seems like it should be able to work. So while the core python files that would interact with archipelago would be hand written, the auto converted files could be regenerated each time we make an update to the logic and then pushed to you all to keep in sync. Obviously a delay in being integrated into archipelago has to be factored in, but we already for the most part avoid making behind the scenes logic changes without an opt-in flag.
The user could then go to a settings page on your end like most games to pick the logic settings that they want, then the generated executable for them would open up our SMZ3 application and allow them to do customizations like pick their Zelda/Samus sprites, pick an MSU, etc. before the rom is actually generated and they can start playing.
Does this seem like a viable solution to you all? Our integration will probably be pretty slow, and I'm sure I'll have lots of questions along the way, but I wanted to reach out before proceeding further with this idea.
Well... LTTP and Varia SM Rando logic both already exist in AP so you could import and use those at least. You can have AP output whatever file format you want so very likely you could output a file that will then open your existing application to do the patching then after that you can either do the networking from your client or preferably use SNIClient
The main issue is our logic has diverged a good amount and has a lot more customization to the logic, so the region files will have to be specific to ours. And, I'm wanting to make sure we don't have to manage the logic in two locations manually.
But I was planning on reviewing the others for how they determine what to return back to Archipelago.
