[Request for comments] Rethinking public rooms to foster a player community

[vdfdev]

The problems

1) Our public rooms features are underutilized - Even though it tooks us a lot of effort to develop, it never "catched on" with players. See the numbers below:

fbgDb=> SELECT "isPublic", COUNT(*) FROM room_entity GROUP BY 1;
 f        | 607430
 t        |  18308

Out of all the rooms created, only 2.9% of the rooms were public.

2) Users that come to the home page directly might not realize there is a private room option --- See https://github.com/freeboardgames/FreeBoardGames.org/issues/784. I've noticed that I've been often kicked out of public rooms, probably because they were not meant to really be public.

3) Our community of developers is disconnected with the community of players. Our discord is mainly inhabited by the developer community (which is great!) but we don't have much player activity there. Seeing other people play your game is very motivating for me, and even though we have https://stats.freeboardgames.org showing thousands of users, we don't have much personal connection with the players.

Proposals

Short-term proposal

Move the carousel to select a public room out of the home page and into the game info, sitting below the game mode cards. This should still be a carousel with several mini-game cards, and NOT look like the existing game mode cards, because the public room might be unrelated to the game the user is looking into. However, we should rank the public rooms in a way that always shows the game of the page first.

Pros

• More traffic seeing public rooms, more likely to find an opponent after creating room (improving 1)
• Less confusion about private x public, as both options would be in side by side (improving 2)
• Might allow users to find other games

Cons

• Might confuse users to see rooms for other games that are not the game they are looking into.
• The game page info is latency sensitive as the main entrypoint for users, so we need to make sure there is no layout shift (like it has today on the home), and also does not increase a lot the Lighthouse metrics.
• Does not tackle issue 3

Long-term proposal

We should replace the carousel and the public room with a simpler matchmaking experience. The idea is as follow:

v1

• Remove the carousel completely and replace it with a separate game mode, let's call it "Ranked".
• Users who click on the "Ranked" game mode are going to be asked to log-in with Discord.
• After that, a spinner will ask the user to wait for X minutes (X = 2?). It will also have a link to a new channel on discord #matchmaking. If someone else does the same during this time we start the match, otherwise ask the user to try again.
• In the initial version, during these X minutes, a bot will announce in #matchmaking that a given user wants to play a certain game. Anybody in the channel can then click on the link posted by the bot to start playing the game.
• We can allow users to start the matchmaking through a command on Discord too.

v2+

• We will keep track of who won/lost the game, add a timer, and compute an ELO score for each player and game.
• If we start seeing many users trying to play concurrently, we can have fancier algorithms trying to match the skill level of users (by using ELO) and/or postponing the bot announcement to the Discord channel.
• All statistics will be associated with the Discord account.
• Bot can announce and mark users when someone wins or loses.
• Bot can show ranking of users, and we can also show ranking on the website.

Pros

• Users won't need to be on the website to be notified that there is someone wanting to play.
• Using the discord authentication saves us a TON of work regarding authentication, password recovery, etc etc etc and gives a unified experience
• This will incentive users to hang out in the Discord server, hopefully building a community of players

Cons

• We are adding dependencies on Discord APIs and etc.
• Moderation might become a challenge if the discord server becomes busier. But we probably can also get volunteers from the community eventually.

Please let me know what you think!

[ProspectPyxis]

As the one who opened #784, I have quite a few opinions on everything written here.

• The carousel could instead be moved to its own dedicated "public rooms" page, for if someone wishes to find specifically public rooms. In fact, I wonder if a more traditonal list format (similar to what you'd find in various games' server select options) would be a more familiar interface for listing rooms overall? That may be out of the scope of this issue, though.
• I wonder if the matchmaking system - particularly one so intrinsically tied to discord in such a way - is a good idea. I have several points that I want to be considered here:
  • One of its pros - that users won't need to be on the site to see who wishes to play - could actually also be a disadvantage, particularly for mobile users. Switching between multiple applications is often not the smoothest experience, and is why I appreciate the site having a built-in chat system, so that we don't have to jump back and forth between the web browser and another app like discord. To have the matchmaking system tied to discord in the way you suggest would negate this somewhat.
  • This might be just a "me" thing, but while I understand that piggybacking on discord would cut down a lot of effort in maintaining security, it would cut into the self-contained nature of the site somewhat. One thing I liked about this site is how it's something independent that anyone can use regardless of the platform they normally use. To explicitly require discord, and not to mention requiring joining the server to use some of these features, would cut into that independence quite heavily, at least in my opinion.
  • And of course, there's the general concern of adding another dependency onto the site, especially one dependant on an external service. I can't speak much to this since I haven't touched the backend code of the site, but I imagine adding such a big dependency would be something that has to be managed carefully.
• Regardless of what matchmaking system we go with, I actually think that an ELO system wouldn't be a good idea, or at least is something that should be handled carefully. Many games on the site right now are casual games in the end, and it wouldn't make much sense to me to try and "force" them to be competitive by adding ELO, so to speak. Besides, any games with a reasonable competitive scene - such as chess - often already has dedicated sites that are much more full-featured than what we can implement.
• One simple solution to problem 3 is to advertise the server more clearly on the page. Right now, the link is simply listed as "chat" besides "code" and "docs" - two technical items an average user wouldn't bother with. I think it'd be reasonable for the average user to believe the server is primarily technical as well, so if we wish for this server to be more general purpose, we should make this clearer. Other changes may need to be done to the discord server directly, but I believe that's outside the scope of the issue.

Overall, to sum up my thoughts on this issue as a whole... While wanting to build a community and reach out to the players, not just the developers, is understandable, I believe it shouldn't be something that's forced. Locking something as big as a matchmaking system behind the discord server, in my opinion, may be a bit much. There are just my personal views, though.

[vdfdev]

@ProspectPyxis thank you for your feedback! Regarding your concern about forcing ELO on casual games, I agree this wouldn't be ideal. Maybe we should enable competitive mode on a game-by-game basis. And regarding not wanting to switch between discord and the website, this wouldn't be required, if the player stays on the website and someone else clicks on the link, the match would start in the same browser. Discord notification saying that someone wants to play would only be helpful if you are not in the website in the first place.

Some ideas I had to tackle some of your concerns: 1) Maybe we don't need to replace/remove the current public rooms feature? So we would still allow players to find rooms for casual games, and make the new features restricted to few games where competitive/ranking modes make sense

2) Regarding the discord dependency, I agree it isn't ideal. We could instead use email registration, login, etc, but that adds quite a lot of overhead to manage, and IMO it isn't a great user experience. I've also considered switching our server to something like Matrix (a FOSS alternarive to discord, used by boardgame.io now), where we could run our own federated server, using our own login. Technically this seems like a better solution, but I think on the user perspective, many already use discord and etc, and the discord seems more feature rich... But it is a private company in the end :/. We could try to support more than one solution (email AND discord AND matrix), but I am afraid this might split the community and add more complexity. Maybe we can start with a single login approach but prepare for a future where we might support several?

3) I would love to hear more about your suggestions regarding increasing the prominence of the "chat" or "community" button, I agree it is a bit hidden right now. Also, your ideas about a new page listing the public matches seems interesting, I just wonder how it would help with the discoverability of this feature having a separate page...

[vdfdev]

Thinking about it, I think I mixed and tangled together too much 3 independent features:

1) Moving the public room carousel from the home to the game info (aka what I called short term solution) 2) Notifying when someone wants to play on our discord server. We could even add this feature to the current public rooms as-is today. 3) Ranked/competitive game mode. We need to allow some sort of registration in that case, and I was proposing using discord, but we could use other systems too.

[b-hub]

1. Our public rooms features are underutilized.

To me, keeping the list of public rooms on the main page would be the best place - as that's where the most traffic is? However, in addition there could be a way to go to the game first and then choose either a public or private game?

2. Users that come to the home page directly might not realize there is a private room option

When you say private room option, is that from starting a game by specifically navigating to the game first and then creating it from there?

If that is the case and people see a public room option and wonder about where the private rooms are - it might be worth making the '+ New Room' modal have a public/private checkbox, in addition to the list of games. (I may have misunderstood this one)

3. Our community of developers is disconnected with the community of players.

I think this is a great problem to tackle and your suggestion of integrating discord could be the solution! As far as I am aware, developers only get their news about FBG via GitHub and Discord. If you could get people to use the public rooms more, then announcing them via discord would give options to developers to jump in a game with them (maybe the site user could even be made aware that they are playing a dev). That is an exciting prospect, both in terms of real-time feedback that people are actually using your game, but also give the developer a chance to experience the game through regular users.

I do agree that requiring a discord login is a bit restrictive, is there no way to achieve the discord announcements by having some background FBG discord account? So from the perspective of the user, they are just in a public room waiting but the link to the room is shared on our discord by the server's account / bot?

If there is some discord integration (I do see the benefit) it could be presented as an option, rather than a requirement.

Other points

Making the site feel less developer oriented

A simple change may just be to move the CODE and DOCs button into the header (next to the language).

[vdfdev]

@b-hub these are great points and thanks for your feedback! Just want to add a small piece of info: Most of our users come from search engines after organic queries like "checkers with friends" (I think we are the second position on this one, on average), that's why I always focus on improving the website for search engines. But it also means that most users might not notice that there are more games or even go to the home page. That's why adding the carousel to the game info might bring more users than just the home page (even though it is unintuitive to think that the home page isn't actually the most prominent place)

And yes, I think we are getting to a consensus here that forcing the login through discord wouldn't be a good idea, but maybe just notifying when someone wants to play might (without requiring a login).

[ProspectPyxis]

I have some additional thoughts on the matter.

• I think that after our recent chat in the discord server, we can pretty safely disqualify discord verification - it's very likely that the API will be clamped down on further and further, and that would likely simply create too many problems in the long run. Announcing open rooms via discord may still be on the cards, though, as long as it's not required to go on discord to join the game - in fact, from my understanding, it may be possible to just use a webhook for this rather than requiring a full-blown bot.
• The confusion with creating public/private rooms could easily be fixed either by the public/private room checkbox as suggested by @b-hub, or simply getting rid of the "New Room" button outright and just giving an option to create a private or public room right in the game select page itself.
• Public rooms overall are in a strange place. I believe that the most common use case for the site is not to find new people to play games with, but instead to play games with their existing friend group. With this in mind, it makes sense that most rooms created would be private ones. However, I fully understand and agree with the desire to build a player community around our games, and I believe that, simply put, we need to advertise our community more on the site. There are many ways we can do this, but some thoughts that I had are...
  • Make the link to our discord server more prominent (rather than just being alongside the technical "code" and "docs" button, as I said earlier), and make sure it's clear that the server is meant both for developers and players.
  • Announce our intentions somehow. As I said, since the common use case of the site is to play games with existing friend groups, we should make it clear that we also wish to encourage our various players to meet each other, rather than simply play with who you know. We could also, for example, have a snippet of text encouraging people who find our site to create and join public rooms with other players and have fun. There are probably better ways to do this, but I'm just giving some examples to show the general idea of what I'm going for.
• As an alternative to public rooms or the ranked room system, we could look into implementing a sort of "quickplay" function, where you would select a few games that you would like to play, and if enough people happens to want to play the same game, they'll automatically be matched up. This has its advantages and disadvantages over our current public rooms system, and if this sounds interesting, I'll give more details in a separate comment - I don't want this one to be too long.

[vdfdev]

@ProspectPyxis I agree with your points. I like your idea about only removing the button to avoid confusion. It seems more elegant than having an option to create private rooms in the "public rooms" section.

I think this gives us enough to work with for a while. We can focus now on improving the prominence of the existing public room feature, and advertising more the discord channel for players. Then, after we do that we can revisit the topic about new features like "ranked" play. And I would love to hear more details about your "quick play" idea.

[ProspectPyxis]

I'm glad you like my thoughts! Either way, this is my current draft for quickplay:

The user will select a group of games they want to play, and once they do, they'll be put into a "queue" of sorts. Once enough players want to play the same game, they'll be automatically matched up into a room to play together. As an example, Player A wishes to play Rota, Chess, or Bombs & Bunnies, and selects those games to join the quickplay queue. Meanwhile, Player B wants to play Chess or Sea Battle, and joins the quickplay queue with those games selected. Now, the system detects that both Player A and Player B wishes to play chess, and as it's a two-player game, there are now enough people wanting to play chess to start a game - and thus, Player A and Player B are matched up automatically for a game of chess.

Advantages

• Allows more flexibility in game choice - players can select a list of games they'd like to join in on, rather than having to decide on a single game.
• Since quickplay is obviously meant for people who just wants to play the same game, regardless of friend group, this could be a nice tool to encourage a community around our games. Plus, it also avoids the problem of rooms not really meant to be public, since quickplay games are always randomly matched.
• Matchmaking should hopefully feel snappier than creating a room and hoping someone joins in sooner or later. Though, this won't mean much if not many players use this feature still...

Disadvantages

• Less control over the game - with quickplay, there's no real "host" in the room, and thus, no one can really change the rules beyond the default. This could be big for a game like, say, Secret Codes.
• Less control over players - handling the amount of players in a quickplay game for games with variable amounts of players could be a problem. Also, there's no way to guarantee that in a quickplay match, you'll at least end up in the same game as a friend alongside some other players.

There are likely other advantages and disadvantages I haven't thought of yet. Besides, despite me listing advantages and disadvantages, there's no reason this couldn't be implemented alongside the current public rooms system rather than as a replacement.

[vdfdev]

I like your idea of streamlining the matchmaking process, i.e. avoiding the whole room interface and making it automatically match the players. This is very similar to what I had in mind about the "ranked", but the ranking itself can be independent of the matchmaking.

The only thing I'm not so sure about your proposal is the idea of "selecting a group of games". I think this might add a ton of complexity on the UI, on the backend and on the messaging. And most users might know only a few games, and the most likely scenario is that they want to play a single one. If instead we only show a list of games other users are trying to play right now, then the other users can make the decision by themselves if there is any intersection to what they are willing to play?

I.e. my idea would be to simplify current public rooms UI to only say "X players want to play now", and have a single "play" button for each game... And in each game page you can have a "quick play" option. I am not sure if we need to add the complexity of selecting a list of multiple games and so on...

Ps: sorry for closing the issue, fat finger

[ProspectPyxis]

Definitely an understandable concern. My idea with the "selecting multiple games" part is to make it flexible for the players who may have a choice of games they wish to play, but it also makes sense that most players would normally only want to play one game at a time.

I actually really like your idea of simplifying public rooms - in fact, we could easily combine that with the "put the public room carousel in the game info page" idea. Taking into account what you've said about how players normally find the site, this could actually improve how much public rooms are used overall, though the problem of wanting players to explore other games as well still remains.

[vdfdev]

Because an image is worth a thousand words, I made some quick mocks to illustrate what we are discussing.

First iteration

• Removes new room button from home page

• Adds carrousel to the game info page

Second iteration

• Simplifies the UI to only show how many people want to play some game, and a button to join them

• Avoids the whole room UI for matchmaking purposes

[ProspectPyxis]

That certainly looks neat so far! Though, I have a couple comments on this still.

• Just as a little thing, the "New Room" button should probably explicitly say "New Public Room", while the "Online Friend" card should say more clearly that that's how you make a private room.
• One concern I have with getting rid of public room UI outright is that we may lose the ability to configure the game - for example, the words list in Secret Codes, or the amount of players in the game. We could just enforce a "standard" configuration for every public quickplay game, but certain players may still wish to do something different while letting others join in.
• Instead of a timer, would it be viable to just keep the user waiting until either a match comes up or until the player hits cancel themselves? I could see this as potentially opening up too many loose connections, but at the same time, it'd reduce the hassle of having to press "try again" every 3 minutes or so.
• As a quick addition, what about making a sound or at least an alert notification when a match is found? This way, the player can switch to doing other things while they wait for a match, knowing that the site will notify them once one is found.

[vdfdev]

• I agree we should make the button clearer. I was thinking even to move the button to be inside the card (or maybe we could make a card outline which is a button to create a game...)
• Good point regarding customization. In that case we don't have the concept of host player (which is who can set the customization parameters now), so we will need to figure out an alternative, if any.
• My fear of not having a timer is that the user might just close the browser or forget the tab open, and then the next player will connect with someone who isn't even active anymore... But I agree it is annoying to have to click on try again
• +1 for sound. We also need to add sound to chat messages, it would help with the current state too for users noticing that someone joined. Maybe we can priotize this as it shouldn't be a lot of work

[vdfdev]

FYI, the first iteration is done and I will be pushing it to production tomorrow morning, with the new Skat game.

By chance, I found this video online: https://youtu.be/IgbZgY9J7ng

Which made me think that I might be neglecting this use case of several-days-long games. In order to support it, I think we should bite the bullet and have a registration in place, so we can notify users (by email, for instance) when it is their turn to play. We should also add a list of active matches in the home page, so they can come back to the game easily. However, I still believe that tying our service to Discord is not a good idea, so I think we should rely only on e-mail for registration. We can make it super simple by just asking for an email, and sending an email to the user with a link, that when clicked assigns that device to the user account (no password needed!).

I think we should change the second iteration a bit by giving the user two options: either "quick play" -> 5 mins max for each turn or "long play" -> 1 day for each turn (lol, maybe we can word it better). But the idea is that some users want to play several game over several days, and we should support that.

[tuxor1337]

The perspective of the yucata.de platform you mentioned is very interesting: You play asynchroneously, you may come back to the game at any time etc. However, I'm wondering whether you really need a sign-up for that.

Just think of the polling tool Framadate: When you create a poll with Framadate, providing a mail address is optional. The poll is removed automatically after a certain period of time. There is an admin-link and a public participation-link for each poll. Each participant will enter a poll via the public participation link and, upon voting, will get an individual link (with a hash), so that users are able to come back later to change their own vote. Emails may be optionally provided by participants to send the individual link to that address.

By the way, this has the potential to also fix #702:

• Each match has a public link to enter as a new player. After entering a match, an individual link is created for each player so that players can come back and impersonate that user to continue playing as that user at a later stage.
• When the same player is impersonated from different sessions (devices) at the same time, we have to decide on a way to deal with it: Can all devices that impersonate that user make moves on behalf of that user? Will this create a problem of race conditions or is this non-critical because we deal with these kinds of problems already now in the case of game stages where several users are active at the same time? Or do we want to restrict move-making to the most recent impersonator of each user?

[ProspectPyxis]

I suppose for the registration/logging in, you're looking to implement something like a "magic link" system? I unfortunately don't really know much about those ends of things, but it should at least be a little easier on us to not have to directly store passwords in any way, I believe.

The idea for short-form and long-form games is definitely interesting and could be good. I do have a few points to raise about it, though:

• Quite obviously, games that are timed by default (like Bingo) would not work in the long-form format, which is something to consider.
• Unless the plan is to abort the game outright if a player fails to make a move within the time limit, we'll have to consider how each game handles having a player's turn skipped - especially if the game doesn't have a simple round robin format where you can just skip a turn. I believe this could be handled by having an AI take over for the turn, though that's just one suggestion that may still have its problems.
• Regardless of whether we go with this or not, I've always thought that a timer in public rooms would be a good idea to prevent a player from simply holding up a game forever.
• I wonder if notifying by e-mail is really the best idea? There's nothing wrong with it inherently, but I feel like a more dedicated solution - like, say, a web browser extension that connects to the site - would work better as a notification system than constant e-mails.
• I wonder if more fine-tuned time controls is something we can look into in the future? In particular, I'm thinking about chess, which can use various time controls to create very different experiences depending on how fast you wish to play. Though, that might work better once boardgame.io implements a dedicated timer.

Other than that, there are the infrastructure considerations, like how we'll handle room creation (the quickplay system doesn't quite work with long-form games the way we've planned it), and old problems like how we'll handle customization if a room doesn't have a "host" still remains. That said, I do still think this could be a good thing to implement to the site.

[vdfdev]

Thanks for the feedback folks!

@ProspectPyxis great point about timers, and I totally agree with you that we need a per-game behavior configured for what to do when the turn is lost. I am also a contributor on the boardgame.io project, so I will see how hard would be to add support there for timers. The bingo timer was a bit hacked together, relying on the users browsers to enforce the timer... Regarding notifications, most browsers nowadays support native notifications, so we could leverage that too. But I still think that e-mails can be useful, and as a login mechanism it is better than relying on third parties like discord, facebook, and etc.

@tuxor1337 I like your idea of authentication by links, but I feel like not coupling this with e-mails is just a worse user experience? If a site gave me a link to authenticate another device, I would have a hard time moving this link around to my desktop or laptop, I would probably end up e-mailing myself the link or pasting it somewhere like Google Keep. So I guess that most users are already familiar with the concept of confirming their email which would be all that's necessary to link another device together? Also, we really don't want users to send this link to other people on social networks and etc, as it would allow other people to impersonate them. So I still think e-mails are the less worse solution.

With that said, I believe that not having to login is one of the best things about FBG currently. We definitely don't want to enforce login for any existing game modes, and maybe not even for the "quick play" mode. But for "long play" that it will happen over several days, I don't see how to make that happen without some reliable way to reach back to the user when it is their turn.

[tuxor1337]

@tuxor1337 I like your idea of authentication by links, but I feel like not coupling this with e-mails is just a worse user experience? If a site gave me a link to authenticate another device, I would have a hard time moving this link around to my desktop or laptop, I would probably end up e-mailing myself the link or pasting it somewhere like Google Keep. So I guess that most users are already familiar with the concept of confirming their email which would be all that's necessary to link another device together? Also, we really don't want users to send this link to other people on social networks and etc, as it would allow other people to impersonate them. So I still think e-mails are the less worse solution.

To switch from a desktop to a mobile devices, a QR-code of the link would work. And of course you can also give the user an option to enter an email (that is NOT stored on the server) where the link is sent. As I said: Just have a look at how it is implemented currently in the polling tool Framadate.

[vdfdev]

But then if the users want to enable notifications by email, they would need to enter again the e-mail somewhere else? I just feel like this is not a great UX :/, and also having just an email it isnt super sensitive information.

[tuxor1337]

Okay, those are two different things: If you want to enable notifications via mail, then you have to store the mail, of course. But if you only want to have the link sent to you via mail in order to switch, e.g., from mobile to desktop, then there is no reason why you would have that email be stored on the server-side. I don't understand why that is a problem for the UX. En contraire, it's a bad UX if you need to log in or disclose your mail address even though that's not strictly necessary for a particular functionality.

For many mini-game web pages out there, there is a bad habit of requiring to register with your mail address even if you only want to play a quick game with friends. As you said, not having to sign up is one of the best things about FBG. And it would be even better if we would avoid these kinds of things for new functionality going forward.

[vdfdev]

"bad habit of requiring to register with your mail address even if you only want to play a quick game with friends" -> I 100% agree with that, and we are not changing anything about it in this case. Just to be clear, the topic here is when you want to play several games over several days.

My only fear of not requiring e-mail to play such a long game is that the user will not enable notifications, and then they will forget to play, and then it will be a bad experience not only for them, but for all the people in that match that got cancelled/skipped/etc because of this. And even if the user remembers to come back on the same device, if you increase the probability of such thing happening, at some point in a game with many people over many days, it will happen :/

[vdfdev]

But I guess we could avoid e-mail if we ask users to enable notifications before trying to find a match (could be the browser notification too)...

[tuxor1337]

No, it's fine! I think we actually didn't have a disagreement in the first place. :slightly_smiling_face: I totally support presenting the user with an option to enable email notifications. I even agree to nag the user about it (big text: "hey, please enter your email address here to stay up to date about other users' actions in this match", small button: "no thanks"). But, ideally, the user should have some way to decline if it's not absolutely necessary to collect the mail address. That's all I'm saying.

[vdfdev]

Sounds good, Im in favor of this alternative hehehe :). Also we can re-use the notification flow if users want to (optionally) enable them for other game modes too.

[ProspectPyxis]

So while digging through some old issues, I've found #461, which actually mentions the exact concept we're discussing now. I'll leave it here as a related issue, even if it doesn't add many details to what we've already discussed.

[vdfdev]

I've added a toggle "is_public" to http://stats.freeboardgames.org ... We are seeing a 35% increase in public rooms on the last 14 days, and a 60% increase in the last 7 days, vs 0.9% and 13.4% increase in all kinds of rooms respectively. So it seems like more users are using public rooms now :). I will keep investing in making the experience better, there is still a lot to improve.

[cwatsonc]

Would it be a good time to add/condense this dialog into a roadmap that could help the users envision our direction? I think it was @richardaum who created a user facing facility for gathering game experience/bugs/feature requests -- I think we should pin our thoughts somehow at the preamble to that discussion so users could upvote most requested features/patches/bugs etc. Reading through this dialog is a good first draft but we should try and condense and make it more digestible as we decide where to apply effort /$0.02