I'm looking to make a web-app/game where people do not need an account to play, but the game is room based, and once the game has started the room closes. I'm most familiar with Spring/REST services as a back-end.

The best example for this type of system is the Jackbox Games backend (Quiplash, Drawful, etc). The way theirs works is:

  1. Go to landing page
  2. Enter desired username and also a "room code" of the room to join (note: anyone can join, no account needed)
  3. Click start game when all users are in
  4. Play game, no more users can join

Anyone have any ideas of how to approach this?

I'm familiar with having users authenticate against a database on a login call to the server. And also I'm pretty familiar with how I might pass around payloads via JWT, but I'm having a bit of trouble piecing together how I might create the rooms and then close them. Also keeping users "logged in" until the game ends.

Any suggestions would be wonderful.



2 Answers 2


Keep a list of room codes for opened rooms, and when the game begins, remove the room code from the list to close it

You can keep the room codes for currently open rooms on the server-side in some sort of a list. Any room which is open for joining will have its code on this list, whereas any room which hasn't been created yet or is not open for joining does not have an entry on that list.

Room joining flow

  1. When user enters the username and room code, you check whether the room code is present on the "open rooms" list. If it does, you add the user to the list of users waiting for the game in a room to begin.
  2. When all players have joined, the game begins. You close the room by removing its entry from the "open rooms" list. Players start playing now.
  3. No-one can now join the room, as the "open rooms" list no longer has an entry for it. The room code is no longer valid for anyone who wants to join, so the room is effectively closed to everyone outside of the game session.

(Note: this assumes that there are no passwords for individual user accounts. In this case a separate user authentication feature needs to be added, as otherwise users can pick any username they want.)

  • \$\begingroup\$ Thank you! That is the flow I was describing, yes. There are no passwords. That method seems like it will work for the management system for closing rooms. But that's not really what I was having trouble with. I guess my question from above was mostly about how to keep the user logged in. So from what you described, the server knows what user belongs to which room. but how do subsequent calls to the server work? How does it know which user the client is? Does it bass back a UUID/token on room join, and the server and client pass this back and forth to verify the user's identity? \$\endgroup\$ Commented Jan 31, 2017 at 16:07
  • \$\begingroup\$ @drewtenenbaum A UUID/token could be a good idea, but if you're already letting users pick (unique) usernames, you could just as well use the combination of the username and room code to identify the user on each request - this way you don't need to generate them yourself and you don't need a separate table/list for the UUIDs/tokens. Anything could be used for identification as long as it's unique (to avoid collision) and fairly short (so that you don't have scalability issues if serving hundreds of users). Is this close to what you had in mind? \$\endgroup\$
    – Pabru
    Commented Jan 31, 2017 at 22:17
  • \$\begingroup\$ Yes. That's sorta the route i want to take. It seems simple enough, but what's stopping people from spoofing other users if they wanted to , assuming they know the roomcode? Also if i navigate away from the page, am i forced to re-enter my username/roomcode? \$\endgroup\$ Commented Feb 1, 2017 at 20:21
  • \$\begingroup\$ I could send back a hash of the Username and roomcode and store it in the cache/cookies, so that if the user needs to refresh or "log back in" while the game is still going, they can check to see if this was the same device, and then let them in, otherwise, they will be denied. That would stop spoofing, no? \$\endgroup\$ Commented Feb 1, 2017 at 21:06

From your comment on the other answer you are saying that you are primarily having trouble about how to keep the user logged in.

From the games I've worked on, a standard practice is to create an anonymous player account when the game is first loaded using a randomised identifier and secret. You then log in by providing these access details to the backend server in exchange for a session token that can be used to authenticate subsequent requests. Session tokens are usually time-limited and must be refreshed using the original identifier and secret.

You've mentioned JWT tokens - they are indeed a good way to handle session authentication for these types of services. One of the main benefits of JWT is that the tokens are stateless, so you server does not need to maintain a list of valid tokens - this has scaling benefits as there is no need to maintain a central store amongst all your servers.

The JWT standard also contains built-in support for token expiry times. There are many libraries available for validating and constructing JWT tokens. One the disadvantages of JWT is that there is n oway to invalidate an existing token, aside from maintaining a list on your server and checking that list every time you validate a token.

Alternatively, you could also use an existing game backend service to store your player accounts and your room list. These will come with login and authentication support already and could simplify what you are trying to do. ChilliConnect offers both these features. Full disclaimer: I work for ChilliConnect.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .