LabMUD is now open for players. We’re doing a soft release this weekend (as of the time of this post), where we’ll be accepting people and letting them get into the lab early. We’ll do a formal launch even next weekend where the actual metaplot will begin.

Note that during the first week I expect you guys to find a lot of problems leading up to the official release and hopefully we can sort them out. If you want a smoother experience, wait for next weekend.

Otherwise, please come join us in the Lab!

2017 State of Play

Hi everyone,

I thought that I would give a bit of a “Where the hell are we at?” update to mark the turning of the year. I’ll reflect a bit on the journey so far and talk about what’s next.

Journey So Far

2017 is 8 years since I got the idea of making the FutureMUD engine, and 5 years since the C# rewrite. It’s also the 3rd year of work on LabMUD and we’re nearly approaching 2 years since we announced we were opening LabMUD and then failed to do so.

It’s probably fair to say that we disappointed a lot of people along the way; it has been a very long time. The reality is FutureMUD is still a one man team, as it has been since 2012. I’m not a professional software engineer and I have proven to be really bad at estimating the time it takes to complete coding tasks, although the main issue is time commitment to the project.

One of the big time sinks has been becoming a father, something I wouldn’t change for the world. However having a baby (now toddler) around the house does not make for a very peaceful environment. I probably could have demanded space, time and solitude to work on FutureMUD but that wouldn’t make me a very good husband or father.

I’m also now 30 years old, and at the real prime time of my career – by day I am a District Engineer who looks after around 1500km/950miles of mainline railway track. I recently got an internal promotion as well. A lot of this has meant working longer hours, travel, networking, attending functions and such in what would otherwise be my free time.

Why does this matter? Well, from time to time people have floated ideas like “Why don’t you do kickstarter/patreon and get funding to work on the engine full time?”. The answer is y’all couldn’t afford me. RPI MUDs are pretty niche, and I have a history of over-promising and under-delivering. I couldn’t justify taking time off my job that pays better than $75 USD an hour (seriously kids, study STEM subjects…) for the likely starving artist or worse level of funding I’d get.

Nonetheless I do still find time to work on it all. Less than I’d like, but it has come a long way. According to my stats on Git, since May 2015 I have made 600 commits to Git, changing 290,000 lines of code – although the codebase itself is 95,000 lines (many of those lines will have been changed multiple times along the way, hence the large number).

Where are we now?

The codebase as it stands now is actually further along than what I had said I wanted to wait for when we delayed launch in May 2015; it’s probably more fully featured than SOI was when it launched in 2003 and almost certainly more fully featured than Atonement Alpha was. The only thing on my “List of Excuses not to launch List” that isn’t done is probably crafting, and that’s like 50% done.

In terms of building, LabMUD is mostly done for its phase 1 objectives. There is only one core area of building that needs to be worked on and it’s one of the “Gameplay Systems” that we wanted to launch with, one of the “Something to do to give people things to struggle with and fight over” type areas of content. It’s not far from being done either, just needs some solid time spent on it.

As most of you have stopped paying attention to LabMUD in the intervening time and I probably won’t even get all of you back for launch, a lot of the pressure to just get it open has been lifted. I’m sort of focusing a bit more on releasing a game that will be a little more on the “finished” side and a little less on the “test for the devs” side. At least, finished in the sense that it’s stable and reasonably feature complete. More of a beta than an alpha.

What’s the plan?

I’m targeting an Easter release at the moment. I’ll have crafting done by then, it’s the only big coded system that needs finishing (mob AI could probably use a bit of work, but I’d open without it). When I am ready to go, this time it’s for real, for better or for worse. This gives me a few months to do what I need to do, continue to fix bugs, and then get going.

Once we’re open, we’ll stay open and fixes will come in incrementally as well as new content. I’m hoping 2017 is the big year.

And thank you to those few diehards who’ve kept up with the project and have really driven the testing over the last year. You know who you are.

Quick Update

Here’s where we’re sitting, in terms of building required to get LabMUD open to player characters:

  1. Progs (15 or so, of varying difficulty.)
  2. Set up forage system.
  3. Build two/three more NPCs.
  4. Fix time/celestial object issues.
  5. Complete helpfiles (at least the basic ones.)

Obviously the opening of the game still hinges on combat being in in its most basic form, but that’s up to Japheth. From a building perspective, things are getting pretty spare… And that’s even with me making up work for myself to feel accomplished. Arguably, #4 is a bug, and requires some digging around in the code to sort out. #1 and #2 will take the most time. #3 will probably take an hour, hour and a half or so, tops. #5 may require some work as well to flesh out fully.


There are a total of 423 rooms, 115 items and 3 NPCs built.

In terms of number of rooms, that should be relatively stable now come launch. Items will uptick a bit, as I’ll need to put 20 or so in for foraging to feel varied, and the number of NPCs will increase slightly.

Anyway, we’re still (hopefully) on track for a mid-April release. Won’t likely be in time for an April 1st launch but… well, I can dream.

Determining Staff Policy, Part 3

As in my last post, I’m going to continue discussing some of the questions that tend to come to the fore during staff policy debate, such as whether or not (in games large enough to warrant it) staff should rotate between spheres, or be permanently assigned to one sphere.

Rotating assignments vs. permanent positions?

Shadows of Isildur was, and continues to be, a prime example of permanent positions among members of staff. On SOI, you were generally hired to do a particular thing, in a particular area, and were expected to remain in that area for the duration of your administration. You might move within that sphere, from trainee to senior leadership, but you never generally left that sphere. Those who did leave often only did so because that area of the game had been closed, or because another area had lost all qualified staff and required immediate, emergency oversight. Meanwhile, Armageddon is an example of the opposite principle at work: staff rotation. Staff are hired on and rotated among the different areas of the game, spending a scheduled amount of time in each area before being cycled elsewhere. While they are hired on to perform certain tasks, they are not hired on to do them solely in a single area of the game.

Both positions have their advantages and drawbacks, but the obvious edge goes to, in my opinion, rotating staff assignments.

In permanent positions, it is easy for a staff member to become too endeared to their own specific sphere. This endearment can cause friction between other members of staff, in separate areas of the game, and friction between players outside of that sphere – especially if they are antagonistic to that sphere. Everyone, after all, wants “their side” to win. And while one of the obvious benefits of permanent placement on staff is that the staff member in question collects a wealth of knowledge about their own sphere, and understands its intricacies intrinsically, that same staff member, taken outside of their sphere, knows nothing. If they are the only soul online among administrative staff, and a player comes to them with a question, and it is outside of their sphere, they will often inform the PC it is outside the scope of their ability and then wash their hands of it. More times than I can count, as a player in Shadows of Isildur, I was told there were no staff online who could help me with a simple request because “it was outside their sphere” – despite there being three or four staff members online at the time. Rotational staff positions at least force the individual staff member to familiarize themselves with other areas of the game, in addition to also limiting some over-familiarity with any single sphere, and allow the staff member to assist in resolving more issues among players than they would have been able to do otherwise.

How do you fairly investigate complaints about staff members?

Another question that crops up from time to time involves formal staff complaints and how they are handled among members of staff. Do you allow the accused staff member to prosecute themselves, do you appoint a jury of their peers to judge them, or does one head staff member personally investigate the claims? And what constitutes a legitimate claim? Are all claims of abuse investigated, regardless of the source, or are some players less reputable than others, and are their claims then less valid?

There is no easy answer to any of the above, and regardless of how you decide to handle complaints against staff, there will always be players who cry bias against themselves and corruption elsewhere. And they will always be half-right; there is always that potential for abuse, even if it goes unrealized. In many cases, speaking as a former indignant player, the potential for abuse is enough.

The most ideal situation is probably impossible. In my opinion, the best solution would be to contract out the investigation of complaints against staff to a third party – a group that is unfamiliar with both the players and staff of your particular MUD, but has experience with MUDs in general. It would allow them to be as impartial as possible, limiting the accusations of bias, while still remaining familiar with how MUDs work. Given how small the MUD community, and the RPI MUD community specifically, is, however, I doubt this would be realistic.

What may be more feasible is a triumvirate of investigators – one appointed to lead the group by the game owner, and two others to weigh in on evidence for or against the accused: one, appointed by staff as a whole, and the other voted in by players. These three individuals would be players in that they would have no admin privileges – they would not be able to log into the game as an admin, would have no access to staff forums, etc. Or, at least, not until a complaint is raised. Then the lead investigator would be given the ability to browse certain staff forums and to, with discretion, browse game logs pertinent to the issue. They would gather evidence, and detail that evidence to the other two investigators in a forum dedicated to such things. The three would then come to a conclusion and present their findings to head staff – punishment would be meted out based on predetermined rules and regulations. The triumvirate would return to being players solely, until a complaint is raised again.

All complaints would be investigated equally, but there would be clearly stated punishments for players who submit repeated, blatantly false reports. And there would be transparency – players would be informed of major infractions by staff members, should they be found guilty, and when/if a staff member is fired for a major infraction, players would be made aware. There would be no graceful exit for staff who have broken the rules. Those staff members who do not break the rules, however, and are being fired for other reasons (such as generally just being useless) would be allowed to step down gracefully.

Perfect solution? Certainly not. In fact, I’m still not certain I like the setup, and have no idea if it would work in practice in a game. But until I find something better, that’s where my thoughts lie.

Determining Staff Policy, Part 2

In my experience, there are a few common questions that tend to get floated in discussion about staff policy. I’m going to limit my aimless rambling a bit, and attempt to address those here – but more than ever, the following post is written from my own very specific perspective, coloured by my own experiences as both a former member of staff, and a former player on various RPI MUDs.

Should staff be able to play PCs?

Years ago, Shadows of Isildur used to have a policy for new staff members: upon joining staff, you would be required to retire your current PC. You were not limited from playing new PCs once on staff, but there were some theoretical limitations regarding just how far in an organization that player-character could now climb, etc. Unlike players, staff on SOI were also not limited to playing only one PC. Instead, they were given unlimited player-character slots, and usually given as much RPP (roleplay points, a currency used by players to buy the ability to play different roles and restricted races) as they needed in order to create characters of their choice. By the time I was a staff member on Shadows of Isildur, this policy of retirement was largely gone. Instead, staff members were often as much hired to administrate, build, and run plots as to oversee the clans their own PCs had risen in the ranks of. For example, certain staff members, as players, had created player-run clans. These certain staff members, upon becoming administrators, turned these player-run clans into staff sanctioned organizations with a firm place in the lore of the game, and high levels of support, and made their own characters (who they still played, who still ran these same clans) often into the equivalents of barons, lord captains, or kings.

I believe Armageddon has a similar staff policy, and that new staff members are required to retire (or, in Armageddon terms, store) their current PC upon becoming staff members. As in Shadows of Isildur, Armageddon staff are not forbidden from playing PCs, only from playing PCs within the area they are currently staffing within (and I’m not even sure if that is a hard rule, or just rumor.)

So, should staff be able to play PCs?

In my opinion? No.

When staff members are allowed to play PCs, whether these be characters they created before or after becoming an admin, friction is introduced between that staff member and every other player-character that potentially interacts with their PC.

MUDs, RPI MUDs especially, are intentionally very intimate games. They encourage players to invest in their characters – to invest in them repeatedly, mentally and emotionally. And when these characters die, all that expended effort goes up in smoke: all that time is wasted, all the clever things you wanted that character to say are left unsaid, all their plans are undone, and all those emotional ties formed between that character – and yourself – and other characters are severed. Losing a PC can be, at best, a frustrating experience. At worst, it can be depressing and, for some, quite traumatic. Often years are put into a PC, and often the death of that PC is senseless. Players form close bonds with their characters. Sometimes, too, those bonds cause the line between OOC and IC to blur – people begin to identify too closely to their PC, and take fictional threats against their PC as legitimate offenses against their own self. Players become defensive, fostering a “me against the world” attitude. They become reactionary.

Staff members should never, at any point, be put into a position to develop and display this attitude. The role of an administrator on a RPI MUD is, in my opinion, that of a facilitator. When staff members are allowed PCs of their own, regardless of the situation, they develop attachments that bias them against other players and staff members. They may not intend for it to happen, but it is unavoidable. And reactionary staff members no longer facilitate for others.

Why do RPI MUDs allow their staff to play PCs if there is so much potential for harm, intentional or unintentional?


A MUD is a game, and games are supposed to be fun. Players have fun by playing their characters, by developing them – skilling them up, making friends, gathering good equipment, exploring strange lands, crafting new items, etc. By depriving staff members of their characters, there is the general belief that you are depriving staff members of fun. And let’s face it, staff members are volunteers. They aren’t getting paid for any of their hard, often tedious, thankless work. Shouldn’t they be allowed to have a little fun to preserve them from burn-out and frustration down the road?

No. No, because staff members that require a character to enjoy themselves are the wrong sort of staff to be hiring on in the first place. There are a variety of gamers out there – not all of them get their rocks off on that emotional bond that forms between themselves and their character, and their character and other characters. There are plenty of people who do not need to play a character to enjoy themselves, and those are the sorts of people who thrive best in administrative roles on MUDs. These people derive enough enjoyment out of world building and the creation of stories, and the reactions of player-characters to their stories, to make playing a PC pointless. But they aren’t often the people who end up on staff. The people who tend to end up on staff usually have had staff watching them for ages before being approached, or accepted – and they’re being watched in the first place because of the quality of their character, and the intensity of character-to-character interactions. And anyone defined by their character, first and foremost, is likely the sort of person to truly miss not playing a PC. Depriving them of a character will make them miserable, and they will not be a good staff member for it. Not depriving them of their character, and allowing them to administrate on a MUD, will encourage them to lash out preemptively against any threats to their PC. They will feather their own nest at the expense of others.

In Shadows of Isildur, there was a player who joined staff. They identified strongly with their character – and had a history of doing so with their characters. Their character happened to be in a moderately powerful position, and was moderately long-lived by the time they joined staff. They were chosen to join staff because their character was long-lived, and had proven successful in their leadership position. (Leadership qualities, the ability to create roleplay for others, were highly prized in staffing applications.) In addition, they proved through the successful, multi-faceted persona of their PC that they could create deep, enjoyable characters. After joining staff, they were not required to retire their PC. Their character’s organization became a mini-sphere within their area of the game, and they were put in charge of it directly. Their character became the equivalent of a duke, with unparalleled power – though they were still beneath NPCs, in theory, there were no PCs above them. They could execute any PC at their leisure, for any reason (or no reason.) And, besides, the NPCs above them were directly animated by them.

This staff member began to religiously snoop the rivals of their character. They began to build custom weapons, armor and clothing for their character, and the friends of their character. These weapons and armor were some of the best in the game. Rooms were added onto the game to house this staff member’s clan. An entire mini-sphere was constructed, just for their character’s groupies. They built NPCs that were wildly unbalanced, to serve as their character’s personal bodyguards, and, if any other members of staff commented on it, became rabid and aggressive against them. They began to ignore other portions of their assigned sphere, prompting another call for new staff members to pick up the slack, and instead began to focus exclusively on their own character’s monkey sphere.

One day, a PC, after offending that staff member’s character, was arrested by NPC guards animated by that staff member, and thrown into a prison that staff member had built exclusively for their character’s organization to utilize. That player, complaining of bias, logged off after being told by that staff member OOCly that they were going to be executed – after a long rant at the PC by the staff member, berating them for their “unfounded accusations” against their character. The staff member, incensed, removed all RPP from that player’s account, retired their PC for them, and then created a NPC clone of that player’s PC. They then, multi-boxing to play both their staff avatar and their own PC at roughly* the same time, brought the NPC prisoner, the NPC guards, and their own PC to a public square. They announced across the zone that a mini-RPT was in progress. When people arrived to see what was going on, they staged an elaborate execution of the NPC of that player’s PC, in (likely) one of the most confusing and neurotically smug events in the mad history of that section of the game. They roleplayed that the NPC had pissed themselves in fear, had blubbered and begged for their life, and sobbed like a baby during the affair.

When the player logged into their account at a later date, attempted to log into their PC, and questioned why they couldn’t, they were informed their PC had been executed and they were now banned for a week because of their own poor attitude. The player logged back out, and never made another PC on Shadows of Isildur – despite, prior to this event, having had an exemplary track record, a history of mid-level leadership in clans, and an investment in roleplay.

Thus – staff members should not be allowed to play PCs during their tenure on staff, regardless of the situation. Staff members should instead be hired who derive their enjoyment of the game through world-building, the creation and successful implementation of plots, and through the observation of the interweaving stories of the characters in game. If staff members truly miss those interactions with player-characters so much, let them either animate NPCs for brief periods at a time, furthering their own enjoyable plots for the sake of others – or let them resign and return to being a player.

No exceptions.


(*On SOI, you couldn’t log into two characters at once from the same computer. It was possible, however, to force one character to go “link-dead” without quitting the game legitimately, by crashing the client or resetting your internet connection, leaving them in the game, and then log on afterwards as your staff avatar.)

Determining Staff Policy, Part 1

In this post, I’m going to try to focus on the reasons why a stable staff policy is absolutely vital, and the reasons why many MUDs out there seem to lack a coherent, quantified staffing policy. I won’t touch yet what I think makes a good staff policy – but I want to provide background for how I think problems arise, and how they can continue to persist even in successful games, and lay the groundwork later for discussing how to avoid these pitfalls.

In my experience, the genesis of most MUDs (note: my experience is almost exclusively limited to RP encouraged or “RPI” MUDs) is not a well-planned thing. Most MUDs come about either spontaneously, as when a few close individuals with a similar idea have ready access to a code base and the tech know-how to set up a MUD, or reactively, as when a (again) few close individuals disillusioned with their current game decide to create a better, idealized game for themselves, lacking in the same perceived problems their original game had.

Shadows of Isildur was created by staff who were disillusioned with their current game’s direction and left to make their own, better game. Likewise, Lost Tales of Beleriand was created by former SOI staff disillusioned with the current direction of Shadows of Isildur. Atonement, too, was created by staff who were disillusioned with Shadows of Isildur’s direction and left. Parallel RPI, Mirrors, and the various other MUDs that grew out of the RPI++ Engine were largely founded by (again) disillusioned staff upset with Atonement’s direction – or lack of direction after it closed. They left to forge their own way. Shadows of Isildur itself, disillusioned with previous incarnations of Shadows of Isildur, closed and reopened several times under largely new staff direction each time. Black Sands, created using the RPI Engine, was created by players disillusioned by the direction of another well known RPI, Armageddon. Black Sands isn’t the only MUD (not by far) created in reaction to disillusionment with Armageddon staffing policies and direction, but it is probably the most successful of the attempts. As I’m most familiar with the RPI Engine family of games, I’ve focused my attentions there. And I think I’ve made my point.

Again, not all games are created as a direct result of disillusionment and jaded staff (or players) – for example, take a new MUD, currently in its early Alpha stage, running on the RPI++ Engine: Lautolae Springs. It’s the perfect example of a MUD’s genesis being influenced by a few close friends and a shared goal. At any point in time, there are nearly half a dozen MUDs in development like Lautolae Springs, created by friends and run by friends. Whether they succeed or fail matters very little to me for the purpose of this discussion – what matters is that, almost exclusively, these games are run by a close-knit community that will police itself to its own unspoken standards.

Staff who know each other and trust each other do not need to worry about codifying a detailed set of rules and standards, and because they do not need to worry, often do not bother with staff policy at all beyond a few broadly stated ideals that can be largely boiled down to: “be fair.”

While games are small, and the staff who maintain those games are close-knit and trustworthy, the rule “be fair” is often enough. But staff turnover in MUDs is historically quite high, and often after a game is opened to players, divisions arise where previously there had been none. When games are still being built, everyone is on the same page, and it’s “us against the world” – but once those games allow players to create and play characters, real life tends to encroach, or boredom, or staff members realize that they would rather play in the world they have created than oversee it. Even though staff members are volunteers, their workload can be as tedious and mind-numbing as in a real job.

Regardless of how it happens, new faces replace old ones, and staff numbers tend to expand. New staff members, rather than being a part of the close-knit circle of staff who originally created the game, have their own friendships and loyalties outside of staff. Staff members are no longer close-knit, but instead become competing heads of various cults of personality. “Us against the world” becomes “me against you” – and it’s not uncommon once that occurs for staff members to complain that other staff members are ruining their fun, destroying their sphere, harming their clan, or unfairly biased against their favored players. Sometimes their complains are legitimate (after all, it’s now “me against you” for all parties involved) but other times these are knee-jerk accusations leveled at staff members who are still trying very hard to adhere to the golden rule of “be fair.”

As Atonement sits more freshly in my mind than Shadows of Isildur, and those are the two MUDs I am arguably most familiar with, I’m going to use Atonement as an example of… well, all of the above.

Atonement was created by the Northlands sphere staff of Shadows of Isildur. Their sphere lead, Songweaver, was upset with the direction of the game – more specifically, he was upset with some of the other members of staff, and the abuses of power he had witnessed during his own tenure. The Northlands team left to create their own MUD, united from their struggle against power abuses, but wholly lacking a unified idea from which to base a game. Instead, a number of ideas cropped up: one staff member wanted the setting of the game to feel very much like the Wild West, with a small town positioned on a trade route between large nations. Another wanted a sleek, sexy cyberpunk game with lots of neon glow, and a chic Parisian atmosphere. Another staff member wanted the game to take place on a prison ship orbiting Earth, where gangs fought over automated shuttles delivering food. Another staff member wanted the game to take place on a terraformed Moon, while the Earth hung holocaustic and dead above the horizon.

To appease everyone, compromises were made that ended up alienating everyone instead. It was determined that each setting would be given its own pride of place eventually. The first stage of the game would take place on a space ship with limited resources. The second stage of the game would take place in a small town on the moon, with a Wild West vibe. The third stage would take place on Earth, in a glossy, glamorous future Paris. The staff member who championed their setting would become the lead of the stage that their setting sat in. Crisis averted.

The problem, of course, was that this compromise averted nothing. The staff member who championed the spaceship setting was not a builder and had no interest in building the game. The staff members who did build had no interest in building Alpha because it was not their version of the game, and they had nothing invested in it. Interest waned. Those staff members who were waiting for the later stages of the game to roll around ended up leaving as other games, and real life, took precedence. When the Alpha stage of the game was eventually completed using volunteer builders, the game had nearly no staff left to speak of out of their original crew. New staff were eventually hired. Staffing policies were not ever clearly detailed, which would lead to friction down the road when those new staff (now running the game with newer staff under them) came into conflict with players over accusations of staff abuse, favoritism and corruption.

As tempting as it is to put off a robust staff policy until the game is more popular and stable, there’s a good chance that if it isn’t built alongside the rooms, objects and NPCs of a MUD, the staff policy won’t be fully actualized at all. Without clearly detailed policies, there will always be mistrust between players and staff – and confusion among staff on how to act among their peers, as caretakers of the game.

The question remains: just what the hell makes for good staff policy?

Welcome to the Lab (alternatively: Watch This Space)

Hold onto your pants. With FutureMUD development proceeding smoothly, it’s finally time to get the ball moving on LabMUD.

Wait, what is LabMUD?

LabMUD is, as evidenced by the header, a demonstration MUD. It’s meant to showcase the FutureMUD engine during early development, and to act as a platform for balancing and bug-fixing while still running as a fully functional RPI. That means it is (or will be) fully open to players, volunteer staff members, and be as (in time, at least) full featured as any future FutureMUD engine game. Roleplay will be enforced. Permadeath will still exist. The difference between LabMUD and, say, any other fledgling RPI with an evolving codebase is that LabMUD exists primarily to introduce new systems and code to unfamiliar players and staff members in a controlled, (hopefully) fun way. While LabMUD may outlive the development cycle of FutureMUD, it is not envisioned as a standalone game that continues without end, but rather as a stepping stone toward full release.

So, where are we now?

Right now, we’re focusing on getting the MUD finished, which means wrapping up all building and backend stuff. There are no rooms left to describe, the game world is linked in and most objects have, at this point, been completed. Skills have been finished. Culture has been finished. Ethnicities are being finished as we speak. Chargen has been tweaked to be LabMUD appropriate (rather than FutureMUD appropriate) but may require additional fixes before it’s ready. Still, that’s not a big issue. Time, celestial objects, and language are complete.

Helpfiles are NOT ready yet, but I’m of the opinion personally that if we launch with the bare minimum necessary, we can always add more as the game progresses. Ideally, I’d like to see a way to log what helpfiles are most commonly searched for by players, so staff can focus on what’s actually being searched for rather than wasting their time on every little esoteric command in the game.

We’re also still working on getting the website finished. This includes the forums. While they are fully functional at the moment, they are ugly. 

When can we see LabMUD open to players?

Plainly? Whenever it opens. While the game is almost completely built, it does still lack certain coded systems. FutureMUD does not yet have (for example) a combat system, or a crafting system, or weather. LabMUD will probably open before crafting, or even weather, is complete, but we would like to see combat in its very basic form (at least) before throwing the door open.

So, yeah. Watch this space. Periodically, we’ll be posting updates and (should our fancy be tickled) narrative fluff. You can also follow us on Twitter if you’d like. We have one of those now.