# Managing Games Games are KC7 modules deployed inside a classroom. Each game is an independent clone of a core module with its own join link, roster, analytics, and settings. ## Overview A classroom can hold any number of games. Core modules (like "A Scandal in Valdoria") are master templates. Games are instances cloned from those templates for a specific group or event. Each game gets: * **A unique join link** that participants use to access the game directly. Works without classroom membership unless you configure otherwise. * **An independent roster.** The same person can be enrolled in multiple games, and each enrollment is tracked separately. * **Separate analytics.** Performance, completion, and scoring stay isolated per game, so the same module can run multiple times without mixing data. * **Independent settings.** Time limits, scoring, hints, auto-assign, and access controls are configured per game, even across clones of the same module. ## Creating a Game 1. **Navigate to your classroom** from the tenant dashboard. 2. **Click the "View Modules" tab.**
3. **Click "Create Game."** 4. **Configure details.** Give it a name (e.g., "February 2024 - Valdoria") and pick a core module from the dropdown.
5. **Click "Create."**
The new game shows up in the classroom's module list. From there you can copy the join link, open settings, view analytics, or manage students. ## Sharing Game Access Three ways to get participants into a game. ### Direct link Copy the game's join link and send it however you like (email, LMS announcement, chat, QR code on a handout). Clicking the link sends the participant straight to the game. New users are prompted to create an account, returning users get in immediately. Good for one-off events or when you want manual control over who receives the link. Gets tedious if you're managing many games or frequent cohorts. ### Classroom join link Share the classroom's join link and password instead. Participants who use it become classroom members, and any game with auto-assign on enrolls them automatically. Useful for ongoing programs. A semester course can add students once at the start, then enable auto-assign on each week's game when it's time to open it up. Watch your auto-assign settings so participants don't see content before you're ready. ### Manual assignment Open the game's Students tab, search by username, and add participants individually or in batches. They get enrolled in that game only. Best for small groups, controlled cohorts, or selective access. Doesn't scale to hundreds of participants but gives you a clean audit of exactly who was added when. ## Game Lifecycle ### Active games While a game is active you can monitor participation in real time, watch the live scoreboard, track completion rates, and export results. ### Completed games After an event ends, results and analytics stick around. Participants can return to review their work. Join links keep working unless you disable them. ### Archiving To take a game out of active view, open its settings and disable or delete it. Participant data stays in exports, and analytics remain available through dashboard history. ## Multiple Games Strategy How you organize games depends on what you're running. ### Same module, different dates Create a fresh instance each time you run the same module. Each instance has its own roster, dates, and analytics, so March participants and April participants stay separate even though they're playing identical content. Name games with the date so they're easy to find later: "March 2024 - Valdoria", "April 2024 - Valdoria". Historical analytics across runs help you anticipate where future cohorts will struggle. One thing to know. Participants who complete an instance can't replay it in another instance to improve their score. If you have repeat players across months, consider rotating modules. ### Different modules, same classroom Stack multiple modules in one classroom to build a learning path or progression. For example, start with "A Scandal in Valdoria" as an intro, follow with an intermediate module, then an advanced capstone. Create all the games up front but keep auto-assign off until you're ready to open each one. Name them to reflect sequence and difficulty, e.g. "Week 1 - Beginner - Valdoria", "Week 4 - Intermediate - Network Analysis." The win here is cohesive tracking. Classroom analytics show each participant's progress across the whole program in one view. ### Multiple classrooms For larger or more complex programs, split games across classrooms. Common patterns: * **By organizational unit.** Separate classrooms per department, team, or grade level. * **By skill level.** Beginner, intermediate, and advanced classrooms with different managers and content. * **By time period.** "Fall 2024 Section A", "Spring 2025 Section A". Clean separation between terms makes archiving easy. * **By program type.** "Staff Training", "Student Course", "Community Events". Different lifecycles, different management needs. More setup, more permission management, but better structure at scale. Analytics get segmented but more meaningful since the data is organized by the dimension you care about. ## Game Organization ### Naming conventions Use descriptive names that include date or cohort, the module, and any context you need. * ✅ "Spring 2024 Intro - Valdoria" * ✅ "Employee Onboarding Q2 - Valdoria" * ❌ "Game 1" * ❌ "Test" ### Auto-assign Turn auto-assign on when all classroom members should access the game, you're running recurring events, or you're managing a large cohort. Keep it off for games scheduled later, when you want to limit access to specific participants, or when you're running multiple simultaneous tracks. See [Game Settings](/using-the-tenant-system/managing-games/game-settings.md) for the full auto-assign configuration. ### Pre-planning events Create games in advance for semester schedules, recurring monthly or quarterly events, and multi-week programs. Control access using the auto-assign toggle, manual assignment, or scheduled link distribution. ## Troubleshooting **Participants can't access the game.** Check that the join link is correct and complete, the game isn't disabled, participants have KC7 accounts, and classroom membership is in place if you're relying on auto-assign. If the link is broken, regenerate and reshare it. If a participant didn't make it in, add them manually. **Wrong module selected.** If nobody has played yet, delete the game and create a new one with the right module. If participants have already started, the module can't be changed. Create a new game, share the new link, and keep the old game around for its data. **Duplicate games.** Review the module list, archive or delete extras, and tighten up your naming convention. Deleting unused games doesn't lose any participant data. ## Related Documentation * [Game Settings](/using-the-tenant-system/managing-games/game-settings.md) - Configuration options * [Organizing Classrooms](/using-the-tenant-system/managing-games/classrooms.md) - Classroom structure * [Performance & Analytics](/using-the-tenant-system/analytics.md) - Game analytics and data *** [Back to Tenant Overview](/using-the-tenant-system/overview.md) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.kc7cyber.com/using-the-tenant-system/managing-games.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.