Managing Games
Games are KC7 modules deployed within a classroom for participants to play. Each game is a clone of a core module that can be configured and managed independently.
Overview
A classroom in KC7 can host an unlimited number of games. Each game represents an instance of a core module - think of core modules as the master templates (like "A Scandal in Valdoria"), and games as individual copies of those templates that you deploy for specific groups or events.
When you create a game, the system clones the selected core module and creates an independent instance with its own characteristics:
Unique Join Link: Every game receives its own URL that participants use to access it. This link remains consistent and can be shared via email, learning management systems, or any communication platform. The link works independently of classroom membership, meaning participants can access the game directly without first joining the classroom (though you can also require classroom membership through settings).
Independent Participant Roster: Each game maintains its own list of enrolled participants. This means the same person can be enrolled in multiple games within a classroom (or across classrooms), and each enrollment is tracked separately. When you add participants to a game, they gain access to that specific game instance only, not to other games in the classroom unless those are configured with auto-assign.
Separate Analytics and Results: Performance data, completion rates, scoring, and all analytics are tracked per-game. This isolation allows you to run the same module multiple times with different groups while keeping their data completely separate. You can compare results across different game instances if needed, but each maintains its own independent dataset.
Configurable Settings: After creation, each game can be configured with its own settings including time limits, scoring rules, hint availability, auto-assign behavior, access controls, and more. These settings are independent from other games, even if they're clones of the same core module. This flexibility allows you to run a beginner-friendly version and a competitive version of the same content simultaneously.
Creating a Game
Step-by-Step Process
Navigate to your classroom
From the tenant dashboard, select the classroom where you want to add a game
Access the modules view
Click the "View Modules" tab in your classroom
Create new game
Click the "Create Game" button
Configure game details
Provide a name for the game (e.g., "February 2024 - Valdoria")
Select the core module you want to clone from the dropdown
Confirm creation
Click "Create" to instantiate the game
After Creation
Once created, the game appears in your classroom's module list. From here you can:
Copy the join link to share with participants
Access game settings
View analytics
Manage enrolled students
Sharing Game Access
Once a game is created, you need to provide access to participants. KC7 offers three primary methods for granting access, each suited to different scenarios and organizational needs.
Distribution Methods
Direct Link Sharing
The most straightforward method is to copy the game's unique join link and distribute it directly to participants. This approach works well for most scenarios and doesn't require participants to join the classroom first.
To use this method, navigate to the game within your classroom, locate the join link (typically displayed prominently in the game details view), and copy it. You can then share this link through any communication channel: email invitations, announcements in your learning management system, chat messages, or even physical handouts with QR codes.
When participants click the link, they'll be directed to the game. If they don't have a KC7 account, they'll be prompted to create one. If they're already logged in, they'll gain immediate access to the game. This method gives you precise control over who receives access since you're manually distributing the link.
The advantage of direct link sharing is simplicity and directness. Participants don't need to navigate through classroom structures or understand the platform hierarchy - they simply click and play. The disadvantage is that it requires you to manage link distribution for each new game, which can become tedious if you're running many games or have frequent cohort changes.
Classroom Join Link
An alternative approach is to share the classroom's join link along with its password. This method enrolls participants into the classroom itself, and then games within that classroom can be configured to automatically assign enrolled classroom members.
To use this approach, you'll find the classroom join link in the classroom settings. Share both the link and the password with your intended participants. When they use this link, they become members of the classroom. From there, any games configured with auto-assign enabled will automatically enroll them.
This method is particularly useful for large groups or recurring cohorts. For example, if you're running a semester-long course with weekly games, you can add all students to the classroom once at the beginning of the term, and then each week's new game will automatically become available to all classroom members when you enable its auto-assign setting.
The classroom join link method reduces administrative overhead for ongoing programs but requires participants to understand they're joining a classroom that may contain multiple games. It also means you need to manage auto-assign settings carefully to prevent participants from accessing games before they're ready.
Manual Assignment
For maximum control, you can manually assign specific participants to games through the Students tab. This method is ideal when you need precise control over who accesses what content, when they access it, and for tracking specific cohorts.
To manually assign participants, navigate to the game's Students tab (or the classroom's Students tab if they're already classroom members), search for participants by username, and add them individually or in small batches. The system will enroll them in the game, and they'll see it appear in their personal game library.
Manual assignment works best for smaller groups, controlled research studies, individualized learning paths, or situations where you need to grant access selectively rather than broadly. It's more labor-intensive than the other methods but provides complete visibility into exactly who has access to each game.
The key advantage is granular control and clear audit trails. You know exactly who was added, when, and by whom. The disadvantage is the time investment required for large cohorts - adding 100 participants manually is significantly more work than sharing a classroom join link.
Game Lifecycle Management
Active Games
Games remain accessible to participants as long as they're active. You can:
Monitor participation in real-time
View live scoreboards
Track completion rates
Export results
Completed Games
After an event concludes:
Game data and results are preserved
Participants can still access to review
Analytics remain available
Links continue to work unless manually disabled
Archiving Games
To remove a game from active view:
Navigate to game settings
Disable or delete the game
Participant data is preserved in exports
Analytics remain accessible through dashboard history
Multiple Games Strategy
As your KC7 usage grows beyond a single event, you'll need strategies for organizing multiple games. The platform's flexibility allows several organizational approaches, each with distinct advantages depending on your program structure and goals.
Same Module, Different Dates
One common pattern is creating multiple instances of the same module for different time periods or events. This approach is straightforward and works well for recurring programs where you want to use proven content repeatedly.
For example, if "A Scandal in Valdoria" works well for your monthly cybersecurity workshop, you can create a new game instance each month. Each instance exists independently with its own participant roster, start date, and analytics. Participants in the March game don't see or interact with participants in the April game, even though they're playing identical content.
When naming these games, include temporal information in the title for easy identification: "March 2024 - Valdoria", "April 2024 - Valdoria", and so on. This naming convention makes it immediately clear which game corresponds to which event when you're reviewing analytics or managing enrollments.
The primary advantage of this approach is consistency and simplicity. You know the module works, you understand its difficulty level and time requirements, and you can reuse supporting materials like handouts or slides. The analytics from previous runs help you anticipate where participants might struggle and prepare appropriate guidance. Over time, you build historical data showing how different cohorts perform on the same content, which can reveal trends in participant preparation or learning outcomes.
One consideration: participants who complete one instance cannot replay it in a different instance to improve their score, as the system recognizes they've already completed that content. If you have repeat participants across months, you may want to introduce different modules to keep the experience fresh.
Different Modules, Same Classroom
Another strategy involves offering multiple modules within a single classroom, typically to provide progression paths or varied experiences for the same participant group.
In an educational setting, you might structure this as a learning path: start participants with "A Scandal in Valdoria" as an introduction, follow with an intermediate module to build skills, and culminate with an advanced module as a capstone challenge. All three games exist in the same classroom, allowing you to track individual participant growth across the entire curriculum.
When using this approach, carefully consider your auto-assign settings. You generally don't want to auto-assign all modules to participants immediately, as that can be overwhelming. Instead, create all the games at the start of your term but keep auto-assign disabled. As you progress through your curriculum, enable auto-assign for each module when you're ready for participants to access it. This gives you pre-planned structure while maintaining control over pacing.
Game naming should reflect both the module and the intended sequence or difficulty: "Week 1 - Beginner - Valdoria", "Week 4 - Intermediate - Network Analysis", "Week 8 - Advanced - Threat Hunt". This nomenclature helps both you and participants understand the progression and expectations.
The advantage of housing multiple modules in one classroom is cohesive tracking. You can see each participant's overall progress across the entire program in one view. The classroom analytics show completion rates across all modules, helping you identify participants who excel consistently versus those who struggle at particular difficulty levels.
Multiple Classrooms
For larger or more complex programs, organizing games across multiple classrooms provides the highest degree of structure and separation.
You might organize classrooms by organizational hierarchy - creating separate classrooms for different departments in a corporate setting, or different grade levels in a school. Each classroom functions as an independent silo with its own managers, participants, and game instances. An engineering department's classroom doesn't interact with the sales department's classroom, even though both might be running similar content.
Alternatively, organize by skill level with classrooms for beginner, intermediate, and advanced tracks. This organization makes it easy to assign appropriate classroom managers (your expert instructors managing advanced, your teaching assistants managing beginner), ensures participants only see content at their level, and simplifies analytics by grouping similar-skilled participants.
Time-based organization is popular in educational contexts: "Fall 2024 Section A", "Fall 2024 Section B", "Spring 2025 Section A". This structure provides clean separation between terms and makes archiving straightforward - at the end of the fall semester, archive or delete the fall classrooms without affecting spring content.
Program type organization works well for diverse use cases: separate classrooms for "Staff Training" (monthly workshops), "Student Course" (semester-long), and "Community Events" (one-off public events). Each classroom type has different management needs, participant expectations, and lifecycle patterns.
The multiple classroom approach trades simplicity for organization. It's more complex to set up initially and requires more careful permission management (ensuring the right managers access the right classrooms), but it provides superior structure for large-scale programs. Analytics become more segmented but also more meaningful - you can compare performance across departments, skill levels, or time periods because the data is already organized appropriately.
Best Practices
Naming Conventions
Use consistent, descriptive names:
Include date or cohort identifier
Specify module name
Add context if needed
Examples:
✅ "Spring 2024 Intro - Valdoria"
✅ "Employee Onboarding Q2 - Valdoria"
❌ "Game 1"
❌ "Test"
Auto-Assign Configuration
Enable auto-assign when:
All classroom members should access this game
Running regular recurring events
Managing large cohorts
Disable auto-assign when:
Games are scheduled for future dates
Limiting access to specific participants
Running multiple simultaneous tracks
See Game Settings for detailed auto-assign configuration.
Pre-Planning Events
Create games in advance for:
Structured semester or term schedules
Regular monthly or quarterly events
Multi-week programs
Control access using:
Auto-assign toggle (enable when ready)
Manual participant assignment
Scheduled link distribution
Troubleshooting
Participants Can't Access Game
Verify:
Join link is correct and complete
Game is not disabled in settings
Participants have created KC7 accounts
Classroom membership if using auto-assign
Solutions:
Regenerate and reshare link
Check game status in settings
Verify participant account creation
Manually add participants if needed
Wrong Module Selected
If game not yet started:
Delete the game
Create new game with correct module
No data loss since no participation yet
If game already has participants:
Cannot change module after creation
Create new game with correct module
Communicate new link to participants
Preserve old game for data/analytics
Duplicate Games
Multiple games with same name or configuration:
Review game list in View Modules
Archive or delete duplicates
Update naming convention for clarity
No participant data loss when deleting unused games
Related Documentation
Adding Games - Detailed game creation guide
Game Settings - Configuration options
Organizing Classrooms - Classroom structure
Viewing Results - Game analytics and data
Last updated