[Feature] Repurpose sub-level system to allow players to be in multiple intracluster maps at the same time

[Boondorl]

GZDoom version

No response

Which game are you running with GZDoom?

None

What Operating System are you using?

None

If Other OS, please describe

No response

Relevant hardware info

No response

Is your feature request related to a problem? Please describe.

Currently the sub-level system has been dormant for who knows how long and the plan for it was never very clear. Hexen is a core id tech engine game and playing it in multiplayer can be frustrating since all players are forced to travel to the same intracluster levels at the same time. Given this game was literally made for co-op, it makes sense to expand on its features with the already existing multi-level ticking code.

Describe the solution you'd like

The best path forward would be cleaning up whatever code remains decoupled from it and figuring out the best way to handle keeping events synchronized. Levels would only run if they have an active player in them and would shut down otherwise. The easiest solution to handle this would be to load in all levels at once and then have a dormancy system where empty levels are not ticked, but this would eat up more memory. Potentially this could also allow an option for levels to keep running in the background should someone want to simulate an ecosystem of sorts (think something like STALKER's AI systems). The harder solution is dynamically snapshotting and (de)loading levels based on if anyone is even active in those levels.

The ACS VM would also need to be tweaked a little so it would be intelligent enough to run level load scripts instantly for e.g. Hexen's puzzles that work off map re-entrance. I believe event handlers would also need to be changed and the VM's primaryLevel functionality would need to be tossed as function calls could come from any level at any time. I think this whole rework is totally doable, it just needs a clear plan of action since it wouldn't require any real changes to rendering or determining how an Actor crosses level boundaries.

Describe alternatives you've considered

No response

Add any other context or screenshots about the feature request here.

No response

[kcat]

Given this game was literally made for co-op

I don't remember hearing that Hexen was made for co-op. It's an option, sure, but it's design seems primarily for single-player.

Allowing different players to be in different maps of a hub can present challenges with scripting. Maps can trigger scripts in other maps, which normally won't execute until the player warps to that other map. This can be set up in a way that the intended effect is meant to trigger when the player appears back in the other map, but if it's possible for another player to be in that map when the script is triggered from elsewhere, the effect can be premature and create softlock scenarios as the effect happens when the players aren't where they're expected to be. Hub maps can also have continuously running scripts that occasionally spawn in new things for the player to fight while in the map; if these continue to run and spawn new enemies when players are off in other maps, they'd come back to that map to find a lot more creatures than intended.

Aside from the complexity of synchronizing players doing things in different maps, and synchronizing map state as players warp between maps, this would have to be an opt-in setting for hubs. They'd need to indicate they were designed with asynchronous, immediate inter-map effects in mind, rather than the current behavior of delayed inter-map effects.

[Boondorl]

Auto running maps in the background would be opt-in via MAPINFO since nothing is designed to support it by default and it could be potentially expensive since you're running multiple levels worth of thinkers at once. Level scripts running immediately could definitely present potential softlock scenarios, but I'm not sure if vanilla Hexen would have this issue. Ideally it'd be a server option so the host would decide if players must travel together or if they're allowed to split, but for the previous reason it might be smart to also make that behavior opt-in via the commandline. Future maps can simply design around it if needed via map scripting if they want to support it.

Synchronizing would be quite simple. When a player is loading a new map, the game will momentarily pause as it waits for that player to send over their next tick. Not super ideal from a smoothness perspective but level swapping would just need a way to essentially shift a player from one map to the next in a way that the thinker lists will match (since the game is fully paused while the player is loading in, this is probably more trivial than you'd think since race conditions aren't possible). That being said, since the maps are already fully loaded into memory it would mostly show up as a minor hitch.

[MajorCooke]

I would love for multi-levels to be a thing because I'm working on a project where I have to put actors in fake sectors to make them act, and then transfer them over to another map in the event they're active and the map switches. This would cut out a bunch of extra sectors I'd have to make in order to make them work, i.e. doom enemies marching up to a base far away and attacking it while the player is on route from another map.