Lufia II Ancient Cave: implement new game #1218
Conversation
| client_ap_items_found = int.from_bytes(tx_data[4:6], "little") | ||
|
|
||
| if client_items_sent < snes_items_sent: | ||
| location_id: int = locations_start_id + client_items_sent |
There was a problem hiding this comment.
Design question: Is the path to checks (blue chests) completely linear in the game, and you are forced to open each one before continuing?
If no, follow up question: am I reading correctly that two players who connect to the same slot and check completely different checks, will nonetheless find all the same checks?
Since this is a Roguelike, I should back up and clarify whether 2 people connecting to the same slot will have the same generated dungeon? Would that be desirable or not?
There was a problem hiding this comment.
The Chest number is based on the order you opened them in. Every time you open a chest, it is the next one in the sequence. When you die and start over, it continues counting from the last chest you opened.
2 players would not get the same dungeons, as the dungeons are randomized by the game.
I believe keeping track of your chest number is tied to your save file (the SNES SRAM), so 2 players connecting to the same world would be overlapping their chests, rather than new ones. Co-op does not seem designed for this game.
There was a problem hiding this comment.
Blue chests are fungible. The first blue chest that you open will be reported as the check "Blue chest 1", even if you encountered a bunch of other blue chests before that (but didn't open them).
If two people connect to the same slot, with personA opening four chests and personB opening a single one, the checked locations on the server should then be "Blue chest 1" to "Blue chest 4", but not "Blue chest 5".
So while you should be able to connect to the same slot and play like that, the total recorded progress will be equal to the farthest progress that one of the individuals has achieved; the checks of the participants don't get added together.
Two people running the same ROM will encounter different floor layouts, even on their first run (unless they are manipulating the RNG).
Every time a player starts over (be it after death, reset, or intentionally escaping the dungeon by using the item "Providence") they will discover a different first floor. Floors are generated randomly when they are entered, i.e., if you made a savestate while on floor B5 and then repeatedly reloaded it, you could see different layouts on floor B6 (depending on the RNG-affecting actions before going down the stairs and the frame count).
There seem to be projects that strive to "derandomize" the cave and force a fixed floor layout every time the cave is entered on the same ROM, so I guess it must be desirable for some. But this is not how the vanilla game or this AP implementation works as of now.
There was a problem hiding this comment.
If two people connect to the same slot, with personA opening four chests and personB opening a single one, the checked locations on the server should then be "Blue chest 1" to "Blue chest 4", but not "Blue chest 5".
Out of curiosity, is this an intentional design decision? I could see some players being interested in being able to co-op a seed (two players playing the same slot). Especially since, as I understand it, some of Lufia's goals/options can be quite long. Being able to co-op a slot would make that more "sync-viable".
There was a problem hiding this comment.
If two people connect to the same slot, with personA opening four chests and personB opening a single one, the checked locations on the server should then be "Blue chest 1" to "Blue chest 4", but not "Blue chest 5".
Out of curiosity, is this an intentional design decision? I could see some players being interested in being able to co-op a seed (two players playing the same slot). Especially since, as I understand it, some of Lufia's goals/options can be quite long. Being able to co-op a slot would make that more "sync-viable".
There is only one mode that can be shortened by co-op-ing the game and that would be Iris Treasure Hunt. Iris Treasures are red chest items, and therefore the blue chest count or content is irrelevant for this mode. The issue I see with co-op-ing that mode is that I am not sure how Iris Treasures are handled. @el-u will have more insight here...
There was a problem hiding this comment.
Out of curiosity, is this an intentional design decision? I could see some players being interested in being able to co-op a seed (two players playing the same slot). Especially since, as I understand it, some of Lufia's goals/options can be quite long. Being able to co-op a slot would make that more "sync-viable".
It is intentional in the sense that I didn't know how I could have made it work properly with coop. The way I keep track of them in the game, blue chests are indistinguishable. E.g., the game only knows that 4 chests have been opened, in the client, I translate that to "Blue chest 1" to "Blue chest 4", and that is reported to the server.
I have thought about this before, and what one could do is have the client constantly get the total number of checked locations from the server and then, if it is larger than the number of chests currently opened in the game (e.g., if another person has opened a chest), the client writes that increased number back to the savefile. But that opens the door to double counting chests in solo play, which sounds worse to me than not being optimal for coop. (As an extreme example: Someone repeatedly loading a savestate and opening the same chest over and over again could clear out a whole seed in just a minute.)
There is only one mode that can be shortened by co-op-ing the game and that would be Iris Treasure Hunt. Iris Treasures are red chest items, and therefore the blue chest count or content is irrelevant for this mode. The issue I see with co-op-ing that mode is that I am not sure how Iris Treasures are handled. @el-u will have more insight here...
No co-op. Collecting and counting Iris treasures happens completely locally on the game side.
As far as the server or client are concerned they do not even exist as items.
There was a problem hiding this comment.
The bit about reloading save states is a valid concern. I'm not particularly familiar with the game itself; I imagine that there could be some logic in the client to detect that behavior, but that's not a priority for initial release. That's something you can look into post-release.
ThePhar
added
the
is: new game
basepatch: - support non-Windows OS - gitignore all asar files - document expected data bank values - make AP initialization more reliable locations: - simplify location mapping - remove unused location IDs options: - replace capsule_monsters_available/party_members_available choices by shuffle_capsule_monsters/shuffle_party_members toggles - convert methods to properties world: - remove unused code - add event for Final Floor - update required_client_version, remove required_server_version
|
The ROM area which I had reviewed looks great with the latest updates. Any remaining disagreements there are largely stylistic and can be forgotten. So please consider all my ROM and doc comments resolved. Thank you!! |
el-u
requested review from
Alchav and
alwaysintreble
and removed request for
Alchav
| @@ -190,6 +193,11 @@ Root: HKCR; Subkey: "{#MyAppName}soepatch"; ValueData: "Arch | |||
| Root: HKCR; Subkey: "{#MyAppName}soepatch\DefaultIcon"; ValueData: "{app}\ArchipelagoSNIClient.exe,0"; ValueType: string; ValueName: ""; Components: client/sni | |||
| Root: HKCR; Subkey: "{#MyAppName}soepatch\shell\open\command"; ValueData: """{app}\ArchipelagoSNIClient.exe"" ""%1"""; ValueType: string; ValueName: ""; Components: client/sni | |||
|
|
|||
| Root: HKCR; Subkey: ".apl2ac"; ValueData: "{#MyAppName}l2acpatch"; Flags: uninsdeletevalue; ValueType: string; ValueName: ""; Components: client/sni | |||
There was a problem hiding this comment.
I'd prefer to have #1262 merged first, to make this section obsolete.
There was a problem hiding this comment.
Certainly.
Will update if it is merged.
|
Default host.yaml options (currently) need to also be added to get_default_options() in Utils.py |
done |
|
In addition to implementing ThePhars review I have also pushed a small commit that makes this worlds typing compatible with the changes brought by ae30b09. |
|
Updated this worlds tests to be compatible with the changes brought by 2dcfbff. |
|
Certainly looks to be working |
|
@ThePhar around to finish your requested review? |
Co-authored-by: wordfcuk <[email protected]>
What is this fixing or adding?
Adds a new game: "Lufia II: Rise of the Sinistrals" (SNES)
This implementation focuses solely on the Ancient Cave (gift mode); it does not cover the story mode.
Required ROM dump:
File name: "Lufia II - Rise of the Sinistrals (USA).sfc"
MD5 hash: 6efc477d6203ed2b3b9133c1cd9e9c5d
Size: 2621440 B
World implementation by el_ [@el-u]
Documentation, installer, setup guide, and testing by Ludwig Futureman [@wordfcuk]
How was this tested?
Public sync and async games.
If this makes graphical changes, please attach screenshots.