Secure Facility 7: What did we learn?

So with technical posts discussing what was done and how it was done now out of the way for future referencing by myself and other people playing with tech, what I wanted to write to cap things off was to ask the question: What did we learn?Basically this is the first event I’ve done which featured such a core website being a source of information prop.  I mean sure we did remote controlled screens for Haunted Hotel, we did streaming video and mass twitter accounts for British Haunts (although the really cool green screen was done by someone else for that one), and I built a simple terminal interface NFQ, but I think this is the first game I’ve done in which the web stuff was designed to give such in-game interaction for multiple people, and so I learnt a few things about it, which I’ll try and capture here.

Number 1: Treat it more like a traditional book prop

The first thing I think I learnt was that it needs to be more like a traditional Book O’ Evil prop than a website.  The rule of thumb I like to work too is that if information is critical to a game then it gets flagged up early in the game creation process, and its noted where that information is, what it definitely needs to say (and what it needs to not say) and who is responsible for creating it.  Ideally I like to put the same information in different forms in two places, so if the players miss the first piece of information they may get the second, or if someone sits on one piece of information then others get a chance to get the second piece.

Now this was almost done successfully here but not quite, we I think managed to write up some of the stuff as “In the intranet site” but needed to be clearer about where it was, who was putting it in to avoid last minute editing jobs.

Number 2: Documentation is Good: spread out editing duties

This one is one I think we won at, I knocked up the main CMS site pretty early on, and made sure to document it enough that 99% of the data input was from the Refs, by and large this makes sense, a website needs to be large enough to feel real, and having only one person be on duty to enter that information leads to bottle necks.

Number 3: Know Your Org Charts and Know Your Users

This is something we learnt as we were going along, because of the way that the CMS was built it relied on lots of groups to manage who could see what, and we didn’t want every single user being able to see every single thing because that removes the challenge of breaking into different accounts to score different things.  However hammering out the fictional org chart and at least the heads of departments and other key accounts early on means you can get this structure in place and not have to do a bunch of tedious and error prone work fitting articles back into your security structure.

Number 4: Single Points of Failure: Have a high bus number

Technical props in teams with only 1 technical person can easily lead to this problem, if possible try and have a second admin who can step up on the day if you’re sick/hit by a bus.  Also do your best to follow best practice, I know this is something you’re doing for a hobby but try and do your duty (swear The Abigail Oath) keep your server patched, keep regular scripted backups of the site and database, keep stuff in a version control system, know how to restore from them, have a plan for how to run it local to the site if the net goes down (less of a problem in metropolitan areas but if you’re running in the wilds then its way more likely).

The non-technical Refs don’t need to hear the details of all of these sysadmin duties, what they need to hear is “I’ve built it, I can fix it if it goes wrong, I can deal with problems on the day” – and you need to be able to deliver on those statements.  Try and get the system reliable enough and the documentation good enough that Refs can make minor edits and corrections on the day easily.

Number 5: Treat it less like a traditional book prop

Take advantage of the things you can do by use of this technology, always try a new thing with it.  Remember it can be in multiple places at once, and most importantly if you don’t stop them players making changes to it they will, and that’s good because players engage and connect more with an environment they can change and get feedback from than one that feels like they’re on rails.

Mix it up with various things – add forums for pre-game chatter, video, sound effects on timers, add notes, messages, email accounts, things they can change, things they wish they could – all that sort of stuff that lets the prop mesh more with its environment thus making it feel more real and the game more engaging and immersive.

What we found in this event was that players worked out they could log in from multiple places at once, and they did, they took advantage of this by sending messages to other users on the system and pretending to be the alien creature attempting communication in order to sway the player population to have sympathy with their faction (no everyone, the creature wasn’t trying to communicate with you via the internet).

We also had players work out that the site contained vital info that would let other factions do things they didn’t want (open the doors) and so naturally took advantage of the accounts they’d broken into to change details to stop this happening (account passwords, door access codes) and spread this information around their faction which was unexpected and kind of cool.

Conclusions?

Well I had a lot of fun making this prop, and I think it went quite well for our first really big interactive web prop (as opposed to building websites for information like British Haunts and to a certain extend RainbowCon), we had people engage with it, it generated roleplaying opportunities, spread out access to information amongst the player base, and taught us useful lessons about how players like to interact with such things.

So yeah my take away is if you’re running a game with technology try and embed it into the game in the same way that tech is embedded into day to day life, try and make it seemless and follow the rules of tech that your players are used too.  The more its in the background as a normal part of the environment the more players will interact with it the same way they interact with tech day to day, and the more opportunities it will give for spreading in character information, helping characters communicate with each other, and giving opportunities for creating reactions and roleplaying.

Leave a Reply