2003
Abstract
The Marble is a system to assist with the running campaign Live Action Role Plays (LARP). As with most of applications being developed these days, Marble is going to be web based and track information about Events, Knowledge, People, Places and Things.
$Revision: 1.2 $
Table of Contents
Table of Contents
Many people run Live Action Role Plays (LARP) which take a long time to organise and take even more time to work out the behind the scenes detail. With a large long running LARP, keeping track of everything can be quite a task. And that's just for the players.... GMs who deal with this can have even more problems, such as changing assistants and players.
Marble is intended to assist both the Players' and GMs with keeping track of everything. This document outlines the user level requirements for this system.
The latest copy of this document is available at http://marble.sourceforge.net/downloads/documentation/requirements/. Alternateive formats are available: As a single page or a PDF.
Table of Contents
What should a LARP system do? Well a LARP system, such as Marble, should help both the Players and GMs. To assist in running a LARP it is essential that the system tracks key information. This key data includes character (people) details, information that each character has, locations and things (swords, magic items etc). If the system can keep track of all of this then the system is doing well.
This chapter provides the requirements on which components of information need to be stored, as well as the type of access and authentication requirements of the Marble. A few other requirements are also covered, such as the system's minimum response times.
To enable the system to assist with the running of LARPs the the level of detail to which the system must record information about the game is quite high. This must be complemented by hiding information for specific games. This section details the information which Maric's Place requires to be stored and then attempts to demonstrate how this might be modified to cope with other systems.
This will hopefully produce a system which is flexible and extensible enough to cope with all circumstances.
The first piece of information which is critical to running a LARP is the character. Just about every where things revolve around the character. Taking this into account the associations between characters and other pieces of information are very important. These relationships include:
The relationship between two characters. It is important that this type of relationship can be recorded for each character individually. This is to allow both character to have different interpretations.
An example of why it is important to ensure both directions are recorded for this type of relationship can be demonstrated by:
Fredric believes that Madeleine is a friend, but Madeleine is neutral to Fredric because of an incident involving the Imperial Princess Sara.
It is also possible that a character will use names other than their own, such as when they are on a secret mission. This could be captured as part of a character record, but a character may use many of these over the course of several adventures and in some circumstances there is enough additional information that the character's alias is almost a new character. A similar situation exists when a character has amnesia.
Where a new character sheet would be required to represent the character for the alias it is important that this information is also recorded. An example of this is shown below with Superman and Clark Kent:
Superman has an alias Clark Kent. Many people know of both of these different people, but because they are seen as so different they need to have different character sheets.
The relationship between the two identities may be known or suspected by different characters. For this reason it is also necessary to track the relationship between a character and the associated aliases in such a way that other characters can identify their knowledge of the relationship.
Characters also have possessions which can be stored/left somewhere. It is also possible for a possession to change hands.
Some possessions are well know and will be named. Other possessions only have a description. Possessions should also have a date they were created and destroyed, as this could be important if an original is destroyed.
Clubs, organisations etc. are groups which a character may have a relationship to. More details about these groups can be found in the section called “Organisations”.
The last thing a character is associated with is knowledge. Knowledge includes the information the character has about events and researched information. This basically is the character's memory of everything they have heard, read, done or said.
This memory is partially created by the player entering reports (the section called “Player Reports and Character Sheets”) and GMs entering new knowledge into the system.
The attributes of a character are also important. These include, but may not be limited to:
Name. A character's name is complex, as there is usually one or more given names as well as a surname. In some cases a character will have other names they are known, such as aliases, maiden names, tags and cover names.
Birth and death dates.
The birth and death dates may also have a third date associated with them, the character's evolution date. This date is represents the date which a major change occurred, such as being embraced and changing into a vampire or an awakening for a mage or psychic. It is also possible that a character may go through more than one of these changes.
Because these changes are so profound there will generally be a large number of changes to the the various attributes of the character. A record of the original attributes must be kept to allow the correct traversal of time lines in the game.
Character statistics. These statistics are the numeric representation of a character's physical and mental attributes.
The character statistics are not required to be implemented for Maric's Place, until the rest of the system is complete. This is due to Maric's Place generally being run as a system less LARP.
Race. The race for the character. This is one of the things which may change with the evolution of a character.
Sex. The sex of the character. It is also important to remember that sex is not always just male and female.
On some occasions the character's sex may also change.
Personality. The personality the character has be built with at the start of the game. If there are significant changes to the personality there should also additional entries appended to this information.
There should also be at least two personalities, the one which is the way the character is perceive and the private one which is the character's internal struggle with themselves.
History. This another one where there should be at least two versions of the history, for similar reasons to those used for personality.
Beyond the character you have larger entities in the game world, such as organisations. For the purposes of capturing information about the game world, an organisation can represent many different social structures. These structures include:
Business Organisations
Secret Societies
Houses
Clans
Families
Political Organisations
and many others...
This list covers a lot of the social organisations in Maric's Place. But Maric's Place is not the only LARP which must be supported by Marble, so Marble must support social organisation in a way which allows this list to be extended or reduced to fit the LARP.
Organisations have similar attributes to the section called “Characters” . Each of the things a character can be associated with must be considered in relationship to an organisation. There is some additional information which is required to complete the picture about an organisation and that is the ruling body. It is possible that the ruling body is also made up of a council, which is just like an organisation within an organisation.
Organisations can also have relationships with other organisations. These relationships may mean that the an organisation is completely contained within another organisation.
Some organisations are organised into hierarchies, where there is a ruling body or person. When this is the case there are usually titles associated with positions or roles within the organisation.
Organisations are not the sole owners' of titles. Some times people take on a titles which have no relationship to an organisation. In this case it is possible that the title is an alias, such as The Phantom is Kit's alias which is handed down from one generation to the next.
The Marble is not interested in recording these types of titles, as they are more aliases and should be recorded as such. The other types of titles must be recorded in such a way that it is possible to identify who held a title when as well as who claimed to hold the title and when.
In this context holdings refers to any land or property which is owned. Holdings may be owned by a character directly or by an organisation. In either case the holding has a location and description. It is also possible that one holding may contain other holdings, such as when the king owns the country but his dukes will "own" roughly equal portions of the country each.
In some games the amount of financial influence you can to bear is important. The following list contains the key factors which must be considered when wealth is implemented.
The amount of money on the character.
The amount of money the character has in a bank or buried under a bush some where.
The income from businesses, interest from investments, wages and any lands which the character may hold.
Miscellaneous income, such as bonuses or once off payments.
Character knowledge is a tricky thing. What makes it worse is that it really comes in two parts.
The first part is that the player has to let the GM know what their character did in each session by submitting a report.
A report should include prompts for particular details which a GM is interested in, but allow the player to enter information in what ever manor they which (free text). These prompts should be customisable on a game by game basis.
Reports should be associated with the character they have been written for, as well as any events they the player things appropriate and appropriate session(s). Where people other than the GMs are able to make associations between the report and events an the GM should be given the option of approving these associations.
Making the association between the report and the events should only be performed by people deemed appropriate. This means that for some games it should be possible only for the GM to make these associations, in other cases players can do it themselves and yet others the player can make the association and the GM can approve it.
When an association is made between an event an a report it should also have an indication of how much character believes the information they have about the event.
A report may be written over time. That is to say a player may write part of a report and leave if for a few days and then complete the report. At some point the report becomes submitted.
The difference in the state of the report must be tracked. An additional states the GM has for a report must also be included.
The second part of the knowledge of a character is what the GM tells the player. Knowledge represents any information about important events, things the character said, did or found out. Some important features of the knowledge are:
Different versions of events can exist for different characters. It is also important that the GM can access the real version of the knowledge entry. This is to ensure that a correct record exists, even if no character knows it.
Associated with the requirement for the GM to be able to find the real event, a character will also have different levels of believe that an event occurred.
When an event occurred. It is possible that an event occurred over many days or hours.
A name, for presenting in list, a summary, for presenting in short form (probably on printed material, like character sheets), and a full description are required.
It is also important for at GM to be able to start writing the character sheet for a character and leave it unfinished. Thus there should also be a state associated with character sheets.
This section will be removed from this document and expanded in another document which describes the performance requirements rather than the functional requirements.
A responsive system means that the system feels like it is performing the operations when the user follows a link or submits a form, not a minute or two after. To achieve this it most users are willing to wait for several seconds for operations which are perceived as complex.
The system should only provide access to authenticated users. This should be achieved through:
Ensuring that data which requires authenticated access is only accessible by the appropriate users. The granularity of this access will depend on the LARP, but can be no smaller than the data contained in the cell of the database. In general it is expected that the smallest unit will be a row.
Providing the break-up of users into various groups and roles.
The interface should provide a simple mechanism which allows the user to retrieve the information they are after. The measure for this should be exactly how much the documentation a typical user needs to read before they are able to find the information they want. GMs are not considered typical users because they may have to perform complex operations, but the target should be the same.
It is very important that before a report is provided that the user has been authorised to see all of the information which is available in the report. In this regard what this means is that each report must be tailored to each user, and some reports will not even be given to a user.
The following is a list of reports which are known to be required. The details for these will be worked out as part of the screen designs [1]
[1] This is simply to reduce the number of documents which need to be written or updated when something changes.