Malware affects 1 million Google accounts

A recent malware (a virus-like program) has affected over 1 million Google accounts. To see if you were affected by this particular attack, visit:

To make sure your Google account remains safe, you can also use Google’s Security Checkup tool:

This does not directly affect Tootsville, except that we use Google accounts to sign in. We also want to make sure that all our players are safe!

We’re pretty sure Shade didn’t do it, this time.

BrowserStack automated testing

BrowserStackAs mentioned in Development, Testing, and Reliability, we’ve been in touch with to get access to their systems for testing. I want to offer special thanks to Pritha Bannerjee with BrowserStack’s support team, who has been most helpful in getting us this access.

You’ll see that we’ve added some brief information on linking to their site. Soon, we should have some test automation set up to take advantage of this service.

Speaking of which … have you considered making a hobby of developing tests for Tootsville?

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. Legacy Players Mail

We have obtained a list of many of the e-mail addresses of parents who requested news and information e-mails from It’s uncertain exactly when this list was made, but it seems to date from around August or September of 2009.

This list has the e-mail addresses of parents who ticked the option “please send me news and updates by e-mail” when they logged in to around that time.

Beginning now, and running through Friday, we’ll be reaching out to them with a message like the following.

Hopefully, this will let our legacy players reserve their Toot names now, and maybe find some old friends who haven’t heard about the new game yet.

Continue reading “ Legacy Players Mail”

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!