This first post is the authoritative one. I'm working the other two posts into this one. [b]The Lore Repository, a Dynamic Timeline and more.[/b] [b]Introduction[/b] There are many pieces of software that allow of the fast and quality production of timelines. However, these software products are designed around the idea that a timeline is about history, and since history is relatively static, the timelines are static as well. The problem is that during the creation process of a fictional work (video game stories, comic books, etc.) the timeline of events is constantly changing. For example, one character may be 2 years older than another character. Each character has a Birthday on the timline, but the particular dates are not necessarily set. If one birthday changes to a new time on the timeline, then the other birthday event should move as well. The Lore Repository is designed to function around this alternative, dynamic approach. While drawing orderly or decorated timelines is not a priority, keeping track of relative dates is. [b]Basic Function Of the Software[/b] [u]ERIC: please use regular quotes like "". “”s don't always translate well. I'm assuming this forum post will not be the final format of these specs, but also in general, ""s are good practice. JASON: Did you find them all? Or should I go through looking for them? ERIC: I did not find them all, only some in the upper half.[/u] There are three measures of time in the Lore Repository. The first is a "tick". Ticks are arbitrarily long units by which all objects are measured. The second is "User Time." User Times are custom defined units of time, they are measured a number of ticks or a number of User Times. This allows a user to define in-character units of time. Examples could be "Stardates", "Ages of the King" or "Years since the bomb". Finally there are "Real Dates." These are dates and hours which correspond to the real passage of time (More on the usage of Read Dates in the Event Fields section). These can be used to sort events by creation date, publishing date, and so on. When a field requires a quantity of time users should be allowed to enter time in either ticks, User Time, or (where applicable) Real Dates. (Note: There are some exceptions to this, such as a document's "Creation Date", it only makes sense to be a Real Date, act accordingly, ask questions if need be) The Lore Repository is based around the concept of an "event". There are several types of events, but they all have the same basic functionality. An event exists at a specific time or a range of times on the timeline. (i.e, Event A happened at tick 23 and Event B happened sometime between tick 24 and tick 30, we haven't decided yet) If no specific time is defined by the user it should be placed on the timeline (near where the user was navigating when the event was created) It has no restriction on being moved to any other time, and it's time fields are blank until alter filled in. (AKA. "Event A happened. We haven't decided when yet.) An event can either be instantaneous (it occupies only one tick) or it can have a duration (it begins on tick 100 and runs until tick 125) Events have links to other events. Most like are bi-directional. They should be represted by a line with an arrow on each end pointing to each event. Some lines are one directional, they are specifically noted. The most basic links are "Before" and "After" links. If event A has a “Before” link to B and A moves to a time which is later then B, then both events move in tandum, B will move to the tick after A finishes. thus perserving their relative position on the timeline. After Links work in a similar manner. The next link types are “Ticks After” and “Ticks Before”, these work in the same manner as Before and After links, except they have a specific distance which must be preserved. Event A might come 500 ticks before event B. When event B moves to a new time, Event A will move 500 ticks before event B's new tick. These link types can also specify a range. Thus event A can be 500-600 ticks before Event B. When event B moves to a new time the software adjusts event A to keep this range in tact. The sofware should move event A the minimum distance to preserve the link. If it's possible to not move event A and still preserve the link, then that's what happens. When a chain of links exist the software should do it's best to adjust as far along the chain as nessesary in order to preserve the link relationships. For example, A is 5 ticks before B. B is 10-20 ticks before C. A is currently at Tick 0, B is at Tick 5 and C is at Tick 25. If A is moved to Tick -10, then B must be moved to Tick -5. Now C must be moved earlier to satisfy the 10-20 tick link, C will end up at Tick 15. If links prevent an event from moving the software informs the user of which links are preventing the event from moving and doesn't move the event. For instance, if event B is set to Tick 100 and event A is 5 ticks before event B, and the user attempts to move event A the software will tell the user that a link from event A to event B and a defined date in event B will not allow A to be moved. Other links: Events can have “extracted” links. They do not represent a relative difference in time. Instead they indicate that a specific event was mentioned in another event. They don't need any functionality beyond keeping track of the event which they were extracted from. Events have a Contradicted link to another event if they reference documents which contradict each other. [b]Information Displays[/b] Storing this information isn't very useful if it's not easily displayable. Feel free to use a 3rd party package to do this, we don't need to rewrite something that already exists. Here are some features we need: There are two primary ways to display information in the Lore Repository. The first is similar to a traditional timeline with events represented as bars along a line. Titles and the date which the events are currently sorted by should be displayed. The timeline should probably scroll and zoom. Usability is the goal with these features. It would be nice if the selected event showed any links it had (unselected event's links should be invisble or semi-transparent/grayed out) The second way to display information displays event details it should show all user-visible fields and properties of the event. The event details display should be accessible from the timeline. Information in the Repository should be sortable by any event field that makes sense( like creation date, tick number, release date, etc). Once they are sorted they should be displayed on a timeline by sort order. Information should be filterable by any field that makes sense (such as category, event type, etc). Events which do not meet the filter are not displayed on the timeline. Event containers should be displayed differently than other events, instead of bars on the line, they should be brackets above the line. [b]Event fields[/b] -An Event has a reference to a Document (see Documents). (This field can be left blank) -An event has a reference to Content (see Content). (This field can be left blank) Fields: I use this format to describe fields: Name [Type of Field] Description Of Special Functionality Title [Text] Should be the name of the event display window and other relevant places where an events name should be shown. Categories [Menu/Text] All previously used catagories are options in a menu, as well as a "New Catagory" option, which prompts for a new Category name Subject [Menu/Text] Functions the same as Categories. Shipped date [Real Date] Should be automatically checked during the Ship process, should ask for confirmation if the user wants to change it. Retired [Real Date] Created On [Real Date] Should be automatically filled in on event creation and unchangeable by the user. Last Edit [Real Date] Functions the same as Created On, but gets updated whenever the Event is changed. Date Links [List of references to other events] These should reflect all the links between events. Each entry should be like this: Link Type, Title of Event Linked To, Time Difference/Range (AKA 20 to 30 ticks before, or 5 ticks after etc) Document Preview[Various] A preview of the document attached to the event, if a preview is readily available. Double clicking the preview opens the document. View Document [Button] Opens the document or content. Low Priority Fields: Created By and Last Edited By. Usernames of who did these things. (For now, using the login name/computer name would be just fine) [b]Documents[/b] Events can have a reference to a document which records what happened during the event. A document is something like text or a picture (a comic etc), or a movie. While multiple events might be described in a single document (example: several battle events are described in the same war novel), each document has only one instance in the database. Multiple events just reference the same instance. There should be a "Document View" which lists all the documents (and optionally, all the Content as well) in the database and allows the user to open them or edit the documents properties. -Documents should be displayed from within the Lore Repository (in the case of text or pictures) or displayed in a standard external viewer, such as mplayer or Windows Media Player for a sound or movie file. (You can let the OS decide how/which external player. Don't put too much effort into supporting alot of formats, just use an external player if adding support is too time consuming, we can always go back and add support later) -These formats should be supported: *pictures (bmp, jpeg, gif, png) [Internal Display prefered] *text (should be some kinda of database wide standard, like xhtml) [Internal Display] *movies (examples: mpegs, avi, wmv) [External Player] *Formatted text (Word Files, .odt's, pdfs etc) [External Viewer] *hyperlinks [External Viewer] Document Properties: Title [Text] Would be nice if this was extracted from the filename -A document can be marked as Contradicted. If the user marks a document as Contradicted they must specify another document which contains the contradiction. Both documents are marked as Contradicted and contain references to each other. There should also be a text field to describe the problem (blank is a valid input) Out of Character [Check Box] No special functionality. Defaults to off. Categories [Menu/Text] All previously used catagories are options in a menu, as well as a "New Catagory" option, which prompts for a new Category name. Same catagory list as events. Subject [Menu/Text] Functions the same as Categories. Shipped date [Real Date] Should be automatically checked during the Ship process, should ask for confirmation if the user wants to change it. Retired [Real Date] Imported On [Real Date] Should be automatically filled in when the document is imported and unchangeable by the user. Updated On [Real Date] Automatically filled in when the document is edited. Unchangable by user. *When shipping, if there is a document which has not been shipped (but is about to be) and it contradicts an already shipped document, there should be a confirmation box for each "Contradiction" which is being shipped. Content -Instead of referencing a document like most events, Content Events reference a specific executable on the user's computer. For instance, a game could be launched to show an interactive cut scene, or a network utility might show the current status of a server somewhere. -Content items have an additional field for location in the other application. Just a text box. -For now, don't worry about these other than planning to launch an external application with a command line flag. (Content is low priority, so it doesn't need to get done for the first release, just plan for the future.) -On the event details display there should be a way to "Launch external application now". (A button or something) [b]Event Containers[/b] Event containers are a special kind of event which contain other events. Events can be “inside” of event containers in two different ways. First, if an event container is based on date, then events are in the container if their current date is within the date range of the container. Events can also have a “contained in” link which requires them to stay in the date range defined by the container. [b]Some external requirements[/b] The software must be project-agnostic. New Repositories should be able to be created without any special knowledge (it's ok to require a familiarity with installing and basic setup required software). The software as a whole should be able to be zipped up and installed (i.e, manually copied to the appropriate directories, we don't need a special installer program) on other machines without too much trouble. We reserve the right to distribute the software any way we choose (although we'll mention you as the software's original author). The software must be compatible with the GPL. If you use any 3rd party libraries they must be available to the public (for free preferably, but for pay is fine). Jason says "MY PRETTY HTML OUTPUT", whatever that means. [b]JASON'S JOB:[/b] A) tell me any missing information you think they'll need B ) Fix any grammer/spelling/formatting crap you want, so I can write more specs instead of correcting them C) Clarify anything tht's ambigious D) Notify me of any changes to the requirements (how the software works, not how the doc is written)