Implement bedwars event

[TestingPlant]

In the Discord, we have agreed that implementing bedwars would be a good choice for our final event. Depending on how we design the map, there will be ~30 teams with ~300-400 players/team. In my opinion, bedwars is good because:

• it is a well known and popular concept which is easier to advertise
• relatively simple to implement
• minimal physics needed
• doesn't require a lot of skill for people to have fun, and people won't die/quit immediately
• people can join in the middle of the game without getting an unfair advantage aside from spawning only in the alive teams
• there won't be too many (>1k) players at the same place most of the time, which will be helpful for Implement serverside entity culling #912

To implement this, we need:

• a test map (doesn't need to look good, we can build our real map later)
• resource generators
• shop gui
• instantly kill players in the void (below a specific y level)
• automatic respawn after a specific number of ticks (e.g. 100 ticks/5 seconds)
• respawning only if bed is not broken

[TestingPlant]

One issue is that there's only 16 wool colors. Usually one team would get one wool color, so this would require ~600 players/team. This leaves us with the following options:

1. Find some resource pack trick to get more wool colors
2. Develop a mod to add more wool colors
3. Reuse the same wool color for 2 teams
4. Same as 3, but use a server plugin to make each client's team is a unique wool color locally
5. Use only 16 teams

I've done some research into resource packs and I didn't find anything immediately. Wool doesn't have any block states we can take advantage of in the resource pack, and I don't think we can add custom block states unless I'm missing something.

Ideally we would not require client mods to join the server. Setting up mods requires some amount of technological knowledge and trust in the mod authors which would stop some players from joining.

16 teams is a somewhat small amount if there's only 1 base/team. We definitely need entity culling for client performance, and having ~600 players at one base plus any attacking players would not be ideal for client performance, although it might be doable. We could mitigate this issue by having 2 bases/team, which also means each team would have 2 beds. This gives the advantage of easily meeting the target goal in #912 of <1k players visible per client and also has the gameplay advantage of preventing teams from dying too quickly.

I'm liking the last solution the most with 2 bases/team, although we might need to reduce the number of teams to limit the map size.

I'd appreciate getting suggestions regarding this.

[andrewgazelka]

I think a lot of people use redstoen block states for this

[Snoodle-Games]

There are multiple paper plugins that can be used to create custom blocks without use of clientside mods. For example: Itemsadder or Oraxen.

I think the most common way to make custom blocks is using noteblocks or mushroom block ids. I'm not sure of the exact method though. Here is a wiki page on itemsadders blocks
https://itemsadder.devs.beer/plugin-usage/adding-content/block

Alternatively, using 16 colors with 2 bases is definitely a good option. Perhaps you could even slightly change the game format to Warlord where each color begins with two bases, each with its own team, then whenever a color captures a base, that group of people convert to that color instead of being eliminated. Then, the first color to capture all teams wins.

[TestingPlant]

I'm thinking of using 16 teams with 2 beds instead of adding more wool colors though resource packs because:

• Accessibility - distinguishing between two different team colors will become more difficult as we add more wool colors. I believe this would be difficult at 30 wool colors even for people without color vision deficiencies. Naming the colors for communication with teammates would also be difficult.
• Many people like to play with their own texture packs which include changes to the wool texture
• Having 2 beds with 16 teams would ensure that people don't get final killed too quickly. Having 2 beds with more than 16 teams would be a lot of islands

[TestingPlant]

Perhaps you could even slightly change the game format to Warlord where each color begins with two bases, each with its own team, then whenever a color captures a base, that group of people convert to that color instead of being eliminated. Then, the first color to capture all teams wins.

I'm not sure whether this would be a good idea. We need the support of many content creators to get enough players for the event, and I believe sticking to the traditional bedwars rules would help with getting bedwars content creators to participate.

[Snoodle-Games]

Fair enough, and after some thought, I realized that having a warlord method would end very badly for client performance since it would be like 9000 players all trying to invade the last standing team LMAO

And 32 colors would be a headache for sure LOL

Would you want the two beds per team to be in different locations within a single large island, or would you want a team to own 2 islands? When one bed is destroyed, would 700 players all spawn on the same location? Or would we have multiple respawn points on each island to distribute players more?

Then for the islands, how big do you want them to be compared with the team size? How naturally fortified or complex do you want them? For example, on one extreme they could basically be platforms. On the other extreme they could be fortresses with layers of defense.

How large should the center emerald island be? And the side diamond islands? How many resource spawners of each type should exist on islands?

Also, are we going to do that smaller 2000 player event first to test this, and if so, are we going to use a smaller map for that, or use this 10,000 player map, just with smaller teams?

[TestingPlant]

Would you want the two beds per team to be in different locations within a single large island, or would you want a team to own 2 islands?

I'm taking some inspiration from Hypixel's 40v40 bedwars which has a separate island for each bed. I'm not sure where we'll place each island yet, although I think placing the two islands per team with one island close to the center of the map and another island near the edge of the map and having a teleporter between the two islands could lead to some interesting gameplay. The teleporter would probably use the end portal texture.

When one bed is destroyed, would 700 players all spawn on the same location? Or would we have multiple respawn points on each island to distribute players more?

I'm thinking of only having players spawn on the alive island, but players spawn on a random generator. I'm thinking of having multiple (maybe 3?) rooms that is approximately 10-15 blocks tall that each contain a generator around 10x10 in size and a shop, and each room is connected to each other in a triangle, and each room has an open gap to reach the outside of the island. I believe the bed should be on the roof of the 3 rooms and have some sort of staircase up to the roof. The roof would allow enemies to still sneak into the bed defense. The roof and different rooms would help with entity culling by reducing the number of teammates visible from a given point.

Then for the islands, how big do you want them to be compared with the team size? How naturally fortified or complex do you want them?

I don't think we should have any natural fortification; I feel like that would be unusual for a bedwars implementation. Each island should be roughly circular and have enough space to fit the rooms mentioned above with some additional space (~5 blocks) to allow people to walk around the perimeter of the island without entering a room.

How large should the center emerald island be? And the side diamond islands? How many resource spawners of each type should exist on islands?

I don't have an exact map layout in mind. I was thinking of having the map being hourglass shaped, although that would make a wide map which is be both beneficial (e.g. many players will be out of render distance) and harmful (large distance between bases, people will need to do a lot of walking, and from a content creator perspective, the entire map should be visible from replay mod).

Also, are we going to do that smaller 2000 player event first to test this, and if so, are we going to use a smaller map for that, or use this 10,000 player map, just with smaller teams?

I would still need to get confirmation about whether TheMisterEpic is still willing to help coordinate the 2000 player event, especially since we changed from the original tag gamemode to bedwars. If we do have the 2k player event, we will probably use the same map with some of the outer islands removed since I don't believe we should spend a lot of time creating a separate 2k player map.

All of these are just suggestions and nothing is set in stone. I'd love to get some feedback on it. I also want to avoid making a carbon copy of any existing bedwars implementations. For example, I'm thinking of adding netherite as the most valuable resource that would only be at the center of the map while having some emerald generators throughout the map. However, this isn't possible if we want to use ViaVersion and support 1.8 clients. I'm not sure whether we should support 1.8.

[Snoodle-Games]

Having an inner and outer island is an interesting idea for defense, though it would cause more of a player bottleneck since the full 700 player team would be traveling through the inner island to reach the center. However, this setup is useful for scaling down to the 2000 player event since you can just remove the outer islands

The island structure of three resource spawners with walls and the bed on top sounds like a pretty good setup. Is there a reason you want three as opposed to four, though?

The hourglass shape would probably result in some bases having an advantage since they'll be more or less clustered by other bases due to the asymmetry. As far as loading the entire map, that may be a bit cramped for a 10,000 player event. I mean, I guess a 32 chunk wide map would have a density of 1 player per 26 square meters, though considering there will be player clustering and a lot of void area, this sounds kinda cramped.

However, for content creators, you could use viaversion to allow for 1.21 clients which can install the Distant Horizons mod along with the Flashback mod, which is a better version of the Replay mod that can render Distant Horizons data within it. We could then provide a client that has Distant Horizons data of our map pre-packaged in it.

Also, what kind of aesthetic theme should we go with? Floating fantasy islands? Sci fi? etc...

[Snoodle-Games]

As for netherite, you could fix the 1.9 issue by simply making the resource you pick up a nether star, then you use that resource to buy netherite, but set up viaversion to display gold gear for old clients.

Or, if you wanted to be fancy, you could create a custom resourcepack that has a complete set of armor of each tier. Using leather as the template for all armor sets will allow you to add colored components to each piece while also displaying the material type such as iron, diamond, netherite

Something along the lines of this:

[TestingPlant]

it would cause more of a player bottleneck since the full 700 player team would be traveling through the inner island to reach the center

I don't think this would be an issue. In my bedwars experience it is already very difficult to coordinate a team of 4 random people to do something together. Players will also need the lower tier resources like diamonds that are in less contested areas outside the center of the map and thus easier to get. I don't think the full team would be going to the center of the map simultaneously.

Is there a reason you want three as opposed to four

Either three or four would be okay

The hourglass shape would probably result in some bases having an advantage since they'll be more or less clustered by other bases due to the asymmetry

That's true. I'm thinking about changing it to where we have circular rings around a center island. For example, we could have 4 circular rings with 4, 6, 8, and 14 bases respectively (these are very approximate numbers, we will likely need to adjust it). Ring 1 would be the ring closest to the center island, i.e. smallest diameter. If a team has a base in ring 1 they would be nerfed by having a base in ring 3 which is theoretically easier to attack due to it being close to many other teams and the possibility of them being attacked from any direction, while a team who has a base in ring 3 would have their second base in ring 4 where it's harder to attack due to how far on average it is from other teams and having less bridges to the ring 4 base.

However, for content creators, you could use viaversion to allow for 1.21 clients which can install the Distant Horizons mod along with the Flashback mod, which is a better version of the Replay mod that can render Distant Horizons data within it. We could then provide a client that has Distant Horizons data of our map pre-packaged in it.

I'm thinking more about how content creators would likely want to show the entire map from a top-down view on screen to show the size of the event without needing to zoom out so far that viewers can't see anything. I'm planning on having the server record a replay mod file (#923) because serverside entity culling would make players hidden behind walls also hidden from replay mod on the client.

Flashback mod seems interesting too. I've thought about adding Flashback mod format recordings to #923. However, the Flashback mod appears to be only source-available. I believe that we should not try to implement the Flashback mod format in Hyperion due to the risk of copyright and patent infringement.

As for netherite, you could fix the 1.9 issue by simply making the resource you pick up a nether star, then you use that resource to buy netherite, but set up viaversion to display gold gear for old clients.

I'm not sure how important it is to have 1.8 support. From what I've read, most people play with 1.8 for:

• support for mods that are specific to a server
• avoid pvp cooldown (I don't think this is an issue since Hyperion doesn't penalize for spam clicking on the server or keep track of the hit cooldown)
• more fps (for some people?)
• it generally works and there's no need to upgrade

I don't believe these issues are that significant on Hyperion. I'm also hesitant on adding fallback blocks and items and making a resource pack to backport the new textures because that would add additional complexity and I'm somewhat doubtful of whether that complexity would outweigh the advantages of supporting 1.8.