If you watched carefully, you might have noticed that DreamHack Open Leipzig 2020 had instant replays directly from the players’ perspectives, not the observer’s. This was powered by the StatsHelix Highlight Wizard, our newest product. The Highlight Wizard uses game data and virtual machines to automate highlight creation in the cloud, capturing every kill directly from each player’s point of view… something that would be impossible with traditional observing.
The first day of the tournament (Friday) didn’t have these clips. Due to unforeseen side effects of a recent CS:GO update by Valve, we had to fundamentally rework how our product interfaces with the game, as it was no longer able to collect the data it needed. Fortunately, what could have taken days to fix only took hours. Our “modular design” philosophy enabled us to quickly make the last-minute changes necessary and get the Highlight Wizard back online.
Here’s a look at how StatsHelix’s modular architecture works and a real life example of how it helped us overcome an unexpected problem:
Background
Classic replay solutions for broadcast productions require a replay operator to constantly keep an eye on what’s happening. The reason is that these tools don’t understand what’s happening on-screen; a human is required for that. Our Highlight Wizard changes this. By parsing game data, we can accurately pinpoint when kills or other highlight worthy events (e.g. bomb defuses, Roshan killings, objective completions, etc.) are happening. The operator can then replay these moments with just the click of a button.
The StatsHelix Highlight Wizard
The gold standard for accessing CS:GO game data at tournaments is the “GOTV-CDN” format produced by the tv_broadcast command. Valve switched to this format a few years ago in order to scale their infrastructure for in-game viewers more easily.
Our Highlight Wizard is based on a modular architecture in order to support different games. Our SDK, which translates CS:GO data into data directly usable by our software, relies on this to detect game events. However on the evening before the event during some final testing, the Dreamhack admins ran into a (recently introduced) bug in the CS:GO server that forced them to turn off tv_broadcast for this entire event.
With our primary data source gone, we needed to come up with a workaround, fast.
Saved by Modular Design
At StatsHelix, we use a modular approach to software design. The diagram below illustrates this — it’s how our interactive streaming product works:
Data is collected, standardized, transformed, then sent to each product as necessary for output
One one side, we have our SDK and associated software that collects data from games and converts it into a standardized format. On the other, we have our products, which generate various forms of output depending on the application — in the case of the Highlight Wizard, mp4 clips. In the middle, we have our core technology: modules. These modules are pre-existing libraries of code that transform and manipulate data to create the desired output. The modules are isolated from both the data collection and the data output, meaning that changes in data source or desired output don’t compromise them. In essence, we have virtual fire doors that prevent all of StatsHelix from burning down in case a fire starts in one section.
But there are advantages beyond just safety. This design means that any StatsHelix product can easily work with a new game by simply interfacing with our SDK. That’s precisely what we did with CS:GO at Dreamhack.
After some brainstorming and experimenting, we determined that the data from CS:GO’s “Game State Integration” API — while slightly less accurate — could be used as an emergency substitute for GOTV data. We ended up linking that to our SDK to give the Highlight Wizard a new way of identifying kills. Once that was done, the rest of the software could continue functioning normally. The recording infrastructure and server-side code didn’t need to be touched at all. The same goes for all of the operator-side code, including the production interface, clip creation tools, and playback.
By the start of day 2, we were integrated seamlessly into the production.
Conclusion
We think Modular Design has several key advantages.
- It’s easier to isolate and fix problems, especially unexpected ones that pop up right before a big event!
- Adapting technology to new use cases is simplified (whether it be new games or new products leveraging existing tech)
- It’s resource efficient (Minimal time spent re-creating existing tech different applications)
- It’s easier for third-parties to work with your products. We can’t stress how important this is as a small company.
In related news, Origami just raised a seed round to create the world’s first “Modular Game Engine.” Here is a quote from their press release:
The modular architecture of the engine and its data driven design is important because it allows Origami to update specific portions of the engine without affecting the whole system. For developers, this means two things: Not worrying about engine updates for your games and an easier way to integrate third party systems.
Modular design is one of the things that makes StatsHelix unique. We are very passionate about it and would love to hear your thoughts. If you have any questions or would like to learn more, feel free to reach out at : info@statshelix.com