Make 8v8 a Map Tag and limit map sets based on player count

[vivid moss]

Had this idea recently as I've noticed that new players don't really understand what maps are typically played 8v8. It seems like there is a pretty consistent set of maps that could be tagged with 8v8 in addition to the "team" tag.

Since 8v8 seems is possibly the most popular mode, I think it is worth adding. It would also be cool if somehow the map sets could be filtered in a lobby, so that you can use commands like NextMap to pick a random map in that map set.

This seems like it could be a low effort way to simplify the lobby experience and make sure newer players know which maps are suitable for 8v8. I'd leave the map list open to the community first to determine which maps fit the 8v8 tag.

[empty pivot]

So that's basically a matter of going through the map tags and making sure they're up to date

If I understand you correctly, you wouldn't like to interfere with manual map selections, just the behavior of !nextmap

I think it already takes some map pools into account but I haven't checked its logic

[nocturne pollen]

similiar suggestions here https://github.com/beyond-all-reason/BYAR-Chobby/issues/459 and here https://discord.com/channels/549281623154229250/1112520691154165842
@empty pivot Idk if there's a system to tag a map anywhere. Did you hear about such a feature or do you know if anything related is planned ?

[empty pivot]

Not really. Although... @long shuttle, admittedly I'm a total noob when it comes to all the Rowy/map automation stuff, so I thought I'd ask - do you happen to know where the tags on maps are pulled from?

[lone tartan]

!nextmap rotation is already handled with a system like this on SPADS

https://github.com/beyond-all-reason/spads_config_bar/blob/main/etc/mapLists.conf

and https://github.com/beyond-all-reason/spads_config_bar/blob/main/etc/DynamicMapRotation.conf

what would be op is reworking the map list in chobby with additional filtering capabitilies and absolutely all these tags (also on Rowy) being shown

but I think nobody doing that because we just wait for Jazlobby

as for a quick way to have a reference now, use the curated map list on the website => https://www.beyondallreason.info/maps

[long shuttle]

Hey, those issues are 2 separate things:

• One is about client side tagging, when user tags map themselves
• Second one is about us tagging maps and that is pushed to all users

Client side tagging is purely lobby and maybe teiserver if you want it to be autosynced for your account.

Source of map tagging and overall everything map related in the future is Rowy. You need a shmuck that will tag those things correctly in Rowy.

Then there is SPADs part, and lobby part, I can push those tags automatically where it's needed, but you need somebody to make use of that information in both of those places.

[long shuttle]

All those files are dead, nobody is maintaining them.

[lone tartan]

ye but they still are used for the command

I only mentioned it since Perfi was talking about !nextmap

[long shuttle]

Website is also manually maintained, so updated rarely

[long shuttle]

Did you familiarize yourself how this files are used etc already? Are they actually used? Because I can automatically push content to them just like to https://github.com/beyond-all-reason/spads_config_bar/blob/main/etc/mapBoxes.conf

(if they exist, doesn't mean they are used, there is a lot of garbage in that repo)

[lone tartan]

I'm not like a super SPADS expert but I am 95% certain this is the data source for the !nextmap logic yes

[long shuttle]

Yeah, I see the plugin to do that is enabled, god, yet another piece of map metadata that is broken

[lone tartan]

with the map list pulling from that old gsheet

xD

[long shuttle]

It's not pulling, it's when whoever remembers to update it updates it.

Everything about maps is like that

[lone tartan]

ya wrong word, just another piece still using the prev system

[unique tendon]

what is Jazlobby?

[long shuttle]

@lone tartan I've opened https://github.com/beyond-all-reason/maps-metadata/issues/118 are you interested in helping out given your work on FFA?

[long shuttle]

Entirely new lobby developed at the moment from scratch that will allow us to add more features more easily.

[lone tartan]

not sure, I had other plans after wrapping up my current stuff, so no promises

[long shuttle]

if you at least have ideas about how the source of the metadata should look like, because you already know ffa problem space, that would be already helpful, and I can do monkey work

[lone tartan]

hmmm you mean like setting up the tags on Rowy?

but yes definitely no problem for helping with the content / metadata itself, just the system I'm not sure if I will work on it

[long shuttle]

Like, we don't want people to enter redundant information

[unique tendon]

you probably don't want too many options either, because that also becomes difficult to use

[long shuttle]

So, what is the minimal amount of information somebody need to provide, for us to e.g. figure out to which ffa sizes map belongs.

E.g. if you have only dimension: num_of_team and num_of_players, and let's say it's 3 and 3, then you can do 1v1v1, 2v2v2, 3v3v3 without somebody tagging that explicitly

If it's 2, 8: then sure that's 1v1, 2v2, 3v3..., but maybe also 2v2v2v2? Who knows

One solution is to just screw that and put all those combinations as separate options

[lone tartan]

well in my opinion the ideal case is, you open the map list from lobby, and it prefilters the list based on the lobby settings (e.g. 8v8 => filter for maps marked as 8v8 in Rowy), and then if you want you can disable filters or setup your own filters

[long shuttle]

But also: when you do ffa, you need to put the valid startpos combinations? Is that required to specify those combinations or not? If yes, we can automatically determine those combinations from there.

Just like e.g. for team games, we can figure out valid combinations of players maybe based on existance of startboxes for the given combinations

[unique tendon]

I think I can see how that would work. Does usability/accessibility become a concern at all for that approach?

[long shuttle]

I will stop now, this is what I mean by designing source of truth data type let's call it. Ofc, we can add redundancy, and then automatically test for invalid configuration, one of the main benefits that it's centralized is to exactly be able to detect stuff that doesn't make sense.

[long shuttle]

Basically Rowy is manual input, then you can do whatever imaginable transformation and testing you want, and it pushes to all consuming subsystems.

[lone tartan]

I think there is no need to think too hard about this, if you want a bit more details of how FFA maps can be triaged then you can have a quick look at my map lists here https://discord.com/channels/549281623154229250/1140480672625070142 but basically it's very easy to determine which maps can be played in X-way (same as the existing tags here basically => https://github.com/beyond-all-reason/spads_config_bar/blob/0b63c2735ff9fb153626e85c09d94708624f3fb2/etc/DynamicMapRotation.conf#L58-L72)

the only issue is indeed TeamFFA, but in general TeamFFA maps can be classified either as:

• regular X-way FFA map except you put more players in each team (example: Trefoil is a 3-way FFA map, but you can easily get 2 or 3 or even 4 persons on each team to make it a TeamFFA)
• maps dedicated to a specific X-way TeamFFA (example: Crescent Bay, which is specifically intended to be played TeamFFA 4-way)

so I think it'll be easy to get away with "just" using a combination of regular X-way FFA tag + an additional "TeamFFA" tag to denote that this map can also be played in TeamFFA, and it's OK if we don't classify further

because there are so few maps in this category anyway it doesn't matter