Glider
"In het verleden behaalde resultaten bieden geen garanties voor de toekomst"
About this blog

These are the ramblings of Matthijs Kooijman, concerning the software he hacks on, hobbies he has and occasionally his personal life.

Most content on this site is licensed under the WTFPL, version 2 (details).

Questions? Praise? Blame? Feel free to contact me.

My old blog (pre-2006) is also still available.

Sun Mon Tue Wed Thu Fri Sat
28
         
Powered by Blosxom &Perl onion
(With plugins: config, extensionless, hide, tagging, Markdown, macros, breadcrumbs, calendar, directorybrowse, entries_index, feedback, flavourdir, include, interpolate_fancy, listplugins, menu, pagetype, preview, seemore, storynum, storytitle, writeback_recent, moreentries)
Valid XHTML 1.0 Strict & CSS
Uses and requirements

Okay, so I'm gonna build a system to do administration tasks in our LARP club. But, what exactly are these? What should this system actually do for us? I've given this question a lot of thought and these are my notes and thoughts, hopefully structured in a useful and readable way. I've had some help of Brenda so far in writing some of these down, but I'll appreciate any comments you can think of (including "hey wouldn't it be cool if the system could do x?", or "Don't you think y is really a bad idea?"). Also, I am still open for suggestions regarding a name.

General outline

The general idea of the system is to simplify various administration tasks in a LARP club. These tasks include (but are not limited to) managing event information, player information, event subscriptions, character information, rule information (skill lists, spells, etc), etc.

This information should be managable by different cooperating organisers and to some extent by the players themselves. We loosely divide the information into OC information (info centered around players) and IC information (info centered around characters). OC information is plainly editable by players or organisers, where appropriate. IC information is generally editable by organisers and players can propose changes (but only for their own characters). These changes have to be approved by an organiser before being applied.

The information should be exported in various (configurable and/or adaptable) formats, such as a list of subscribed players with payment info, a PDF containing character sheets to be printed or a list of spells for on the main website. Since the exact requirements of each club and/or event with regard to this output vary, there should be some kind of way to easily change this output.


Users

There will be four groups of users.

  • Admins. Admins can modify pretty much everything and perform user management.
  • Organisers. Organisers are the lassical "power users", they can freely modify most information. The players on the other hand have limited options.
  • Members. Members are people who have logged into the systen and/or subscribed for an event.
  • Visitors. Visitors are everybody else. Everyone who is not logged in is a visitor and may or may not have access to information in the system (generally only read-only).

Possibly, the first two groups can be unified into one admin group, if the userbase is small.

OC part

The OC part of the system will mainly keep data about persons, events and registrations.

Data

For every person, we keep:

  • Name, address, etc.
  • Medical information, allergies, etc.
  • Vegetarian
  • First aid
  • Glasses/contacts

For every event we keep:

  • Name (ie "Exodus", "Symbols", etc)
  • Title (ie, "Symbols 3: Calm")
  • Date

It would be nice to also keep different registration options (NPC/PC, with food/without food) with different prices and corresponding deadlines, etc. Since this probably requires a lot of overhead and probably organisation-specific code, so this might be simplified to some hardcodedness in the subscription form and some hand work.

Lastly, we keep information about registrations. A registration is essentially a many-to-many relation between persons and events, with some extra information.

For every registration we keep:

  • Date of registration
  • Type (NPC/PC/etc)
  • Other options (food/no food, etc)
  • Character(s?) to be played during the event

Lastly, the system should have some knowledge about payments. The most ideal way to this would be to keep a list of payments, together with amount, date and registration the payment is for. This allows for multiple payments for one registration and allows you to keep a direct mapping between the system and account statements.

The simple way would be just storing the payment date for every registration. This means that partial payments cannot be saved by the system, but is significantly easier to implement. Also, this solution can also be extended to the more complicated solution above.

IC part

Okay, now for the interesting part. Since the system will be used for multiple events, it should be general and customizable. I will start out here with the general part and save the exact requirements for different events for later.

The main piece of data is a character. It should have a name, date of birth, physical description, that sort of things (probably different for different events). This information is all simple and textual. Furthermore, a character should have a larger description and/or background. This is still mainly textual, but should be somewhat formatable (ie, wiki-ish).

Also, a character has an owner. This is the player or NPC that plays the character. Characters could have no owner, in which case the character is not bound to a particular NPC since it has not been played yet, has been played multiple times, etc. The owner is able to see most information about a character and propose changes to it.

Furthermore, the system will know which player has played which character at which event. This is partly stored in the info about registration (what character a player wants to play), but should probably also be stored seperately (what character(s) were actually played). This also enables linking multiple characters to one NPC. Also, there should be room for feedback and/or remarks from the player that played the character.

Lastly, the system knows about the rule data that represent the character: different stats, abilities, skills or whatever is defined for this particular event.

Especially this last part is interesting, because it is not simply modifiable by the character owner. Some kind of moderating system should be in place here, where people can do stuff like "buying" skills. These actions should probably be grouped together and presented to the storytellers as a single "character change proposal", which needs to be approved. It is probably useful to not just use this moderation for skill changes, but for all data, since this requires a storyteller to have looked at all character changes (which is wanted).

Other considerations

  • Most objects in the system should be able to store general "remarks", possibly comments (together with time and author), or simpler just a free form text field.
  • Most objects should be taggable. That is, it should be possible to assign free-form textual tags to different objects, such as "Primogen" to characters or "Crew" to persons. These tags are generally not used by the system itself, but are should be assigned meaning by the users themselves (though some special tags might be used by the system).
  • All objects should have most of their properties defined at runtime. In other words, the actual data stored about a person, should be defined in the database and be modifiable at runtime without modifying code or database structure. This enables different organisations to define different fields with low overhead.
  • There should be multiple different events in the same system (ie, Lextalionis and Exodus). They should (probably) share the same OC logic and fields, but not the IC part.
  • All this data should be readily available on-site (on the event, that is). This means that just before an event, the data should be frozen (ie, made read-only) and the master copy transfered to a different machine that can be taken to site. Also, there should be some way of making this data readable without having a webserver running (ie for offline viewing on a laptop).
  • Parts of the data should be versioned. This means that it should be possible to, for example, show the state of a character as it was during the first Symbols event. All character (or all IC) data should be versioned. All OC data is generally unmutable, such as registrations and events. Only personal data will change often, but is probably not too useful to save historic personal data.

    It should be possible to timestamp all versioned objects at a specific moment, using a custom name (such as "pre-Exodus-1" or something). Since changes to characters should be approved by organisers before being applied, individual changes should be stored by the system anyway. It is therefore not too hard to assign timestamps to these.

Use cases

This is a random list of stuff that should be possible with the system.

  • Send mails to (groups of) users (perhaps automatically for paymentsdeadlines)
  • Generate a list of all (food) allergies
  • Generate a list of all registrations and payment status.
  • A list of characters in a world (like the Dramatis Personae of lextalionis, probably only include characters with a specific tag).
  • Generate character sheets
  • Keep info about which characters have already been generated and which characters have been changed since.

For members

  • List the available events, together with status info (registered, payed)
  • List your current registrations (possibly allow changes?)
  • Change personal data (also show the current data at every registration)
  • Send confirmation email on every registration (including payment info)
  • Allow to create a character after registration

Authentication

To identify users, we need some kind of authentication. To prevent users from needing yet another login, we will reuse the authentication from our forums. There is no need for the organisers to explicitely link persons to forum logins or something like that, since the first time someone logs in to the system, he can fill out his personal data and register for events.

There should be some general way to perform authorization on various data. In other words, one should be able to specify what users have access rights over what data (possibly on an object level, or perhaps for individual properties or entire reports).

 
0 comments -:- permalink -:- 15:26
Copyright by Matthijs Kooijman