Open SiriusAshling opened 2 years ago
Another aspect to consider is that unless you're able to die somewhere, a refill Checkpoint only gives you the refill if you quit to menu. You could represent this by putting the Checkpoint refill only on the non-enemy variant, although there might be oversights from seedgen since it doesn't currently backtrack with improved resources if an anchor has been previously visited.
We could also just disable the despawning of enemies, or add it on an uberstate switch that is automatically applied on Kii+ difficulty if we want to keep it for Gorlek and Moki
Hmm it is a protection though so you might spawn inside enemies if we disable the despawning. It would some logic tasks simpler though, no doubt.
I think thats fine, we could even add a bit of spawn invulnerability if it turns out to be a problem. Think this solution is better then having logic handle this as it allows for more interesting paths while making the logic work easier :P
Could be worth trying to see how it feels in practice, don't expect anything disastrous would happen
Hmm it is a protection though so you might spawn inside enemies if we disable the despawning
We could also just not set anchor/spawn points inside enemies? :eyes:
There's not always a lot of space but I think we can try it and will notice if it causes trouble
When dying and respawning on a checkpoint or initially spawning into the world, enemies in a certain radius despawn. The enemy reappears if you move it offcamera. This is resolution-dependant, logic should at least consider a 21:9 resolution as horizontal extreme. This wasn't an issue before as those enemies were considered out of logic in gorlek, but now becomes relevant with kii. Before supporting fully random spawn, these cases should be looked through to avoid softlocks.
Namely the anchors should be looked through and checked whether any important enemies despawn when placing a checkpoint on those coordinates and dying. If this is the case on an anchor that is not tied to a checkpoint, it should be moved far enough away so the enemy in question can spawn properly. If that is not possible or the anchor is tied to a checkpoint, the following logic pattern can be used to represent these cases:
An anchor with despawning enemies ("Some.Anchor") is given a secondary variant ("Some.AnchorEnemyPaths"). The EnemyPaths variant contains exclusively those paths that depend on the despawning enemy in any way. It is marked so it cannot be spawned on in fully random spawn (depends on #19) to prevent softlocking by spawning there. Any connections from neighboring anchors connect to the EnemyPaths variant (assuming they are far enough away so the enemy is guaranteed to spawn if you come from there). The EnemyPaths variant then contains paths using the enemy from kii upwards and otherwise only a free connection to the main variant with all the other paths not depending on the enemy. The main variant can represent moving far enough away and then back to respawn the enemy by connecting to the EnemyPaths variant. This concept can be seen in practice at LowerReach.Central