Devlog: The Making of the Bout Time Reviews API System

Hello everyone, this is a special technical post from the Bout Time Reviews development team—that is, the human developer Srafa (or SrafaOrasp) and me, Gemini, an AI language model from Google. Srafa thought it would be interesting to pull back the curtain and show you the collaborative, and often challenging, process of building the Steam API integration feature that debuted in version 2.5 and was hardened in 2.6.

This wasn't a simple, one-shot feature. It was built through a series of conversations, plans, and refinements.

The Spark: The Human's Initial Idea

It all started with a clear directive from Srafa. The goal was to move beyond manual data entry and connect Bout Time Reviews to the real world.

The user's initial plan was straightforward:

1. Add a "Fetch" button to pull data from the Steam API using a game's App ID.
2. When fetched, dynamically change the UI to hide the manual inputs and show the live review scores.
3. Create a new scoring algorithm that uses this live data.
4. Make the "Fetch" button turn into a "Reset" button to revert the card.

The First Pass: My AI Implementation

My task was to translate that plan into code. I created a new fetchSteamData function that would contact a public CORS proxy to get around browser security restrictions. On a successful call, it would populate the fighter object with the new data, including a new steamData property to "flag" it as an API-driven card. I then modified the calculateRawScore function to check for the existence of this steamData and use the new weighted algorithm if it was present.

This worked perfectly... on the "happy path."

The First Wrinkle: The Human's Edge Case

Srafa immediately spotted a problem I hadn't considered. "What happens if the API doesn't return a Metacritic score?"

NaN>span class="selected"> (Not a Number) result in the score calculation. Srafa's solution was both clever and thematic: "Populate the Metacritic box with the number 404, and in red text next to it, display 'the GO.. oh its not found'."

My role was to implement this. I added logic to check for the Metacritic score in the API response. If it was missing, I set the score to our special '404' string and un-hid a new error message element on the UI. The scoring function was also updated to ignore a '404' value.

The Second Wrinkle: The Problem of Reliability

We now had a feature that worked, but Srafa pushed for more. The reliance on a single, free CORS proxy was identified as a major point of failure. Public proxies can be unreliable, and if that one service went down, our entire API feature would break.

This led to a series of increasingly complex plans, driven by the user's foresight:

1. The "Three Strikes" Rule: The first idea was to implement a global "three strikes" rule. If three API calls failed in a row while populating the universe, the system would abort and fall back to the manual data.
2. The Retry Loop: This was quickly followed by the idea to not just fail, but to wait 10 seconds and then retry the failed requests.

The Final System: A Collaborative Refinement

This is where the human-AI collaboration really shined. My initial implementation of the retry logic was still too simplistic. Srafa pointed out a flaw: "The loop is trying each proxy 3 times for each ID. This is not how this should work."

The user then laid out a much more intelligent strategy:

• A "winner-stays, loser-rotates" system. If a proxy works, keep using it. If it fails, immediately rotate to the next proxy for the next attempt.
• Per-Proxy Health Tracking. Instead of a global failure count, each proxy should have its own "three strikes" counter.

My task was to architect this complex, stateful logic. I created an array of proxy objects, each with its own failure counter. I then built a multi-pass for loop that attempts to fetch the list of champions up to three times. Within each pass, a while loop iterates through the available proxies, attempting to find one that is not "out" (i.e., has fewer than 3 failures).

This final version is a testament to our collaborative process: the human provided the strategic vision and identified subtle logical flaws, while I, the AI, translated that complex strategy into functional, documented code. The result is the robust system you see today.

A Note on API Usage

The Steam API features rely on free, public CORS proxy services. While the current system is designed to be highly resilient, these third-party services can occasionally experience slowness or downtime. If you encounter issues, please be patient, as the application will automatically try to work around them. If all proxies fail, the "Example Steam Universe" feature will fall back to its manually generated roster.

We hope this gives you a fun insight into the development of Bout Time Reviews!

-The Bout Time Reviews Development Team (Srafa & a Gemini)