beyond-all-reason / bar-lobby

BAR Lobby Client
https://beyond-all-reason.github.io/bar-lobby/
MIT License
37 stars 35 forks source link

Sort custom lobbies based on "best lobby" instead of by players #238

Closed kozak-codes closed 1 year ago

kozak-codes commented 1 year ago

Closes #237 Fix https://github.com/beyond-all-reason/bar-lobby/issues/223

The first lobby should be the lobby that gives you the best chance of jumping into a game as fast as possible

Adds a "scoreBattle" function to the end of the battles list that will score values based on provided values in the issue list. This also re-orders the columns of the custom battles to place the battle "best status" on the far left side. Scores are adjusted so that running battles, or battles ending soon, will display above locked battles but still show locked battles on the first page, if you have them enabled.

Let me know what you think and if you'd like me to polish further.

Example battle list result: image

The battle that you want to join will always be placed at the top. One thing to note is the "ending soon" battles that are full and potentially will be finishing up shortly. Here, we also have a lobby full of spectators and it's placed higher because it might be a bit more renown

kozak-codes commented 1 year ago

This is an interesting idea, and I think this would be more useful to players. The scoring is subjective and arbitrary, and can make the order seem kind of weird, but I think players would appreciate it regardless.

With this I think it'd make sense to scrap the existing Runtime column and merge that functionality into this new column so it says something like Running for 40:15. I'd also rename the column header to Status, and rename Passworded to Private.

Would be curious to know what others think of this idea.

Thanks for the feedback! The scoring is definitely much more arbitrary, but it's meant to be something that can be fine tuned over time with feedback. I'll implement all your suggestions, however the "Best Match" versus "Status" was meant to indicate that the sort is based on best match, and not based on the status of the game. IE you would expect "status" to sort the status alphabetically in that case. In this case, "Best Match" simply indicates why something is a good or bad match, which can double as a status. What's cool about using "Best Match" is the sort indicator points to the first match, so players reading left to right see "Best Match" with an arrow towards the first match, so the sort indicator serves two purposes in that way.

kozak-codes commented 1 year ago

I stole the fixed runtime function from https://github.com/beyond-all-reason/bar-lobby/pull/226

Jazcash commented 1 year ago

the "Best Match" versus "Status" was meant to indicate that the sort is based on best match, and not based on the status of the game. IE you would expect "status" to sort the status alphabetically in that case. In this case, "Best Match" simply indicates why something is a good or bad match, which can double as a status. What's cool about using "Best Match" is the sort indicator points to the first match, so players reading left to right see "Best Match" with an arrow towards the first match, so the sort indicator serves two purposes in that way.

True, although tbh I'm kind of sceptical about the usefulness of having this column be sortable both ways at all. I can't imagine there being a use case really where users would want to see the battles with the lowest scores first. Tbh that goes for the title, map and locked columns too. Even for the playercount and runtime columns, I think it's more likely that users would go to the last page to find the opposite of what they're looking for. So I'm leaning towards changing the behaviour of clicking a column heading to sort it by the most likely desired order, rather than flipping between ascending and descending. I guess that's not exactly relevant to this PR though.

The hope for the future is good matchmaking implementation will reduce the amount of custom battles, so I'm hesistant to go overboard with the amount of functionality, but overall I'm happy enough with this to merge. Will wait a bit in case anyone else weighs in.