On a website users (members or guests) can play a browser game against other players.

Members can choose between two actions:

  1. They create a new game and wait for other users to join.
  2. They join a random existing (waiting) game. When a user chooses to join a game and no games are waiting, he automatically gets redirected to game creation to start a new game.

For guests, only the second option is available. They have to try and join an existing game. Only if no games are available, a guest can create a new game.

But here is the problem: What if a new game opens up while the guest is presented with the option to create a new game?

Is there any good way to handle such a situation?

Here is a timeline of the problem for clarification:

Timeline of the problem

Technically, the user is not allowed to create a new game when he finally submits his options. But I feel it would be wrong to just disallow him from creating his game at that point.

I thought of multiple different ways to handle this case:

  1. When a guest tries to join a game and fails, a variable in his session called mayCreateOneGame is set to true. While that variable is true, the user is allowed to create a game. When he has created a new game, the variable is set to false again. But: What happens when the user does not immediately create a new game but rather comes back an hour (or a day) later. Should he still be allowed to create the game?
  2. When a guest tries to join a game and fails, a variable in his session called failedToJoinAt is set to the current timestamp. While the timestamp is no older than - lets say - five minutes, the guest is allowed to create a game. But: What happens if the game creation takes the user longer than that time?
  3. When a guest tries to join a game and fails, he simply is told to wait until a member created a new game. But: That might take a long time and be no fun for the guest, who just wants to play.
  • What is the problem with the guest creating the new game in the circumstance you have described?
    – Varedis
    Jul 23, 2015 at 7:54
  • @Varedis Without some kind of session variable, I have to check again if games are available when the guest submits their options (the game creation would then fail in this scenario, as there is a new game available). When using some kind of session variable, the problems of point 1. and 2. in my question occur.
    – Lars Ebert
    Jul 23, 2015 at 8:08
  • But why would the game creation fail? You have given them the option to create a new game, why can't you respect that and let them create the game, regardless of what has happened in the meantime?
    – Varedis
    Jul 23, 2015 at 8:37
  • That is exactly the problem: Do they have the option to create exactly one game, no matter how much later? Do they have the option to create a game, but only in the next five or so minutes?
    – Lars Ebert
    Jul 23, 2015 at 9:15

2 Answers 2


If I was the user, I would expect to get presented with a create game screen, if I stay on that screen for 5 seconds or 5 days it shouldn't matter, when I press the create game button it should be respected and the game actually created.

However, if I leave the create game screen and try to go back, it should check for games again before presenting me the create game screen again.

There is probably a wider question you need to ask yourself, which is, why are you only giving guests the chance to create games under very specific circumstances? It seems like all your problems would go away if they had the option to create and join games at any point they wish. Give them some other incentive for signing up, such as saving progress or achievements.


Solve the problem with a dialog

Here's how it could work: you run a check for available games once again, when the user clicks the "Submit" button — no matter how long it took him to fill in the form. If at that point there's another game available, you present him with a dialog: "Meanwhile, another game has become available. Would you like to join it?"

You can make this dialog imperative (no "Cancel" button, wording like "Join the new game") if the policy is strict — looks like it's your case. Or it could be suggestive, with an option to persist and create his own new game.

  • 2
    ... and before the user agrees to join the meanwhile available game, that game has ended :) Jul 23, 2015 at 11:13
  • Why no "cancel" button? I would think "Cancel" should return the user to the configure-new-game screen, in case the user notices how the new game is configured and wants to adjust his settings as a consequence?
    – supercat
    Jul 23, 2015 at 19:36
  • @HagenvonEitzen Yes, this all shows how ephemeral such environments are ;) Jul 24, 2015 at 12:49
  • @supercat That's a great idea for some games where users are incredibly sensitive to the game settings. But might be too much for games like tic-tac-toe :) Jul 24, 2015 at 12:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.