Game Settings
Game settings allow you to configure individual game instances to match your event requirements, control participant access, and customize the learning experience.
Accessing Game Settings
Navigate to your classroom
Click on the specific game
Select "Settings" tab
Modify configurations as needed
Save changes
Core Settings
Game Information
Game Name
Display name shown to participants
Appears in participant game library
Used in analytics and reports
Can be updated at any time
Game Description
Optional explanatory text
Visible to participants before starting
Use to provide context or instructions
Supports basic formatting
Status
Active: Game accessible to enrolled participants
Inactive: Game hidden but data preserved
Archived: Read-only, no new participants
Access Control
Auto-Assign
Controls automatic participant enrollment when users join the classroom.
Enabled (ON):
New classroom members automatically enrolled in game
Existing classroom members added immediately when enabled
Useful for: open enrollment, large groups, recurring events
Disabled (OFF):
Manual assignment required for each participant
Existing enrolled participants remain enrolled
Useful for: phased rollouts, selective access, future-dated games
See Auto-Assign documentation for detailed workflows.
Join Link
Every game receives a unique URL that serves as a direct access point for participants. This join link is generated automatically when you create the game and remains stable throughout the game's lifecycle unless you explicitly regenerate it.
The join link operates independently of classroom membership, which has important implications for access control. A participant can use the join link to access the game even if they're not a member of the classroom containing that game. This independence provides flexibility - you can share a game with external participants, guest players, or individuals from other classrooms without enrolling them in your classroom first.
However, this independence also means the join link is a security boundary. Anyone who obtains the link can potentially access your game if no additional protections are in place. For this reason, treat join links as sensitive credentials. Don't post them publicly, don't include them in searchable websites, and be cautious about where you share them.
If you suspect a join link has been compromised - perhaps it was accidentally posted to a public forum, shared beyond your intended audience, or you simply want to invalidate all previous link distributions - you can regenerate it. Regeneration creates a new unique URL for the game, immediately invalidating the old link. Anyone who had the previous link will no longer be able to access the game through it. After regeneration, you'll need to redistribute the new link to your legitimate participants.
Link regeneration is useful in several scenarios beyond security compromises. Some organizations regenerate links between enrollment periods to ensure only current cohort members have access. Others regenerate after events conclude to prevent future participants from accessing content that should be retired. The regeneration process is instant and doesn't affect current participant enrollments - people already in the game remain enrolled and can continue accessing it, they simply can't use the old link to re-enter if they log out.
Password Protection
Password protection adds an additional authentication layer to the join link, requiring participants to enter a password before gaining access to the game. This transforms the join link from a single credential (just the URL) into a two-factor access control mechanism (URL plus password).
You can set password protection in two ways. First, you can create a custom password - perhaps a memorable phrase related to your event, a code word you'll announce at the start of a session, or a password that aligns with your organization's policies. Custom passwords are useful when you want the password itself to serve as a signal (like announcing it at the beginning of a workshop to confirm attendance) or when you need to meet specific password complexity requirements.
Alternatively, you can have the system generate a secure random password. Generated passwords are typically longer and more complex than human-chosen passwords, making them more resistant to guessing attacks. However, they're also harder to communicate verbally and easier for participants to mistype. The security-convenience trade-off depends on your threat model - a public event might warrant a strong generated password, while a small internal training session might prioritize a simple memorable password.
Once set, participants must enter this password when they click the join link. The system presents a password entry form before granting access to the game. If they enter the wrong password, access is denied. If they enter it correctly, they gain access and the password is typically cached for their session, so they don't need to re-enter it on subsequent visits (though this behavior can vary based on browser settings).
You can change the password at any time through the game settings. Changing the password immediately invalidates the old one - participants who had previously accessed the game using the old password will need the new password for their next access. This is useful for rotating credentials periodically or if you believe the current password has been shared too broadly. When you change the password, make sure to communicate the new one to your legitimate participants through a secure channel.
Participant Limits
Maximum Participants
The maximum participants setting establishes a hard cap on how many people can enroll in a game. Once this limit is reached, the system prevents additional enrollments regardless of the enrollment method - auto-assign stops adding new classroom members, manual assignment operations fail, and the game link shows a "capacity reached" message to would-be participants.
Participant limits serve several practical purposes in real-world deployments. Resource-constrained scenarios represent the most common use case - perhaps your organization has purchased a limited number of licenses, your infrastructure can only support a certain number of concurrent users, or you're running an in-person event with physical space limitations. Setting a participant cap ensures you don't accidentally exceed your technical or contractual capacity.
Pedagogical considerations also drive limit setting. Some instructors find that discussion quality degrades beyond a certain cohort size, or they want to ensure they can provide individual attention to each participant. Setting a limit at 25 or 30 participants, for instance, maintains a manageable group size even if hundreds of people have access to the classroom.
Competitive fairness represents another motivation. In competition scenarios where prizes or recognition are awarded, limiting participants ensures the competitive pool remains at an intended size. You might design a challenge for 50 competitors but receive interest from 200 people. Setting a firm cap maintains the designed experience and prevents the competition from becoming unwieldy.
The limit is enforced at enrollment time, not retroactively. If you set a maximum of 100 participants and 90 are currently enrolled, then increase the limit to 80, the system doesn't remove anyone - those 90 remain enrolled. The limit only prevents new enrollments. However, if you later increase the limit to 110, those remaining 20 slots become available for new enrollments.
This non-retroactive enforcement has important implications for capacity planning. If you initially set a limit that turns out to be too low, you can increase it without affecting existing participants. This provides flexibility to respond to higher-than-expected demand. However, you generally cannot decrease capacity below current enrollment without manually removing participants, which may have fairness or communication implications.
Waitlist
When you enable the waitlist feature alongside a participant limit, you create a queuing mechanism for overflow demand. Participants who attempt to join a full game are automatically placed on a waitlist rather than being turned away entirely. If space opens up - perhaps because someone drops out or you increase the participant limit - waitlisted participants are automatically promoted to full enrollment in the order they joined the waitlist.
The waitlist automation reduces administrative overhead in high-demand scenarios. Without a waitlist, when capacity frees up, you'd need to manually communicate with interested parties and individually enroll them. With a waitlist, the system handles this process automatically, ensuring fair first-come-first-served access to available slots.
Waitlist behavior integrates with different enrollment methods. If auto-assign is enabled and a classroom member can't be added due to capacity limits, they're added to the waitlist. If they're manually assigned and capacity is full, the assignment operation adds them to the waitlist instead of failing. If they use the game join link and encounter a full game, they see a waitlist enrollment option.
Manual waitlist management capabilities complement the automatic promotion system. As an administrator, you can view the waitlist, see the enrollment order, manually promote specific individuals (perhaps due to special circumstances or accommodations), or remove people from the waitlist if they're no longer interested. This manual control provides flexibility when automatic rules don't perfectly match your needs.
Consider the communication implications of waitlisting. Participants added to a waitlist may not realize they're not actually enrolled yet - they might expect immediate access and be confused when the game doesn't appear. Clear communication about waitlist status, expected wait times (if you can estimate them), and what triggers promotion helps manage expectations and reduce participant frustration.
Timing Settings
Timing controls allow you to schedule game availability, enforce deadlines, and create time-pressure scenarios. These settings transform a game from an always-available resource into a scheduled event with specific temporal boundaries.
Game Duration
Start Date/Time
The start date and time setting controls when a game becomes accessible to enrolled participants. Before this timestamp, the game exists in the system and participants can see it in their game library (if enrolled), but they cannot begin playing. When the start time arrives, the system automatically unlocks the game for all enrolled participants.
This scheduling capability enables several valuable scenarios. You can create games well in advance of when you want participants to access them, allowing you to prepare content during calm periods and have it automatically release during busier times. For example, if you're running a Friday afternoon workshop, you might create and configure the game on Monday, set the start time for Friday at 2 PM, and the game will become accessible exactly when your workshop begins without requiring you to manually unlock it.
Start times are particularly useful for coordinating synchronized experiences across distributed participants. In a global training program spanning multiple time zones, you can set a universal start time that ensures everyone begins simultaneously (or at least has simultaneous access opportunity). This prevents participants in early time zones from gaining unfair advantages in competitive scenarios or sharing solutions before others have attempted the challenges.
The setting is optional - leaving it blank means the game is immediately accessible upon creation. This is appropriate for self-paced learning scenarios where you want participants to start whenever they're ready. However, even in self-paced contexts, you might use start dates to create a staggered curriculum release, where Module 1 is immediately available, Module 2 becomes available after one week, Module 3 after two weeks, and so on.
One important consideration: participants enrolled after the start time passes will still gain immediate access when they enroll (assuming they meet other access requirements like auto-assign or manual assignment). The start time is a "no access before this" boundary, not a "must be enrolled before this" requirement.
End Date/Time
The end date and time setting establishes when a game closes to new submissions. After this timestamp passes, participants can still access the game to review content, see their previous answers, and examine the questions, but they cannot submit new answers or modify existing ones.
This deadline functionality is essential for assessment scenarios where you need to ensure all participants complete work within a specific timeframe. In an educational context, you might align the end time with a class period conclusion or semester end. In competitive scenarios, the end time ensures all participants have the same duration to complete challenges, preventing late-comers from having more calendar time to work.
The behavior after the deadline is nuanced and worth understanding thoroughly. Participants retain read access to the game content, which supports learning objectives - they can review questions they struggled with, examine their approach to problems, and learn from the experience even after the submission window closes. This read-only access also serves record-keeping purposes, allowing participants to document their work for portfolios or certification requirements.
However, the inability to submit new answers means incomplete work at deadline remains incomplete. If a participant has answered 8 out of 10 questions when the deadline passes, those remaining 2 questions can never be answered in this game instance. The score is effectively frozen at the point the deadline passed. This creates genuine stakes for time management during the game.
End times are also optional. Leaving this field blank means the game remains open for submissions indefinitely. This is appropriate for practice environments, evergreen training content, or scenarios where you value completion over punctuality. Some programs use a hybrid approach - set an end time for graded assessment purposes, but then extend or remove it after grades are finalized to allow continued practice.
Time Limits
Time limits create real-time pressure during gameplay, fundamentally changing the experience from thoughtful analysis to rapid decision-making. KC7 supports two types of time limits, each serving different pedagogical or competitive purposes.
Per-question time limits constrain how long participants can spend on individual questions. When enabled, each question displays a countdown timer. If the timer reaches zero before the participant submits an answer, the question typically auto-submits with whatever they've entered (or marks it as unanswered, depending on configuration). This creates urgency and tests whether participants can make quick analytical decisions under pressure.
Per-question limits are useful for simulating operational cybersecurity scenarios where analysts must triage numerous alerts quickly, identifying critical threats within tight time windows. They also help prevent over-analysis paralysis, where participants spend excessive time on difficult questions at the expense of completing easier questions they could answer readily.
Total game completion time limits constrain the entire game session duration. When a participant begins the game, a master countdown timer starts. They must complete all questions before this master timer expires. If time runs out, the system auto-submits the game in its current state, scoring any answered questions and leaving unanswered questions blank.
Total time limits create different strategic pressures than per-question limits. Participants must allocate their total time across all questions, deciding whether to spend more time on high-value questions, skip difficult questions to answer easier ones first, or work systematically through the question sequence. This mirrors real assessment scenarios and competitive environments where time management is as important as knowledge.
Time limits can be combined - you might set both per-question limits and a total time limit, creating a multi-layered time pressure scenario. Or you might use only one type depending on your goals. The key is understanding that time limits fundamentally change participant behavior and experience, generally increasing stress and reducing thoughtful analysis in favor of rapid response.
Access Windows
Recurring Access
Set specific days/times when game is accessible
Useful for scheduled lab periods or class sessions
Participants locked out outside designated windows
Extended Access
Grant specific participants additional time
Accommodations for accessibility requirements
Individual deadline extensions
Scoring and Competition
Point System
Standard Scoring
Points awarded per correct answer
Bonus points for speed
Penalty for incorrect attempts (optional)
Custom Scoring
Modify point values per question
Weight certain questions higher
Adjust for difficulty or importance
Leaderboard
Visibility
Public: All participants see full leaderboard
Anonymous: Participants see rankings but not names
Private: Participants see only own rank
Disabled: No leaderboard shown
Refresh Rate
Real-time updates (may impact performance)
Periodic updates (every 30 seconds, 1 minute, etc.)
Manual refresh only
Team Mode
Enable team-based competition
Define team size limits
Teams self-organize or pre-assigned
Content Settings
Module Selection
Base Module
Core module selected at game creation
Cannot be changed after participants begin
Determines available questions and scenarios
Question Subsets
Enable only specific questions from module
Useful for targeted practice or assessments
Custom difficulty progression
Hints and Assistance
Hint Availability
Enable/disable built-in hints
Configure hint reveal progression (immediate, delayed, staged)
Penalty for hint usage (optional)
Answer Validation
Immediate feedback on submission
Delayed feedback (reveal after game end)
Partial credit for incomplete answers
Retry Policy
Unlimited attempts (default)
Limited attempts per question
Lockout after X failed attempts
Advanced Settings
Integration
LMS Integration
Connect to learning management system
Sync grades and completion status
SSO authentication support
API Access
Enable programmatic access to game data
Generate API keys
Configure webhook notifications
Analytics
Data Collection
Detailed vs summary analytics
Time-on-task tracking
Answer attempt logging
Anonymization options
Export Settings
Automatic scheduled exports
Export format preferences
Data retention policies
Customization
Branding
Custom logos and colors (tenant-level)
Game-specific welcome messages
Custom completion certificates
Notifications
Email notifications for participants
Reminder emails before deadline
Completion confirmations
Performance reports
Setting Templates
Quick Setup Templates
Beginner-Friendly Event
Unlimited time
Hints enabled
Unlimited retries
Public leaderboard
No auto-assign (manual sharing)
Competitive Challenge
Time limits enabled
Hints disabled or penalized
Limited retries
Live public leaderboard
Auto-assign for registered participants
Classroom Assessment
Set duration (45-90 min)
One attempt per question
Delayed feedback
Private scoring
Scheduled access windows
Self-Paced Learning
No time limits
Hints available
Unlimited retries
Individual progress tracking
Auto-assign for classroom members
Best Practices
Initial Setup
Configure settings before sharing game link
Test with personal account before participant access
Document settings for recurring events
Use templates for consistency
During Active Game
Avoid changing core settings mid-game
Communicate any necessary changes to participants
Monitor settings if issues reported
Keep backup of original configuration
Post-Game
Archive or disable completed games
Preserve settings for future reference
Export data before making major changes
Review analytics to inform next event settings
Troubleshooting
Participants Can't Access Game
Check:
Game status is Active
Start date hasn't passed yet or hasn't arrived yet
Auto-assign is enabled if relying on classroom membership
Join link is correct and not expired
Password is correct (if enabled)
Settings Changes Not Applying
Solutions:
Save changes before leaving settings page
Refresh participant view to see updates
Clear cache if settings appear outdated
Verify permissions (Classroom Manager or above required)
Auto-Assign Not Working
Verify:
Toggle is in ON position
Participants are members of classroom (not just game)
Game status is Active
Participant limit not reached
Related Documentation
Managing Games - Creating and organizing games
Adding Games - Game creation procedures
Analytics - Understanding auto-assign and performance tracking
Managing Users - Participant enrollment
Last updated