NeunEinser / bingo

A custom item fetch gamemode for Minecraft
MIT License
81 stars 16 forks source link

Separate Spawnpoints per Team #237

Open AlmightyZing opened 1 month ago

AlmightyZing commented 1 month ago

This is a request to have Spread Players be a toggleable option in the lobby. My group prefers to be separated for our bingo games and while the vanilla command below doesn't completely prevent running into other players it does a good enough job that I don't think doing something custom to spread us further is needed.

I've been doing that by manually running the following command just after the countdown finishes (would probably be better before the countdown starts, but I didn't want to risk interfering with the countdown).

This spreads players out in a 1000 block radius and respects teams.

spreadplayers ~ ~ 1000 1000 true @p

https://minecraft.fandom.com/wiki/Commands/spreadplayers

You'd probably want to add your predicates to distinguish between in-game and spectators

NeunEinser commented 1 month ago

Yep, I think something similar has been suggested before. It doesn't look like it has made it's way to github though, or at least I cannot find it.

The main issue I have with the approach you are suggesting is that it renders the skybox effectively useless. If this was implemented, there should be some way to preview each team's spawnpoint.

Since the teams are created after pre-generation starts, this would cause some issues as there is no way of knowing how many teams will be needed, and just always generating 16 spawnpoints would be quite wasteful and lengthen pre-generation significantly.

So, ideally we would initially just generate 1 skybox and only when someone joins a second team, we would generate an additional one if the setting is active and teleport all players to the correct skybox once it's ready.

This would btw also have the additional advantage that the marking functionality of item frames becomes more useful as each team could be using a local version.

Some considerations and edge cases:

One open question: I'm not really sure how the compass and coordinate display should work. Currently, you get teleported to very high coordinates to implement random spawn points, and the displayed coordinates are relative to your spawnpoint.

For cross-team communication it would be confusing. But most likely, it would make sense to just display coordinates relative to the team's spawn point.

This would also mean, for each new team we could just generate a completely new spawn point, which makes it effectively impossible, or at least extremely low odds, for teams to run into each other.

Finally, I think no spread should still be the default, mostly because it seems the most fair as everyone gets the exact same starting conditions.

AlmightyZing commented 1 month ago

Yeah I guess if players want that overview from the skybox that would complicate things. For my group in particular we don't mind a blind spawn location, but I know that won't apply to everyone. We mostly play blind mode so I think of not knowing what spawn looks like an extension of that mode.

I know in other datapacks I've played the card and team selection are done in the lobby, and they essentially created a skybox for each team when the game started. Waiting to create those skyboxes and pre-generate until the game starts would eliminate some of the issues you've laid out (along with cutting down on world file size since currently if you keep randomizing the cards it's saving a lot of unused region files). That would probably require a big rewrite or reshuffle though. I agree that making this opt-in is the way to go.

But yeah we're fine with just running a spreadplayers command for our purposes in the meantime. I'm happy to provide feedback if you come up with any other ideas for this.

NeunEinser commented 1 month ago

Giving a heads-up overview is pretty nice for some of the target groups. Selecting teams from the lobby and only showing spawn at the very end is what version 5.0 used to do, and it's certainly easier to implement.

Reverting back to the old behavior would be a step backwards imo for a - from my pov - relatively niche feature.