Adventure: implement new game #1531
Conversation
black-sliver
added
the
is: new game
| self.create_event("Victory", ItemClassification.progression)) | ||
| self.multiworld.completion_condition[self.player] = lambda state: state.has("Victory", self.player) | ||
|
|
||
| def pre_fill(self): |
There was a problem hiding this comment.
If I'm understanding right, you're creating additional locations and items, then later remove them again? Why not just select a random set of locations and only create those?
There was a problem hiding this comment.
I'm not removing any locations. I'm removing those 'nothing' items from the pool when I place them, but they probably don't need to be in the pool in the first place.
I thought I'd have problems with those unused locations either not showing in the tracker or being unable to 'check' them for the tracker. And also I believe I need to make sure any locations that are plando'd exist, but I guess there's probably some way for me to get a list of those. I'm placing items in those locations and removing those items from the pool, but I'll see what it looks like if I leave out those locations. Or if that does have a problem, not creating the 'nothing' items in create_items and adding them to the pool and taking them back out later, just creating them as needed.
Is removing items from the pool the slow part? I don't want to slow down large multiworlds.
The largest one I tested was 2600 worlds and iirc took about 5 minutes, but that was almost all Adventure and the total location count was only in the tens of thousands, not like a real big async. I'll note down the generation times as I try out these changes to make sure I don't make something awful.
That nothing item, if I keep it, can also be set up more consistently with the other extra filler items now, and I should go ahead and do that.
There was a problem hiding this comment.
Basically, as expected, they don't show up in the tracker if I don't create them. Not generating those locations with random filler limits cuts total generation time to 70% of the original handling, and using all locations but skipping the item pool for any nothings reduces it to 90%. That's with random amounts of filler; it is probably more typical for all locations to have a real item anyway, as that's the default setting. There's just an option for limiting the number of freeincarnates that normally take up any extra slots, and if it runs out of those it uses 'nothing'.
There was a problem hiding this comment.
This is enough of a change I want to spend more time testing than I have right now, so I'll push this another day. I'm having trouble staying awake now.
There was a problem hiding this comment.
I suppose I should also try letting AP handle it normally with those items set to local.
Edit: That's much slower.
There was a problem hiding this comment.
It's rare for games to have this problem in the first place, generally players will prefer any trash item whatsoever over an actual nothing item. But in the cases where it can exist, mostly this is Super Metroid, they are actual Nothing items that as far as AP is concerned is just a regular item.
There was a problem hiding this comment.
As far as AP is concerned, they are Nothing items (ID 118000000) placed locally.
In Adventure, the built-in randomizer (level 3) has a lot more locations than vanilla items, so there are many empty rooms. I want that to still be an option, without revealing what rooms are populated in the tracker, but still marking those as checked when they are seen. In order to make it tracker-friendly, it adds 'Nothing' AP items to some locations which get checked when seen by the client.
The default yaml settings do generate a non-Nothing item for every location, but that changes the feel of exploring some, so I didn't want to enforce that as the way things have to be.
worlds/adventure/__init__.py
Outdated
| locations_copy.remove(loc) | ||
| if loc in overworld_locations_copy: | ||
| overworld_locations_copy.remove(loc) | ||
| self.multiworld.itempool.remove(item) |
There was a problem hiding this comment.
in large multiworlds, this is a very slow operation
There was a problem hiding this comment.
Well, I'm not adding or removing those from the itempool anymore. I think the player experience of not generating the locations is worse, so I'd rather not do that, but if that's the preferred AP way to do it, I can change back over and look into how to make sure I create any locations specified in plandos.
Could you let me know? Thanks.
|
|
Insert AP foreign item data into client zip archive
Everything connects, and the connector successfully handles placing and collecting foreign items, but actually sending those to the client and server isn't working yet, and receiving items from other games probably doesn't work
…agon Still need to mark local items collected when touched Still need to implement deathlink And options. And bat logic. And docs. And tests.
Fixed empty location collection
Add on-screen received messages, Small options update
…buggy, possibly due to bat. Have good test case in current game.
items is optional
Correct a few style errors
castle the player starts at
generate the patched rom with a .a26 extension instead of .bin.
…xtra setup steps anymore.
Co-authored-by: Fabian Dill <Berserker66@users.noreply.github.com>
Co-authored-by: Fabian Dill <Berserker66@users.noreply.github.com>
Fix tutorial author.
with 'nothing' when we have nothings. Make sure there's at least one hard location left, and leave additional overworld locations empty when there are very few items.
and just random fill with nothings if we do. That should only happen with plando, exclude, or priority settings which may not guarantee successful generation.
This reverts commit 9ce8811.
…different. Put the Adventure client launcher component into AdventureClient.py.
Although I may have to remove that when zipping up an apworld due to the non-local import?
|
Well, at least Launcher.py shouldn't have future conflicts. Though I'm unsure if that import is ok in apworlds, but I can always extract that if I need to zip a new one up. |
Adds Adventure for the Atari 2600, NTSC version. New randomizer, not based on prior works. Somewhat atypical of current AP rom patch games; The generator does not require the adventure rom, but writes some data to an .apadvn APContainer file that the client uses along with a base bsdiff patch to generate a final rom file.
Adds Adventure for the Atari 2600, NTSC version. New randomizer, not based on prior works. Somewhat atypical of current AP rom patch games; The generator does not require the adventure rom, but writes some data to an .apadvn APContainer file that the client uses along with a base bsdiff patch to generate a final rom file.
What is this fixing or adding?
Adds Adventure for the Atari 2600, NTSC version. New randomizer, not based on prior works. Somewhat atypical of current AP rom patch games; The generator does not require the adventure rom, but writes some data to an .apadvn APContainer file that the client uses along with a base bsdiff patch to generate a final rom file.
How was this tested?
Two beta tests with a few other games. Several offline syncs and asyncs. Running tests and building an inno installer and testing that with the client enabled and disabled. For large scale generation, generated a few 1050 world and 2600 world multiworlds with just Adventure.