SPA's Brain

I wrote a webapp to handle the most tedious parts of a favorite game I play from time to time, Star Fleet Battles.

5 months ago

Latest Post SPA's Brain by Tracy Parks

Unless you've been living on Mars for the past few years, you are probably aware of COVID-19 and all the fallout from it. Like many others in the world, I've had a great amount of spare time to spend doing things that I'd always had time to put off rather than just do it.

A long time ago I was introduced to a game called Star Fleet Battles, which is a tactical board wargame dating back to 1979 but has had a few rules revisions over time. Back in the day, I'd play this every Saturday night with a bunch of friends at the local game store/hobby shop that I used to work at. One thing I remember that really bogged the game down was the copious amounts of rolling up the damage. Well that was part of the slow down. It could take upwards of 15 minutes just for a couple of players to do a set of average damage. In a game that might have a few groups going at a time, this was 15 min of the rest of the group waiting for all the damage to be resolved.

The method for figuring out the damage is relatively easy, but it can take so long due the the amount (30 points of damage is not unheard of) and the need for the dice to be rolled in matching sets.

As an example, let say a ship takes 10 points of damage, the attacking player then rolls 2D6 (2 standard six sided dice). The total result is then compared to a Damage Allocation Chart that is provided with the game. The chart is comprised of 11 rows and 14 columns, where the rows correspond to a dice result (2 through 12) and the columns correspond to levels of damage sustained on the various systems on a ship. There are more nuances regarding the procedure for looking up the results - such as the third weapon result must be the best type, the fact that there are cells in the chart that are unique and can only be hit once, or that some ships don't have all the systems represented on the chart so those must be passed over - but that is all there is to it.

So with all that in mind I realized that this could be "easily" programmed on a computer. Well, thanks to COVID-19, I had the time to actually do it.

Computers make excellent and efficient servants, but I have no wish to serve under them.

First thing I tried to program the app in was Angular. After some fighting with Angular I realized that I didn't want 10,000 files in the app before I even started programming it. I felt that this wasn't complicated and robust enough of an app to warrant the need for all that memory hogging and performance reducing detritus so I moved over to Python to see if I could at least work through the logic of it all. I needed to see about storing the session, ask the user if the result was valid, process multiple iterations of a die roll, etc. So I thought Python would be a great way of keeping my Python skills sharpened as I don't get to use them that often.

After about two days, I had a working model of the program running and running as intended. After plying with it for a while I came to realize that Python had some shortcomings. One being that I really could only use this app I wrote in the Python environment. Sure I could easily port it over to a web app, but then there was that "I didn't want 10,000 files in the app before I even started programming it" that I would need to contend with.  Just because you can do something, doesn't mean you should do something.

I did fudge around with creating the webapp at first using Flask, but I started to hit some walls as I really hadn't thought through the whole user flow and what I wanted the app to look and function like visually. Up until that point it had just been a text based terminal app and up until that point, I really just had the idea to make something that could process the damage allocation nearly automatically; some user input is needed as every ship is different.

Change is the essential process of all existence

I plunged into making the wireframes for the app in HTML/CSS. I took a look at some frameworks, but I finally settled on Bootstrap 4 as I thought the basic look and feel fit with the original rule set for SFB. I also settled on Bootstrap over my own framework as I really didn't want to spend too much time sloggin through developing new things when they are already been built. I was itching to get this app up and running on the web so that I could really play around with the UI of it to work on improvements.

I ported my Python code over to VanillaJS so that I could work on things "live" and I am glad I did. Doing so made me see better methods of processing the rolls, accessing the chart, etc that I nearly re-wrote the entire thing from the ground up in JS. The GUI opened up so many possibilities and enhancements that I have come to appreciate the need to plan things out, program them, take a step back and look at the results, see the flaws and the opportunities, and start the whole process again with replanning based upon the insights gained from the previous steps.

In the end, I learned so much from this that I had to write about it. Again that whole "got time on my hands with COVID-19" like everyone else. I plan on making this a bit more robust and fleshing it out more, but it is currently fully functional and is an actual Single Page Application, unlike the other SPAs that have an arsenal of files behind them to make even the smallest easiest thing work.

Tracy Parks

Published 5 months ago