ZDoom

DevilBlackDeath wrote:

Soosisya wrote:

DevilBlackDeath wrote: If what you lack is someone to test it with for desync, you could always, like I did for my EVP MP fix, host and join on the same computer If you have 2 screens you can even use "+vid_activeinbackground 1" to see what the other player sees

I'm just bad/lazy at net-codding

Gonna give it a try this week-end if I have time and I'll let you know if I encounter any desync (and if I have any idea where they may come from ) ! In the long run, seeing this be a MP mode for GZDoom would be amazing. I only just discovered how actually stable GZD can be if you have half decent connections so yeah, really hyped to see this project developed. Best of luck

I'm also not sure how some items will stack and work with many players on the map

Soosisya wrote:

DevilBlackDeath wrote: Gonna give it a try this week-end if I have time and I'll let you know if I encounter any desync (and if I have any idea where they may come from ) ! In the long run, seeing this be a MP mode for GZDoom would be amazing. I only just discovered how actually stable GZD can be if you have half decent connections so yeah, really hyped to see this project developed. Best of luck

I'm also not sure how some items will stack and work with many players on the map

As far as stacking goes I guess you could go with calculating the amount of players (if you do that in zscript there's an array of booleans called "playersingame" of size MAXPLAYERS, you could loop through all of it and see how many trues are returned). If you mean giving an instance of each item for every players and stopping other players from picking it up that's more complicated but I have ideas ! But I think the first thing is enough since RoR and RoR 2 themselves don't bother with instantiation which is also known as ninja-everything-you-can-so-you-get-OP-while-your-friends-are-destroyed. Based on that amount of players you can scale item spawning (maybe using Clone Enemies algorithm of "spacing out enemies" to space out your item spawns) as well as enemy spawns and spawnrate (maybe even their "difficulty" rate if you plan on implementing RoR difficulty-scaling over time).

DevilBlackDeath wrote:

Soosisya wrote:

DevilBlackDeath wrote: Gonna give it a try this week-end if I have time and I'll let you know if I encounter any desync (and if I have any idea where they may come from ) ! In the long run, seeing this be a MP mode for GZDoom would be amazing. I only just discovered how actually stable GZD can be if you have half decent connections so yeah, really hyped to see this project developed. Best of luck

I'm also not sure how some items will stack and work with many players on the map

As far as stacking goes I guess you could go with calculating the amount of players (if you do that in zscript there's an array of booleans called "playersingame" of size MAXPLAYERS, you could loop through all of it and see how many trues are returned). If you mean giving an instance of each item for every players and stopping other players from picking it up that's more complicated but I have ideas ! But I think the first thing is enough since RoR and RoR 2 themselves don't bother with instantiation which is also known as ninja-everything-you-can-so-you-get-OP-while-your-friends-are-destroyed. Based on that amount of players you can scale item spawning (maybe using Clone Enemies algorithm of "spacing out enemies" to space out your item spawns) as well as enemy spawns and spawnrate (maybe even their "difficulty" rate if you plan on implementing RoR difficulty-scaling over time).

I mean something different. Let's say 1 player has an unstable nuke, while another player does not. If the first player kills a monster, it goes boom, if another player kills it - it does nothing. Okay, that's simple to check. But there is a feature when a monster dies from an unstable nuke, it also activates an unstable nuke based on the amount of items the player has. In order to perform that chain with 2 or more players, I'd have to somehow pass the pointer of the player who activated it to the next explosion... something like that.

Soosisya wrote: I mean something different. Let's say 1 player has an unstable nuke, while another player does not. If the first player kills a monster, it goes boom, if another player kills it - it does nothing. Okay, that's simple to check. But there is a feature when a monster dies from an unstable nuke, it also activates an unstable nuke based on the amount of items the player has. In order to perform that chain with 2 or more players, I'd have to somehow pass the pointer of the player who activated it to the next explosion... something like that.

Huh yeah! I don't know how that would work. I've read stuff on damage source and damage types but I'm not an expert. I guess you don't really need the "pointer" to the player as much as you'd need their player number. Then you can pass a simple int through to the nuke. Or even make the new Nuke kind of "inherit" the stats of the old one if that makes sense, though that one would be harder. In the "int" case the only edge case you'd have to be careful with is if the player disconnects DURING the nuke but then again since mid-game joining is not a thing in GZDoom anyway not really a big deal. Actually even simpler you could probably just let the "attack" have all the basic important informations, like in the case of Nuke, you store how many nukes the player has in their inventory. It's unlikely the player will pick another one DURING a chain effet, and whether or not the new Nuke should apply to effects in progress is debatable.

Very underrated project !
This mod made me play through the entire Doom 2 campaign (last time I did that was 2006)