Admin panel shows wrong number of players for treatments in a batch

[malsobay]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

In the admin panel, when looking at an ongoing batch, the "Player count" column of the table shows the number of players connected to the instance and randomized into that treatment. The expected behavior is that it shows the number of players as defined by the treatment, not the connected participants; the latter may be useful to users, but should be in a separate column imo.

Once the lobby is full and the game launches, it does show the correct number of players, presumably because the others are kicked.

Steps To Reproduce

1. Create a new experiment
2. Create a batch with one game of the "solo" treatment from the default Empirica experiment
3. Connect to the pre-lobby using two incognito windows in diff browsers.
4. Check the admin panel -- it's a solo condition, but you'll see two connected players.

Empirica Version

Version: v1.9.9
SHA:     cbccdb7
Build:   201
Branch:  main
Time:    2024-03-24T08:25:31Z

Client:  1.9.9
Server:  1.9.9

What OS are you seeing the problem on?

macOS, Linux

What browser are you seeing the problem on?

Chrome, Safari

Relevant log output

No response

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[frasalvi]

I always assumed that this was a feature and not a bug: in general, games keep accepting players without a limit, until playerCount players have completed the intro steps and hence the game has started (cf.

empirica/lib/@empirica/core/src/admin/classic/classic.ts

Lines 83 to 92 in cbccdb7

	let availableGames = [];
	for (const game of batch.games) {
	if (
	!game.hasStarted &&
	!game.get("starting") &&
	(!skipGameIDs || !skipGameIDs?.includes(game.id))
	) {
	availableGames.push(game);
	}
	}

, notice that there is no check on the number of players).

To avoid this, I think the best way would be to resort to disableAssignment=True. At least. that is what I do, so in case you are interested I'm happy to share some pointers.

Edit: After reading the issue again, I may have misinterpreted what you were pointing out. That is, the problem seems to be just what is shown on the Admin console, and not actually the fact that more players than playerCount can be temporarily assigned to a game before it starts. I will leave this comment anyway, in case someone stumbles across this issue and is confused about that behavior.

[npaton]

There can indeed be what I call overbooking during assignment. But, for a playerCount of 1, once the game has started, it should only show 1 player. @malsobay Could you send me your tajriba file? Thanks!

[malsobay]

@frasalvi Thanks for sharing -- the issue is indeed just what's reported on the admin panel, not the actual assignment behavior.

@npaton Once the game has started, it does indeed only show 1 player. But I think this is confusing because before any players join, the column doesn't say "0" players... it says "1", which is the number of players defined by the treatment. The current behavior makes it difficult for the person administering the experiment to gain an accurate idea of how many more people they need to funnel in -- this is why I assumed it was an unintended bug. The behavior in v1 was a lot clearer: you could see all the connected people as icons, but the number shown in the "Player count" column was always that defined by the treatment.

This would be made unambiguous by changing the column to be "Connected/Required Players", e.g. if a treatment requires 2 players but has been overbooked with 5, it would show "5/2", and then change to "2/2" once the game launches. Even if a game's lobby is set to ignore incomplete games, this notation makes it a lot easier to see when that's the case (e.g. "1/2" if only one player connected and the game launched anyway).