Getting information about larps in the hands of players is an ongoing struggle for organizers. And finding out what larps are being run is equally challenging for players. I have a proposal — and a prototype — for a larp clearinghouse named Peacock. It includes standards for larp data and a website to share that information. This talk will show the basic features of the system, along with the design decisions, to be followed by a discussion about the remaining steps to reach a public beta.
Q&A from the original viewing at Solmukohta 2020 Online event
Anonymous 1: I suppose you just need a system like the escape rooms or the delievery-fooderies have (BOX, Escapeall, E-food, Walt, etc), with a small % if you get your players from there.
Problem is, do you want your larp to exist in a platform with another 100/200/500 “competitive” larps?
Anonymous 2: I would like is one very useful feature for producers and designers: A call for last minute participants, when there is people jumping off – with info on if it is paid for or not etc. And participants could have profiles where they list if they are “a last minute player”. This feature would maybe make larps wanna be on the site.
Anonymous 3: Are there many other services that work like this?
Chris Bergstresser: Federated services are fairly common in computing.
Anonymous 3: Uhm, I am not aware of any public service like this one. Everything I’ve used or seen requires logging into the central interface to modify data. This rocks.
Anonymous 4: Ah, automatic currency conversion, that’s convenient (and prevents using free-form text fields for prices, but I see that multiple prices are allowed). One suggestion though: Annotate prices with a description (e.g. “Player”, “NPC”, etc.) to make it a bit clearer?
Chris Bergstresser: Great ideas, but it’s part of the complexity of offering more than one price. The more complicated, the harder to understand. Fairly simple technical problem, somewhat less so UI/UX problem.
Anonymous 5: Looks really useful! One suggestion is to have the Location on the filter show the country instead of the address
Anonymous 6: What’s your code sharing model? Will this be a GitHub thing?
Chris Bergstresser It’s on GitHub. I’m willing to open source it, but we need to think through licensing.
Chris Bergstresser I’m more concerned the API is well-documented, so it can be replicated by others without needing the code.
Anonymous 7: Chris Bergstresser I am not sure how much and in which way I can contribute, but this looks interesting. How should I contact you to get involved?
Chris Bergstresser Chat on Facebook is probably easiest to get started.
Anonymous 8: I also have some ideas and feedback already based on the talk and the documentation online, what would be the best place for that? Here in the comments allows others to react, but it is easy to lose it, of course.
Chris Bergstresser I’ve created this Google Form to sign up to contribute: https://forms.gle/AB1sMG1XWAaMQmPZ8
For feedback, I think here is an okay place to start the discussion. Better to start than wait for the right place, I’ve found.
Chris Bergstresser I created a Google form to sign up if you’re interested in contributing: https://forms.gle/AB1sMG1XWAaMQmPZ8
Sindre Punsvik Thank you! Sounds very interesting, in particular as an UX designer. Not sure if I will have capacity to help more than bouncing ideas
Anonymous 9: I saw the idea is to put YAML in `<script>` tags in webpages. I’m all for YAML, but I’m not sure a `<script>` tag is the right place. Doesn’t HTML have something more semantically applicable for this?
Also, it is nice to just put it into an event website (probably easy enough for novice webmasters too), but at first glance that would mean that each event must be registered in the system separately. It would be interesting to have just a single URL to be polled for an organization that can list all events (though I guess the current design could actually do that).
ALso, isn’t there some kind of existing annotation system (RDF springs into my mind) from the “semantic web” corner that could be used as a base for annotations?
Chris Bergstresser: The initial idea would be to register a root domain, and spider all the pages to gather all the larps for a given organization. That’s a little complicated, though, which is why it’s not in the initial prototype.
As for a better HTML container for this data, I’m not aware of one. <script> tags have the advantage there’s all sorts of special coding around them (since they have to be able to handle Javascript, which contains < and & characters) so they’re safe in all browsers for embedding the information.
I stole the idea from Mustache, which does things like:
<script id="template" type="x-tmpl-mustache">
Hello {{ name }}!
</script>Anonymous 9: Spidering could indeed work, but does make things more complicated maybe. Thinking from our own organisation, we have a single registration system (which is *almost* ready) that knows about all our events and could easily export all needed into on a single URL. I guess both single-URL and spidering approaches could co-exist, of course.
As for the script tags, I’m slightly worried that browsers will try to execute javascript as a fallback if they do not know the type (not sure if that happens in practice, maybe only with ancient browsers) and that all kinds of systems might end up stripping script tags.
OTOH, I guess that stripping script tags can be a feature: If someone can publish script tags on a domain, they will have some authority on this domain (e.g. you will not be able to fake event data using a comment on a website since script tags will usually be stripped). Another approach could be to only look at the <head> tags and not the <body>, but that could complicate publishing data in typicaly CMS’s mayb e.
Anonymous 9: The proposed YAML format does not list a format version number, which is probably good to add to facilitate format changes in the future (and think a bit on how that would work as well).
Chris Bergstresser: There is one coded, but if it’s missing we assume it’s version “1”. I’m hoping most changes can be accomodated in a backwards-compatible fashion, but we’re safe if it can’t be.
Anonymous 9: In my experience, requiring (or at least encouraging) an explicit version number is always a good idea, since it leaves less room for interpretation. But indeed, a default of 1 could work as well.
Anonymous 9: One thing to think about is how to *remove* an event from the list. Removing it from the original webpage could work, but that means that normally events should be listed there indefinitely (which might not happen in practice as people clean up their websites or websites go offline, without any intention of being removed from the archive).
Chris Bergstresser: We need to think through how events age through the system. If events disappear before they happen we assume they were canceled (you took down the web page before it happened, must not be happening) but after that point I think we assume they ran.
But there’s weirdness there. What if people reuse the id? Do we allow people to remove events after the fact? What if people say they attended a canceled larp?
Anonymous 9: I also think that the list of URLs to scrape metadata from might be one of the biggest assets in this system and might need to be separately managed and published (e.g. a github repo with URL lists per country maybe?). Making this list separate makes i…See
Chris Bergstresser: One of the eventual things should be a way for federated systems to share routes to poll with each other, so you can register a route with any given aggregator and they’ll all learn about it. Seems overkill at this point in the design.
Google avoids the problem by just indexing every web page in the universe. Which must be nice.
Anonymous 9: Using Google to find these tags could be nice (maybe require including some unique string in the metadata), but that also opens up a lot of possibilities of dataset poisoning because it removes the step of explicitly adding routes to the dataset and thus also the implicit review process in that.
Chris Bergstresser: Oh, I wasn’t suggesting using Google to find them. Just that, if we were Google, this problem is solved through brute force.
Anonymous 9: I know, but your comment made me realize that Google *could* be used to find them, which is interesting in itself.
Anonymous 10: Is there a status field? For signup open, cloSed, waitlist, in design
Chris Bergstresser: Yes. By default it’s “active” which is why it’s left off many of the examples.
This was part of the Solmukohta 2020 online program. https://solmukohta.eu/
