super-groups and sub-groups

342 views
Skip to first unread message

Robert Heck

unread,
Jun 8, 2021, 10:38:50 AM6/8/21
to oTree help & discussion
Hi,

I would like to create a super-group of 8 people, where the participants are split up in  4 leaders and 4 subordinates.
They then solve a two-player task - one leader vs one subordinate. Afterwards, in the following rounds, that task should be repeated by performing cyclic permutation of the leaders or subordinates and create new pairings, accordingly.

I figured I could make an oTree group with 8 participants and then a sub-group splitting within. However if I want to include waitpages for the two-player task, these have to wait always for all 8 participants to come to that certain step, or am I missing something?

Would the only other possibility be live pages, or are there alternatives?

I tried also to define oTree groups of only two and triggering set_group_matrix through after_all_players_arrive on the group level (yes, having a super-group of 8 would trigger that function 4 times for the super-group). This however did not work properly and lead to incomplete pairing with some players stuck at the waitpage responsible for the pairing.

Thanks!
Best,
Robert

Chris Crabbe

unread,
Jun 8, 2021, 11:45:58 AM6/8/21
to Robert Heck, oTree help & discussion
Hi Robert -

If nothing about your matching scheme requires data from *during the session* you can just call set_group_matrix inside creating_session, which is run entirely upon session creation before any participants connect.  So if you set your players_per_group to 2, and assign the groupings for every round before any participants arrive, nobody needs to wait for the supergroup members.

You haven't described how the supergroup of 8 is used.  If some supergroup-level stats or results are being displayed or something you may have to use a WaitPage with wait_for_all_groups = True to wait for everybody to catch up before running those calculations.

Thanks,
--Chris

--
You received this message because you are subscribed to the Google Groups "oTree help & discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to otree+un...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/otree/1beace55-7d08-40dc-8757-d5d7a13c0a4dn%40googlegroups.com.

Robert Heck

unread,
Jun 9, 2021, 4:22:11 AM6/9/21
to oTree help & discussion
Hi Chris,
thanks for your reply! I try to be more specific: the experiment is supposed to be deployed online together with a presurvey and potential drop-outs. As such I don't see how I can use set_group_matrix inside creating_session.
The individual supergroups are independent of each other and the final total participant number is not fixed. The idea of having the supergroups is to be able to have some aggregated stats for all leaders/subordinates in the supergroup across multiple games, but also to be able to track the individual player and potentially look for more subtle individual effects. So there is no need for wait_for_all_groups.
For the start, the 2-player task is supposed to be quite simple and is only about typing in some numbers each and waiting for each other, but we might make it more complex later. Therefore I'd like to circumvent that the 8 players have to wait until all are finished with their task and have the actual task somehow run as a 2-player task.
So it is the uncertainty of only knowing on runtime who will be part of a 8 player supergroup, but the actual task being only a 2-player task, that I try to solve in an as elegant way as possible.
Did that help to understand what I try to achieve?
Thanks!
Robert

Robert Heck

unread,
Jun 9, 2021, 4:37:26 AM6/9/21
to oTree help & discussion
And to be clear. The payout/score is depending on the responses in the 2-player task and should be calculated ideally at the end of each round and displayed to the players.

Robert Heck

unread,
Jun 9, 2021, 11:45:37 AM6/9/21
to oTree help & discussion
I found a nice solution that seems to work. I use the approach of group_by_arrival_time_new_partners from the oTree snippets.
The difference in my case is that I predefine the desired pairings by participant id in a separate "waiting app" before, which is then appended to a list of pairings stored as a session variable to be able to transfer it to the main app. Likewise I assign a unique group id as a participant variable to each of the players that are grouped in a supergroup.
The pairing is triggered as soon as the wanted supergroup size is reached (I guess I do not necessarily need the separate waiting app, but I do also some activity/dropout checks here).
Reply all
Reply to author
Forward
0 new messages