I’m always a little reluctant to post about work that I can’t show you, but it’s about time for a development status update.
Over the holidays, I’ve been bolstering the messaging layer for EpicTable—that is, the layer responsible for communication between participants in a game. It’s what carries the chat messages, images, map updates, dice rolls, etc. While the messaging layer has been in place and working for awhile, there’s “sunny day working” and there’s “working despite obstacles”.
If you think of EpicTable as a character, it’s leveling up and taking a few additional points in the Messaging skill, so that when it’s faced with a couple -2 or -4 penalties, it can still make the roll.
What kinds of things call for a Messaging skill test? At any time, a player could terminate unexpectedly—say, he experiences a power blip or his computer freezes. There’s not much I can do for that player, but this should not adversely affect the others, and when that player comes back online, he needs to be able to rejoin smoothly. If the game’s host has a similar problem, the players should be notified that the host has gone and be seamlessly rejoined to the game when the host returns.
In addition to system failures like this, there’s plain old network failures. Unlike a web browser, which connects to the web site on each request, EpicTable maintains a connection to the game host. If messages are missed or late or if the connection is broken for some reason, EpicTable needs to smoothly reestablish it.
These are some of the scenarios I’ve been testing. Sadly, there’s not anything I can show you, and no one’s ever going to say, “Wow! I really love the new messaging, John.”, but I don’t begrudge the time spent on it. Messaging is one of those things that has to just work. I’ve used some software that relies on persistent connections and doesn’t handle failures, and the experience is incredibly frustrating—not at all epic.