SC2 Tour System

Context

I was relatively active in the Czech StarCraft II community and was approached by a friend who said he'd like to run a community tournament and would like me to provide a web-based utility for tournament management. Initially this was a small project that wrapped Challonge API and added features like player seeding based on performance, reporting results by uploading SC2 replays, and announcing results to a Discord server.

It grew into a community place that kept a public leaderboard of local players, a list of local tournaments and results, provided player stats and tournament performance services, showed team results of the team I managed, and also expanded into other games played by the community. I also used it as a playground to test a tournament system (McMahon) and evaluate if it was more enjoyable for casual players compared to commonly used systems.

What I Built

This was built as a Java Spring/Thymeleaf application that incorporated data from the SC2 Data Manager project. Initially hosted at home on a Raspberry Pi and later deployed to a proper VPS.

The main feature is simplified tournament flow both for players and admins. Usually, players need to log in to tournament-running web apps, both sides need to report (the same) match results for it to be validated, and an admin needs to manually deal with wrong or missing reports. The system I made only relied on people registering via their game ID and uploading replays after the game. The replays were parsed on the server to determine the winner and the score, which reduced disputes and only needed one side to upload. It automatically set the results after replays were uploaded and reported the result to relevant Discord channels. A nice perk was that it was extremely easy to collect a tournament replay pack in this system.

It also served as an experimental playground for tournament systems that I thought would be more interesting for casual players who usually face strong opponents early in the tournament and are thus eliminated early without enjoying competitive matches at their skill level. The main systems I designed and implemented were a McMahon-derived format for a 1v1 tournament and a Davis Cup-inspired format combining 1v1 and 2v2 games between two-player teams in a team tournament. Based on the feedback, I actually succeeded in creating a fun experience for all sorts of players.

Since I am a data-geek, I was managing a dataset of tournament results for the local community and provided some sort of analytical service (ex., ex.) to browse the results. Once again, I tried to make the data and participation in tournaments fun in some way, so I tracked King-of-the-hill championship that tracked the current king and the defense of the title across tournaments, or provided various statistical tournament overviews.

I got very involved in the StarCraft II team league scene and at some point was running the highest rated Czech team, and I tried to catalogue the achievements via this project as well. I also offered support for other local teams via a common calendar of team matches and a stats service.

This was probably the longest running and updated project I ran and it was mostly driven by my passion for data and RTS games. It bloated (in a fun and enjoyable way) to the current size of 121 Java files, 21 controllers, 62 views, and 140 request mappings.

Interesting Problems

• Full-stack project — this was a challenging project since I basically filled all the dev roles. Especially the frontend visual creation was something that pushed me out of the comfort zone, and it probably laid the foundation of the style I nowadays prefer in regards to web UI. I also needed to learn how to properly host the web app and manage the VPS.

• Getting team match results — this project was heavily reliant on data that was rarely available in usable and complete form. For the team matches, I had to semi-automatically process the result reported to a Discord channel, tournament spreadsheet, or third-party tournament platforms. With every league I usually had to adjust the scripts that put that into the Excel sheet I was using as the source of truth. I also usually wanted more detailed info, which I had to dig out in various ways. Especially collecting player nationalities, so I could create a fun map visual, meant I had to look up the player on other platforms and hope to find a country flag, or ask the manager of the other team (who sometimes even didn't know themselves). Collecting replays (so I could extract fun stats or insights) from team matches was a chore of its own. Luckily, over time I conditioned my players to automatically send me the replays after the match.

• Keeping an up-to-date list of community players — for the system to work, I needed to have the players' game IDs. Blizzard does not provide country flags for players, so I had to improvise if I wanted to craft something resembling the leaderboard of Czech players. This meant that I had to actively listen in the community channels to discover new players and find the accounts they use. Usually, players had multiple accounts they played, so the list was never complete. Thanks to this work, I had an easier time when I needed to fill the roster for team leagues, since I already knew about most of the players and whether they were active and wanted to participate.

• Crafting fun tournaments — while running the tournament platform for the community, I noticed that different players have different expectations about tournaments and what they deem to be fun. This led to me experimenting with formats and collecting feedback on the changes from players. This has also spun up my follow-up project about evaluating the qualities of tournament systems. In summary, I believe I managed to provide a fun experience and to gather more player attendance and engagement with the tournament.

Related projects

• SC2 Data Manager - data collectors and tooling that runs underneath the web surface
• Tournament Format Simulator - analytical exploration of tournament systems and their pros/cons