Hi,\u00a0 this post is from Bruce-Robert Fenn Pocock. I’m the \u201cBenevolent Dictator\u201d of the Violet Volts project, and the author of the game system from Tootsville IV and the new Tootsville V. Today I’m going to talk a little bit about (a) Why is it taking so long to get back online? and (b) Software testing and some great partnerships that are helping us with that.<\/p>\n
Now, the first question on your mind, if you’re reading this, is \u201cwhat’s taking so long?\u201d<\/p>\n
I’m going to start off by pointing out that building an entire world \u2014 particularly a shared, persistent, multi-player online world \u2014 is a pretty big job to begin with. Doing it in people’s spare time and with no budget (well, my husband and I are footing the bill, anyway, and we love y’all but if we go broke doing this, it all goes away \u2026) is hard. It’s going to take some time.<\/p>\n
We’re doing it the hardest way possible in order to build in some reliability that most software just does not need to have. For one thing, you may have seen mentioned, we’re not going to be running this game \u201conly\u201d on a big stack of expensive \u201ccloud\u201d servers like Res Interactive (and most on-line services) have done in the past. As programmers like to point out, \u201cthere is no \u2018cloud\u2019 \u2014 it’s just someone else’s computer.\u201d Well, the Gossipnet system we’re developing for the game is based on the idea of running \u201cyour share\u201d of the game on your computer. You can imagine that in a single-player game, your computer does all the work \u2014 say, in Pac-Man, your one computer handles not only your actions as Pac-Man, but also moves the Ghost Monsters around, as well. In Tootsville V, your own actions will be handled by your own computer.<\/p>\n
Making it so that this system works, though, means that your computer has to \u201ctalk\u201d to everyone around you. The biggest problem with that is that your computer is probably not a failure-hardened Internet server with a great network connection and power back-ups. It’s more likely to be a laptop computer on a WiFi connection where you might, at any moment, close the lid and put it to sleep, or microwave some pizza and disrupt your wireless connection, or try to close an annoying message from your buddy and accidentally quit Firefox and drop out of the game altogether.<\/p>\n
So that means we have to \u201charden\u201d the game against any one (or more!) computer dropping out suddenly, and make sure it doesn’t cause a disruption to other players. It’s a kinda new way of building things, and it’s usually done with server machines in datacenters, not a game being played in web browsers, so we’re inventing new technology as we go along. (I’m going to speak up and take most of the credit for this, myself, but I do want to particularly give a \u201cshout out\u201d to Hans Sense who’s helped me think through some of the particularly complicated things.)<\/p>\n
What we’re doing, also, is trying to build things in a way that lasts<\/em>. The goal here is to create a new Tootanga that can keep on going with very little costs. That means we don’t have to get a lot of donations to keep on running, and even if something happens and my family can’t keep paying for it, it won’t be too expensive for a few people’s donations to keep things going forever. (The expenses are all listed on the Wiki-Wiki, by the way. We are dedicated to being totally transparent about the operation of the game.)<\/p>\n Testing Partnerships<\/strong><\/p>\n As a side effect, we need to ensure that all our software is as reliable as possible. The last thing we need is a software glitch causing problems when it’s running on hundreds or (we hope!) thousands of web browsers around the world. (We are also making plans for how to \u201cpatch\u201d bugs, as they are discovered, in all those running systems, while you’re still playing the game, without interrupting you. But, that’s another story.)<\/p>\n Software tests \u2014 automated tests that the computer can use to verify that the programs are working as-designed \u2014 are the key to that effort. Running these tests is partly the responsibility of the developers. While I make changes to the software, I periodically run some (or all) of these tests to make sure that everything is working as expected.<\/p>\n In order to ensure that these tests run before any changes make it to our players, we also have taken advantage of opportunities offered by both Travis CI<\/strong><\/a>, and Circle CI<\/strong><\/a>. The CI in their names stands for \u201cContinuous Integration.\u201d They \u201ccontinuously\u201d run our software tests whenever we \u201cintegrate\u201d new changes into our code. The status of those tests is then displayed at http:\/\/tootsville.org\/development\/<\/a> as a \u201cpass\/fail\u201d status. Since the \u201cintegrated\u201d code is open, you can even \u201cclick through\u201d and review the results. Getting the main component, the \u201cviolet-volts<\/strong>\u201d program that actually creates the game software itself, totally working in the test environments has been a challenge; as I write this, it’s still failing. That’s a good thing, though: By knowing<\/em> that these tests are failing, we know<\/em> not<\/strong><\/em> to push that program out to our players.<\/p>\n Running this software across myriad systems means there’s a lot of \u2014 let’s call it \u201ctechnological diversity.\u201d Different devices, different operating systems, different screen sizes, different web browsers, all can influence how the game program works on your own computer. Not everyone has the luxury of running Tootsville on a high-definition display on a Fedora\u2122 Linux\u00ae computer with the latest stable release of Firefox\u2122, and that’s OK. (If they did, though, it would sure make my job easier!)<\/p>\n