I help run logistics at SimTerra LARP, which mostly just means keeping track of character sheets and bank transactions. I do other things, and staff at other LARPs in this role do other other things, but character sheets and bank transactions are the hardest piece and the most important.
A big part of SimTerra is reactions to other LARPs (and as we became an older LARP, reactions to ourselves). Complex rule systems were confusing and too often got in the way of having fun, so SimTerra did away with them. When I was still PCing, our rulebook was two-sided character sheet and check-in was “here’s how many skillpoints you have and your perm chance, we trust you to rebuild your character sheet and not rewrite into different skill trees every other event.”
Eventually, we moved away from this towards a more traditional spreadsheet for a thousand reasons. Part of it was Bob actually built OpenOffice spreadsheets (cleverly titled CharacterSheet.ods and Bank.ods) that could track (the 4th attempt in the first 6 years?), part of it was the addition of Talents and long-term Projects, part of it was the convenience for older characters who had over 20 skillpoints and didn’t want to spend 30 minutes rebuilding their character every event, among other reasons.
The spreadsheets were pretty awesome while they were around. With some copying-and-pasting, you got basic version control. They were written in OpenOffice and stored in Dropbox so any staff could pull and edit for free (this seems trivial today, but 2010-ish was a scary time to live in and collaboration tools, much less free ones, were awful). CharacterSheet.ods was split across sheets, so if you only cared about the experience record that was on one sheet, and each skill bought by a character lived on another sheet (same for perks, talents, etc) BUT there was a master view where you could lookup a character (by Player Last Name, Player First Name, then Character Name) and it would collect all of that data onto one sheet for editing and another sheet for prettier printing. Hooray!
Now the dark side:
Isolation on multiple sheets and cross-sheet lookups are useful, but there is zero enforcement. If I forget the pattern needed to add a skill, death, or event attendance CharacterSheet.ods probably won’t throw an error and I won’t notice for at least another event. Con1: Business Logic Validation
Another downside is check-in started to take longer. Instead of 2 short look-ups to figure out your current skillpoint total and perm chance, now we needed to ask “what changes do you want to make” and record them. We’re also reading and writing from CharacterSheet.ods, so it can’t be scaled horizontally by adding more staff (which in theory we could do before, but never needed to because character sheets weren’t a bottleneck). Con2: Scalability
A related issue to Con2 is players tracking and updating their characters between events. Now, players would need to email/IM if they wanted to check if they’ve been credited for an event, had unused skillpoints to spend, or money in the bank. Both staff and players found this annoying, so almost no one did it.
This is where I started staffing and after fooling around with mods and NPCing (which I did have a lot of fun with), I found my true calling pushing pixels and running all the “boring” stuff. Which was great, because apparently every other staff member HATED this (or at least liked it the least out of all the things they could be doing at an event). Good news is now other staff could do more of what they enjoyed – putting on mods and NPCing. Bad news is I (and check-in) became a huge bottleneck. Where check-in at the house used to take AT MOST an hour (if we had 45+ players show up), check-in at the camps with me regularly lasted all night, with the average player taking 2-5 minutes to check-in after waiting up to 30-45 minutes. Con3: Speed
Spreadsheets aren’t great at isolating what and only what you need to see at a given time either. As more and more data got stuffed into CharacterSheet.ods (I think it hit 3MB at one point), this became more and more taxing. Tracking a specific event for a specific character to be sure they got the proper XP? Not very hard, but time-consuming if they’ve attended 30 events and I have to scroll to column BZ. Con4: Presentation. Tracking talent growth across multiple versions (different files) of the spreadsheet to be sure they were credited with the right amount of time units? Time-consuming, tedious, and hard to verify. Con5: Strong Versioning
In the last couple of years, SimTerra’s gotten some “meta” skills too. Protos can earn skillpoints at 2x or 3x the normal rate. Retiring players can earn up to 20xp on top of their normal event experience. Bob (the spreadsheet’s author) was kind enough to keep up and adjust formulas as needed, but as time went on he had less and less time to offer. This is similar to Con1 but the problem here is testing interaction between a new feature and old. Con6: Feature Testing/Assurance
So, what to do?
These aren’t terribly hard to work around, but SimTerra Staff don’t get paid enough to deal with the above. (SimTerra does pay its staff though, and while it’s a very small amount, I believe we’re one of the only LARPs to do so and it’s just such a nice gesture). Every person involved in a LARP is there for the labor of love.
Around this time I also graduated from college and wanted to shore up my resume with side-projects, so I started a Rails webapp that I called SimRep. Since then, SimRep has been my mudfield project – I’ll experiment on it with new tech that looks interesting or useful (https://en.wikipedia.org/wiki/Greenfield_project), but it’s 2 years old now and I get angry emails if I break it for more than a week (so, a little https://en.wikipedia.org/wiki/Brownfield_(software_development)).
The parks don’t have great internet coverage, so whenever I’m able to make events I’ll bring my desktop, set up a little office, and run a local copy.
But I’m not there every event – so I had to come up with a way to get data into and out of SimRep without killing 2 trees’ worth of paper every event.
And that’ll be the next post!