FFA map counts: set instead of a single number

[sprunk]

This field expects a single number:

But really the possible player counts, the max player count and the best player count are not necessarily the same.

For example Throne ( http://zero-k.info/Maps/Detail/8162 ) can support up to 16 people:

• but it has reasonable starts for any number up to 16. For example it has non-crappy 10-way startboxes defined (the 7-way ring at the bottom plus the 3-way ring on top).
• it generally plays best when played 7-way.

Oktogon ( http://zero-k.info/Maps/Detail/57013 ) can also support up to 16 people:

• it has reasonable starts for 2, 4, 8, 12, and 16 people. It doesn't support 10-way well (uses 12-way boxes but leaves empty slots).
• it plays best in 4 or 8 way (probably - new map and hard to tell yet, but unlikely to be 16).

This mostly has the effect on what the map picker proposes (for example it won't propose Throne for a 7-way because it is set to max 16) and a slight effect on balance (for example a 14-man game on Throne will become a 14-way FFA and not a 7-way Team FFA with 2-man teams in an FFA room). For now the workaround is probably to tag maps with the "plays best" instead of "max supported" playercounts but it would be ideal if you could put multiple values there.

[maackey]

I would expand this to be map player counts in general -- not just FFA.

When searching for maps on the website a 2v2 teams map will be included with 16v16 lobster pot maps -- there's not currently any good ways to filter/search by player count -- arguably more important than map size, which can be misleading.

The different sets of player counts would be nice to have available on the map detail page as well.

---

Resources table schema currently has the following related fields:

• MapIs1v1 (bool?)
• MapIsTeams (bool?)
• MapIsFfa (bool?)
• MapFFAMaxTeams (int?)

I'd either replace MapFFAMaxTeams with MapSupportedPlayers (varchar?) -- comma separated list of supported player counts... or add a linking table MapSupportedPlayers (ResourceId, PlayerCount) -- many to many relationship between the map and supported player counts (leaning towards this more and more as I think about it).

[sprunk]

I don't have an opinion on counts outside pure N-way FFAs because those are fuzzy.

Consider DSD. It has 7 obvious startpoints per team (total 14). Do you mark 12 or 16 as a supported playercounts? What about 4 (2v2 here is hardcore but not even degenerate since there's just two lanes) or 32 (cluttered but then literally every map would be in a 16v16)? Where is the border?

Worse, consider Aberdeen_3v3v3. Do you mark it as a 9-playercount map? But you can't play a decent 9-way FFA there. Do you mark it as a 3-playercount? But it's a bit too large for each side to be just 1 player. It's fundamentally a team FFA map which just integers won't be able to reflect.

---

For N-way FFAs I agree that a linking table (ResourceID, PlayerCount) would be good.

[maackey]

The nice thing about the linking table is that it can support both the strict, specific N-way FFA and the fuzzy -- close enough estimation.

DSD possible supported playercount set: 6, 8, 10, 12, 14 3v3 to 7v7 is probably close enough to the range of players it was designed for. Obviously you can play with more/less but the experience will be different. I haven't played on it in a while, I might even say bump minimum to 4v4. But in any case I view this field as dependent on the map and what the designer says / thinks is appropriate.

Yes, Aberdeen doesn't support 9-way FFA, but 9 players can play FFA on it. Introducing teams to FFA definitely complicates things. Perhaps we'd need two tables to determine the supported playercount and supported team count (for FFA directions). In which case Aberdeen would have two sets: supported playercount: 3, 6, 9 supported teamcount: 3

There's other maps like neurope, speedball, duck, etc. that can support a wide range of play styles: duck playercount: 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, etc... duck teamcount: 2, 3, 4, 5, 6, 7, 8, etc...

[sprunk]

Aberdeen would have two sets: supported playercount: 3, 6, 9 supported teamcount: 3

What about, say, La Isla Bonita? It's a 3-way map but is also explicitly designed to be good for 1v1. You can both put "3" as a supported playercount and "2" as a supported teamcount but you don't actually want to make a 2v1.

DSD possible supported playercount set: 6, 8, 10, 12, 14

This isn't fuzzy, it has specific values. Let's work with this set as an example:

• why not 4? DSD has just 2 lanes so technically a 2v2 doesn't yet become degenerate and can be played if you're hardcore enough. I agree that it's good not to have this value in the set though.
• why 6? It doesn't even fill all the "back" startpoints. I would disagree on having this value in the set.
• why not 16? 8v8DSD is a meme at this point and like, "the" DSD experience (despite being larger than the map is actually designed for). I would disagree on not having this value in the set.
• let's pretend somebody improved the list and put values up to, say, 20 on it. Somebody could ask, why not 22? It's fun and cozy.

Etc, ultimately it's just down to somebody deciding on some borders which will be arbitrary to some degree and bound to create disagreement. This doesn't mean it would be a worse solution than what we have now but is one of the reasons I don't want to expicitly endorse it.

By "fuzzy" I meant something like having a linking ResourceID -> (TeamCount, canonicalPlayerCount), for example

DSD Deluxe: (2, 16) DSD: (2, 14) Marsellus Wallace: (2, 2) Aberdeen: (3, 9) La Isla Bonita: (3, 3) La Isla Bonita: (2, 2)

And the non-canonical playercounts would just be weighed less for !map. For example if you're playing an 8v8 teamgame then DSD Deluxe has some 1 in X chance to be picked because it is the canonical size, regular DSD has 1 in Y chance where Y > X because it's slightly off from the canonical but still perfectly okay, and Marsellus Wallace has basically no chance of being picked because it's pretty fucking far from okay. Similarly, if you want to play a 3-way FFA and have 12 people it would prefer Aberdeen over La Isla Bonita, and a map tagged (3, 12) would be preferred over Aberdeen if one exists. Effectively this would be similar to the current system where the playercount is just aproximated by the map area.

This still doesn't solve the case of which team counts are the best though. For example I would want Throne to still be proposed some of the time for a 10-way, but this can't be done via "distance from optimal" because unlike playercounts, teamcounts don't work that way (for example 5-way is great on throne, 6 is bad, 7 is perfect, 8 is okay, 9 is bad, 10-way is okay, 11 is bad, ...). Duck "works" at literally any playercount but I would not want it proposed at all - this is currently done via map support level so maybe that's also something to consider - so Throne could be (5, 5, Featured), (7, 7, Featured), (8, 8, Supported), (10, 10, Supported), and 6/9/11 not even listed so implicitly unsupported. Then if you have 10 people in a room and there's a !map, or put 10 in the desired playercount search on the website, Throne would be treated as a Supported map, but with 7 it's Featured.

Then there's the question of what to do with the MM (which only exists for 2-way maps and only very specific playercounts). Maybe the playercount can just be per-team, and from the set of "Solo (1v1 / true FFA), small (2-4), large (5+)", or maybe a separate 2-3 and 4-5 counts to match what the MM has, in which case every size can be fairly reasonably marked?

So you could have

The edit UI would look like

And in the DB it would be (ResourceID) -> (teamcount, size, level).

[maackey]

What about, say, La Isla Bonita? It's a 3-way map but is also explicitly designed to be good for 1v1. You can both put "3" as a supported playercount and "2" as a supported teamcount but you don't actually want to make a 2v1.

The same could be said for DSD Deluxe: (2, 16) -- its not very good for a 10v6 game. I'm coming from the assumption of a player looking manually for a map through the site, or the lobby trying to select a map for balanced teams/ffa. I don't really get this point at all.

I guess my definition of fuzzy was all those questions of "why not 4? why 6? why not 22? etc." -- there is no clear optimal set, and yes it is rather arbitrary / up to the maker or devs to decide values. But this also applies to the singular "optimal" value in your system, there are just fewer numbers to contend with. But yes, this is definitely an advantage of a singular value. However explicit values have several advantages:

1. Players can clearly see specific player / team counts and not wonder if 4v4 is a "small" or "large" game map
2. No ambiguity for filtering and automated processes. I've been told computers are rather good at handling numbers. A little less good on human concepts like "small" or "large".
3. Edit UI is dead simple: A single text field input for player count, and a single text field input for team count. MapsController can parse the string and store values in correct relational format, and likewise query related values and format them to a string for editing.
4. Flexibility to properly define odd and peculiar maps with multiple specific values. And allows MM to do stuff like FFA (3 players on 3 teams it can easily filter to select only maps that support 3 teams and 3 players without any extra work)

You also got me thinking about weights which can also be implemented in the explicit system (an extra column in linking table for weight value), and ordering the numbers in the input string. I'm wondering what would happen if eg. 12 players were in a room with aberdeen selected and someone started !map -- would the balancer allow for a map like isle de bonita? How?

Also, I'm pretty sure support levels are one per map -- they would also have to be overhauled which I'm not sure has a positive ROI. It would also increase maintenance costs by having multiple levels of support to modify -- that straight up sounds like a nightmare to manually update hundreds of supported fields multiple times over for each of the hundreds of supported maps.

I know those screenshots are of the details page, which I haven't gotten to yet, but here is the direction I'm heading with map previews. Still WIP (values are meaningless, everything subject to change, etc.) but may provide some idea of where I'm heading with details -- replacing ugly inflexible hard to work with stars into info tags, but very similar idea.

[sprunk]

Apparently BAR has something like my idea in the post above under the hood: https://github.com/beyond-all-reason/spads_config_bar/pull/19