Server upgrades today (Planned Outage)

The underlying operating system on the servers that host Tootsville, Tootsbook, the Wiki-Wiki, and everything related are going to be upgraded today. This will mean that there will be about a two-hour window that we’ll be off-line.

We don’t yet have a “high availability” set-up because we’re still testing things, so during that time we’ll be totally off-line.

The last server reboot was 571 days ago, so this isn’t exactly a frequent thing! service on-line

We’ve just completed a shakedown of the service. This is based on the service from the Fabulous Adventuring Company, who donates a lot of technology support to Tootsville. is a short-link service that can be used by the game for sending links in e-mails and things like that. It’s a simple but important part of the technology needed to make the game easy for everyone to access.

There isn’t much to see, but the help page is visible at

Development progress report

With the holiday season upon us, our volunteer team isn’t moving as fast as they might, but progress is being made regardless.

The JSCL compiler that converts the Source Code, which programmers write, into the Object Code (JavaScript) that runs in your web browser is being stabilized this month. That means we should be back to working more on game features and less on the underlying system components. It also will make it easier to share our improvements to JSCL with others through the main JSCL project. This works both ways: others will be able to take advantage of improvements being made for Tootsville, and we’ll likewise be able to more easily incorporate improvements that others might make to the compiler.

In the arena of curators, some interesting pieces have been identified, including the beginnings of the Tooth Theatre film lineup. The first scheduled film will once again be The Cobweb Hotel — the same spooky classic cartoon that was played for the Theater’s grand opening 7 years ago.

Our servers are also playing host to a mirror of the Project Gutenberg library, a collection of classic books in the public domain. A selection of these books will be available in Tootsville itself to collect, read, and share.

The so-called “Robo-Toots” — non-player characters — are gaining conversation skills in a special offline “training” program. When this research project has been developed a bit further, Toot characters who don’t have any player accounts will be able to have fun conversations with players about their favorite topics. The artificial intelligence systems responsible for that are gathering knowledge about real-world topics through reading specially formatted “fact collections” and dictionaries.

There is still lots of opportunities for volunteering with Violet Volts in all kinds of areas, so if you’d like to share your talents and maybe learn some skills in the new year, and you’re 13 (with parents’ permission) or 18 years or older, let us know and we’ll be happy to put you to work 😀

Let’s Make Some Noise!

Volunteering Highlight: Integration Test Engineers

Integration Test Engineers build and observe tests to make sure everything is working as it should. is being built entirely by volunteers. Volunteering Highlight is a bi-weekly column where we explore some of the things that volunteers can do to help with Violet Volts, the project that produces Tootsville.

Continue reading “Volunteering Highlight: Integration Test Engineers”

New core policy document: Vulnerability disclosures

In our quest for perfection, security is one of the things we have to keep in mind.

Our vulnerability disclosure policy is now online on the Wiki-Wiki. We have also published a PGP (GPG) public key that can be used to send encrypted messages if you discover any such vulnerabilities.

Once the system is online, we’ll also be using the HackerOne platform to invite security researchers to audit our system and disclose any uncovered vulnerabilities.

Development, Testing, and Reliability

Hi,  this post is from Bruce-Robert Fenn Pocock. I’m the “Benevolent Dictator” 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.

Now, the first question on your mind, if you’re reading this, is “what’s taking so long?”

I’m going to start off by pointing out that building an entire world — particularly a shared, persistent, multi-player online world — 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 …) is hard. It’s going to take some time.

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 “only” on a big stack of expensive “cloud” servers like Res Interactive (and most on-line services) have done in the past. As programmers like to point out, “there is no ‘cloud’ — it’s just someone else’s computer.” Well, the Gossipnet system we’re developing for the game is based on the idea of running “your share” of the game on your computer. You can imagine that in a single-player game, your computer does all the work — 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.

Making it so that this system works, though, means that your computer has to “talk” 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.

So that means we have to “harden” 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 “shout out” to Hans Sense who’s helped me think through some of the particularly complicated things.)

What we’re doing, also, is trying to build things in a way that lasts. 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.)

Testing Partnerships

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 “patch” 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.)

Software tests — automated tests that the computer can use to verify that the programs are working as-designed — 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.

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, and Circle CI. The CI in their names stands for “Continuous Integration.” They “continuously” run our software tests whenever we “integrate” new changes into our code. The status of those tests is then displayed at as a “pass/fail” status. Since the “integrated” code is open, you can even “click through” and review the results. Getting the main component, the “violet-volts” 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 that these tests are failing, we know not to push that program out to our players.

Running this software across myriad systems means there’s a lot of — let’s call it “technological diversity.” 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™ Linux® computer with the latest stable release of Firefox™, and that’s OK. (If they did, though, it would sure make my job easier!)

That’s where our newest partnership comes into play. Over the next few weeks, I’ll be rolling out integration with BrowserStack, who have agreed (in exchange for some advertising-like mentions in our programming areas) to give us free, limited access to their library of over 1,000 web browser, device, and operating system combinations.

I’ve decided that the “advertising” they want is OK with the “no ads” policy because it will not appear to players, only people who are actively looking “under the hood.” Their links will appear on our GitHub page, the Developers page, the “about this program” screen, and places like this blog. The average player will probably never know, or care, about this partnership. What I hope they will notice is that we are able to detect possible problems with certain devices or browsers before we push out software to our players, which means less bugs reaching the player.

Are We There Yet?

It’s still a long ways to go before we can rest. The next Milestone will be our new Hillside Demo, and I don’t want anybody’s expectations to be too high. It’s not going to look like much. Your Toots won’t be able to do lots of things, yet. The goal of this milestone will be to make sure that the major pieces of the game are working: that players can log in, talk, move around; that the 3D scene draws properly on your display; that the software doesn’t crash or misbehave horribly when someone drops out of the game. These are really exciting things for a programmer, and horribly under-whelming things for a player. I can’t even promise that the Toots characters will be animated or have their patterns and colors on, yet.

Once we reach that point, though, things will start looking a little more interesting to you, as a player. You’ll be able to see as new features, new items, and so forth are introduced. Changes will build up and we’ll start checking off the “Issues” on our GitHub project pages one by one.

I hope that the Hillside Demo will still happen in 2016, but as you know, the holidays are coming and that always causes unforeseeable delays in “hobby” projects like this. So — no promises. It’s still possible, though. Hang in there!