Introduction

This is actually a rewrite of a project that goes back to 2016. It started as an IRC bot that announced the start of Blood Bowl games on FUMBBL so that users could tune in and watch the games. Nowadays it also lets users place virtual bets on said live games.

Blood Bowl is a game of fantasy American football set in an alternate Warhammer Fantasy setting. Originally a miniatures board game, it can also be played on the computer through it’s video game adaptation, or Fumbbl. Fumbbl is a website that lets you play through a java client.

A game of Blood Bowl on Fumbbl.

Another game in action.

Pulling live games

When I started the project back in 2016, Fumbbl didn’t have a public API that listed the currently live games. With the terms of service not forbidding it, I went ahead and decided to get the data myself by directly scraping the webpage listing the live games.

I investigated the HTML code of the page and looked for ways to iterate through the relevant data.

The information is a series of nested divs, with the class telling us its type. Because the bot is only written for the tournaments run by the league I play in, we’re only interested in the League Tournaments section.

We will iterate through every div starting from the League Tournaments class. First we find the tournament class, telling us to which tournament the following matchrecord withtournament match belongs to. Coincidentally, the URL of the tournament points us to the league running the tournament, so if it matches with ours we store the information.

Looking back at this, I would replace the magic strings with adequately named constants. I would also provide the list of valid groups from a config file.

Furthermore, if the group doesn’t match ours, we continue iterating through it anyways, only discarding it at the end of the iteration. I would skip entirely the matches we’re not interested in.

Now we iterate through the children nodes to get the match details.

And finally, if the group matches ours, we instantiate a new Match, add it to our dictionary of matches, and iterate to the next div sibling until we reach the div with the Gamesfooter class, at which point we return our Matches dictionary.

Again, we could save up time by only checking for the group once at the start, skipping iterating through divs we don’t want.

The matches will be saved in memory. Every minute we will check for matches, compare them with the ones already in memory, and if they don’t already exist in memory, that means we have a new game and we send an announcement with the link to watch the match.

Because we store the matches in memory, if the program is restarted during a match, it will announce it again. This is how the program worked before we added a database.

Virtual Bets

The system for virtual bets was inspired by SaltyBet. A fight between 2 characters is streamed on Twitch, and users can place a virtual bet on who the winner will be.

This system can easily be translated for Blood Bowl games. The only difference is that games can end in a tie. However, to implement all of this we need a database.

Originally, I used SQL Server for the database. While SQL Server and SSMS are excellent tools, I would’ve prefered something simpler given the small scope of the project.

During the rewrite, I also experimented with Entity Framework Core. I was amazed at the convenience EF core offers, but I wanted to get more practice with SQL, so I also discarded that.

In the end, I ended up using SQLite due to its ease of use, setup and portability. There won’t be a large amount of concurrent operations, and the dataset won’t be big.

There’s not a lot of queries but it’s all relatively simple. We create, we read, we update and we delete. There are still some queries that need to be written to implement more features.

Something that is still missing is creating the database if it doesn’t exist. The current one was manually created as it was being developed.