#1 by Maeva
Hello oTree devs, I'm developing an experiment with the following structure: - 20 subjects per session - 5 different games (each subject must play with 5 different partners: one partner per game) - Random game order (e.g., subject 1 and 2 might play game #1 first, while subject 3 and 4 start with game #5) - Each game has 10 rounds - There is dynamic re-matching of subjects between games Currently, most of the backend is working. I have two main apps: game_app: Handles the actual gameplay wait_and_match: A kind of waiting room where subjects go after finishing a game, to wait until they’re re-matched. This app uses live_method and implements intelligent matching logic based on these key rules: 1) Subjects cannot be matched with the same partner twice and 2) Newly paired subjects must be assigned a game that neither has played before (e.g., in their second game, subject 1 may be matched with subject 4 to play game #3, while subject 2 and subject 3 play game #4 together) Originally, I structured the experiment using an app_sequence like: game_app → wait_and_match → game_app → wait_and_match... But later realized oTree doesn’t allow duplicate apps in the app_sequence. Creating multiple versions like game_app1 → wait_and_match1 → game_app2 → wait_and_match2... isn't ideal here, as I need a single, persistent matching system that maintains a global state across the entire session — this logic is critical for the experiment. Given that, I’m trying to figure out: Is it possible to implement a single, persistent waiting room that: Runs concurrently for all subjects between games Can match players regardless of where they are in the app sequence Sends back players to the game_app Or are there alternative approaches that would be better suited for this design? I’d really appreciate any suggestions on how to structure this efficiently in oTree. Thanks in advance for your help — happy to share more technical details or the GitHub repo if that’s helpful!