I’ve had an interesting experience creating a web app for an external service, from its development to having the owner essentialy shut people like me down. Gather ‘round for the story of Salty Stats.

SaltyBet

I found out about a site called SaltyBet a week ago. It’s been around since EVO 2013, but gained lots of popularity around the weekend of Valve’s The International 3 Dota 2 tournament. Quite an interesting concept, where two AI fighters compete and you can bet on who you think is the winner with fake money. The characters were a grab bag of variety, from DBZ Marvel and anime favorites to outliers and hacked up characters from places like Family Guy. It’s pretty much a way to have fun when everything else feels boring all of a sudden. However, I did notice some interesting things about the statistics side of things.

Freedom to bear charts

Firstly, you needed to pay a subscription fee to become part of the Illuminati, which in addition to “exclusive” statistics, made sure you never went under $666 (normally if you lost everything, you default to $10 and are considered in the “salt mines”). Then I found out more:

• The live information was being taken from a JSON feed updating on the site every 2-3 seconds
• The stats provided by the website only gave win/loss rates, no match history or bet totals
• People really didn’t like the idea of having to pay for stats

So I decided to make it my weekend project to start a stat-tracking website to give everyone access to this publicly available information. After all, one could record the results of every match and pretty much have the same information as calling an API at a certain interval.

What powered the service

The technologies I used were:

• Node.js: This was the first time I created a Node application. Previously, I would’ve either used a cronjob or nohup’d a php process to grab the data via cURL, file_get_contents or otherwise. My script simply checked for the status (bets open, bets locked or winner declared) and did database updates accordingly. Most of the problems that occured had to do with the immense load put on the site in its first week of grand popularity which caused the script to sometimes not pick up on wins and leave some matches winless (which defeats the whole point of the service).

• SQLite: Since the amount of data to be collected would be small, I decided to go with a lightweight flat file SQL database. Each match had 2 text columns for the player names and 7 integer columns for the rest of the data, including bet totals and time checkpoints. Matches were on average about 5-6 minutes apart (could be shorter or longer depending on if the match was one-sided or not), giving around 250 matches per day. As you can tell by that, the amount of data would only a few megabytes a month, but that’s not where the magic happened…
  I had created a few views to show more detailed information about each player with win/loss rates, betting totals, and who faced who. The latter information is quite important to show which characters have a tendency of beating a certain category of character (like those that one-hit ko, like to be defensive with dodges rather than attacking, or finding that golden DBZ character that actually wins). Information like that is what gives bettors the advantage.

• PHP: I will never fail to admit that PHP is the fastest way for me to write up a web app. By simply tabularizing SQL rows, the frontend part was done in a matter of minutes with quick updates to the code being pushed out every so often due to user requests or features I was planning on adding anyway.

For a few days, all was well. I posted the site on Twitter and /vg/, and was getting a lot of referral traffic from 4chan and Something Awful, with a recorded maximum concurrent of around 30 people visiting the site. After switching from using http to grab the JSON to request, everything was stable. And then on that Tuesday, things went very south very fast.

Coaxed into a Snafu

Preface: There is another site known simply as “Hightower” (due to the domain name) that kept track of players’ match history and W-L rate, only it added user-provided comments and certain flags that showed what a player had a tendency to do. This site also suffered the same fate as the following.

On Tuesday evening, I found out that Hightower’s site was down. After reading several comments confirming it, I quickly went ahead and checked my site, noticing a few weird things with the player names as you can see below.

Yep, the most obvious indicator is the numbers “1.” and “2.” prefacing the player names, giving me the impression that he was trying to misorganize per-player statistics and screw up sites like Hightower and mine. You could’ve said I was, well, salty at this point but I was just disappointed that it stopped working and had burned out in a matter of days. I posted around that I’d continue to leave the site up (Hightower’s became a 404 page) with the statistics from over 2000 matches it gathered up.

Eventually, after attempting to grab the match info by other means, Hightower’s came back online with no further planned updates. Yes, this dream was over. But I did learn a lot from this incident:

• People appreciate a free product that can do better than a premium offering. It doesn’t take a genius to figure this out, but not only will the free product be embraced, but the person behind it. I sure was happy at the popularity of it.
• Node.js is awesome. I’m going to use it for future projects especially those centered around data scraping.
• You don’t need much power. I was hosting this on a VPS with 1GB of RAM, and it barely went above 200MB (along with the other services it was running in the background) and used only a few hundred KB per minute of bandwidth.
• People take their fake betting seriously. Just look at the Twitch chat.

Until next project folks. Remember, never bet on DBZ.