CMSC 22000 Final report

Quarter: Spring 2025

Feature: Tournaments

Design and Implementation

Simulation features

The tournament team worked on implementing tournament simulation functionality. This included simulating single-elimination, double-elimination, round-robin, and multi-stage tournaments using faked player and match data. We implemented backend and front-end changes, so the ‘simulation mode’ can be activated under any active tournament in the Chigame web application. This mode lets users interactively simulate tournament outcomes by selecting winners for individual matches or running a full simulation where winners are randomly chosen and advanced through each round. Crucially, this functionality is overlaid onto the existing tournament structure without altering any core tournament data—ensuring the simulation is a non-destructive, testable preview of how the bracket might unfold. We built a TournamentSimulator utility that handles simulation logic for both formats and added new UI controls in the tournament detail view, including a toggle for simulation mode and the ability to switch between single and double elimination styles. The backend and frontend changes will help aid future teams when playable games are deployed to Chigame, as the tournament simulation logic is decoupled but easily integrated into the tournament model.

Additionally, under the simulation mode, we worked on creating a seeding component for tournaments. This consisted of two main tasks: using player seeds as a way to set up tournament brackets (for single and double elimination), and using player seeds as a way to break ties (for round robin, and hopefully multi-stage in the future). We implemented a very simple seeding system, which calculates player seeds based on previously won vs lost tournaments of the same game. We also created seeding fixtures for users and past tournaments because we didn’t have any real tournament data to work with. Creators of tournaments can now simulate tournaments with and without seeding for single and double elimination, which means that bracket construction is either seeded (seed 1 vs seed n, seed 2 vs seed n-1, etc.), or based on when players joined the tournament. Creators of tournaments can also simulate tournaments with and without seeding for round-robin, which means that winner ties can be broken randomly, or based on which player has a higher seed (this is currently only implemented in the backend).

Additionally, we implemented a backend recommendation system that suggests users to invite to tournaments. The system scores users based on multiple factors: friendships with the tournament creator, prior experience with the game, participation in the creator’s past tournaments, and familiarity with the tournament format. We encapsulated this logic in a TournamentRecommendationService with a public helper method get_tournament_recommendations(). It excludes users already in the tournament and ranks recommendations by score. We also developed frontend components to display these suggestions and created fixtures and tests to validate both systems. These tools are well-documented and designed for easy extension in future iterations.

The tournament team also worked on enhancing the tournament creation experience and developing an analytics page for matches. For the tournament creation feature, we improved both the UI and backend to streamline and modernize the user experience. Previously, tournaments had to be created manually at least 24 hours in advance, with dates manually inputted. We requinzed this convoluted user experience and introduced functionality that allows tournaments to be scheduled just five minutes ahead of time and added a user friendly drop down calendar for selecting dates and times.

We also implemented real-time form validation. Users are now informed of required fields when attempting to submit a tournament, and the form cannot be submitted until those fields are completed. Previously, users received no feedback when entering invalid data—such as scheduling a tournament in the past. Now, they receive clear error messages that guide them to correct their input. Additionally, we added a character counter for the tournament fields and enforced a 1000-character limit in the backend. This encourages concise and specific tournament descriptions, helping players more easily identify the events that are relevant to them. We also built out an analytics page for matches, which provides insight into tournament performance and match outcomes. This page supports admins and organizers in reviewing key metrics and making data-driven decisions. To do this, we developed front-end, back-end, and testing scripts. This feature provides valuable insights into tournament activity by calculating key statistics such as the fastest and slowest matches played, the total number of matches within a tournament, and identifying which users completed their matches the quickest. On the front-end, we added functionality that allows users to view analytics by clicking a “View Match Analytics” button beneath each tournament. This redirects them to a dedicated page displaying all relevant metrics in a clear and accessible format.

The component we worked on in the Tournament team was the Tournament Feedback feature. This was a feature that allowed users to leave comments and ratings on tournaments. The base of the system was the Feedback entity model, which was implemented as one of my first PRs, which has a one-to-many relationship with the Tournament model. Each feedback includes attributes like rating, comment, user reference, and timestamp. Next, to handle the logic, we developed Create, Read, Update, and Delete models in the service layer (as the API later was supposed to be for the API team) that performed necessary operations for feedback. This layer enforces input validation such as rating bounds and non-empty comments and strict authorization where only the original author of a tournament can see all the feedback of a tournament. On the other hand, users can view all of their own comments across all tournaments.

On the frontend, we integrated feedback functionality in the tournament detail page. Once a user navigates to the tournament detail page, users can submit feedback in a text box, put in a rating from 1 to 5, and click on the submit button. The submitted feedback appears under both All Feedback and My Feedback, but not that only the owner can see the All Feedback link. As a normal user, one would only be able to see the link to My Feedback. Each feedback item includes an edit and delete option when authorized.

To enhance tournament incentives, we introduced a new prize model that distributes rewards to the top three players. This involved changes across the model layer, service layer, and frontend. We updated the Tournament model to include a field that maps placements (e.g., 1st, 2nd, 3rd) to their respective prize values.

On the tournament results page, we added a visual component that displays the top 3 players and their corresponding prizes. We also added prize information to the tournament detail view, so users know what they are playing for ahead of time. To address the issue of full tournaments, we implemented a waitlist system that queues additional players once a tournament reaches capacity. While we did not build out the full UI experience this quarter, we completed the backend and model components. This foundational work will allow future teams to build out the full frontend and enable users to view and manage their waitlist status directly from the UI.

Next Steps

One important component that future tournament teams may want to look into is greater tournament customizability. Right now, when creating a tournament, tournament creators can fill in text boxes for both win and ‘draw’ (tie) rules, but this information is not very useful, and doesn’t actually affect tournament setup in any way. This year, we tried to make tournaments more customisable in simulation mode by adding different tournament types, and adding a seeding option for tournaments. But in the future, there are many more ways we can make tournaments more customisable. We could add different ‘win rules’ such as first to ___ points, best of ___ games, highest scorer, games won or lost. We could also add different ‘draw rules’ such as picking random winners, rematches, higher seed wins, or simply allowing draws. There are many interesting ways we could make tournament creation and rule-making easier and more customisable.

Another critical next step is a full redesign of the tournament model to support multiple tournament formats at the backend level. I discussed this with Sam, and it’s clear that the current implementation is heavily tailored to single elimination—everything from how matches are stored to how tournament progression is handled is specific to that format. This is a major bottleneck if the team wants to fully integrate double elimination, round-robin, or multi-stage tournaments in a meaningful way. While we were able to simulate different tournament types this quarter through frontend overlays and decoupled logic, the underlying data structures in the model don’t reflect that flexibility. To move forward, future teams should refactor the tournament model so that it can store and differentiate between tournament types and expose methods to handle match generation and progression logic appropriate to each type.

In the future, others can build upon our work by further synchronizing the tournament creation page. Specifically, they should ensure that all description fields are consistently treated as required, as some team members have added new items that are not yet validated. Additionally, there is room to enhance the Analytics page by incorporating more detailed metrics and insights. Future contributors could integrate features developed by other teammates into the analytics dashboard to provide a more comprehensive overview for users. Lastly, more extensive testing should be conducted to ensure that all form validations and user notifications are functioning correctly across various edge cases.

Another task that future students could work on to improve our work, or in general for the tournament team, is to ensure consistent tournament visibility for owners across all views and user flows. Something that happened this year was we discovered a bug where users can only see tournaments where they have been assigned as a player. This means that tournament owners cannot see the tournaments they created themselves. While we fixed the bug in my code to allow tournament owners to see tournaments they created (and the line of code should still be in the codebase), this functionality was later lost likely due to merge conflicts from parallel development. A future student can work on debugging this problem; it should be a quick fix in the TournamentDetailView in the views.py file.

Another major area is the frontend integration of the waitlist feature. While the backend logic and model infrastructure are complete, users currently have no visibility or interaction with the waitlist system through the UI. Future developers can design and implement a user-facing experience that allows players to see when a tournament is full, join a waitlist, view their position in line, and receive a notification or automatic enrollment if a spot opens up. This would make the waitlist system feel more seamless and intuitive for users. Another high-impact area for future development is the addition of live player standings tracking within a tournament. As it stands, prize assignment occurs only at the conclusion of the tournament based on final placements. Implementing a real-time leaderboard that updates as matches are played would greatly enhance the competitiveness and transparency of the experience. Such a system could display evolving player ranks, provide visibility into current tournament leaders, and potentially lay the groundwork for more advanced features like ELO-based matchmaking, seeding, or season-long performance tracking. These improvements would help turn tournaments into more dynamic, engaging events for users and expand the platform’s long-term capabilities.