Skip to content

Lore Repository


NOTE TO EVERYONE ELSE: My philosophy of design has moved away from writing long abstract documents like this. I’d much rather start writing software and iterate toward a goal, rather than plan this much. If I find myself opening Word instead of Visual Studio or Photoshop, I’m probably going about it wrong. However, I’ve left it up in case you’re interested in reading some of the detailed design documents I was writing after I graduated.


The Lore Repository, a Dynamic Timeline and more.

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.

A Note about UI
At this point we haven’t decided whether this should be a web interface, a standard software interface or something else. As such, none of the user interactions have been defined. Generic phrases such as “detail display” and “X screen should be accessible from the current screen” are used. Particulars of implimentation must be decided later, such as double-clicking versus clicking on a link or mousing over an item to recieve a tooltip. Just use best practices for the platform that we end up going with. Feel free to ask questions in each instance. I might do UI mockups later as well.

Basic Function Of the Software

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)

User time units of time should be arbitrarily sub-dividable. Which means you can specify the 20th day in a 36 day month in a 100 day year which is known as the third “Year Since the Bomb “. A day might be a tick, a month is 36 ticks, a year is 100 ticks. (Note: the smallest measurement of user time is not required by this document to be a single tick long)

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.

Information Displays

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. (Doubleclicking on an event on the timeline for instance)

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.

Event fields

-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)


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] 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.

Notes [Text Field] Just a text field to store notes.

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)

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. [Button abd Dialog box?] 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.

-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)

Event Containers

Event containers are a special kind of event which contain other events.

Event containers can define a start date and an end date (in Tick/User Time), if these fields are filled in by the user, than the event container brackets from the start to the end date.

Event containers can have a duration defined (in Ticks/User Time), they are the length of the duration whereever they are moved on the timeline.

If any two of: start date, end date, or duration, are filled out, than the third is implied and should be automatically filled out. (Any changes to one should update the others)

If start or end (and the duration) are not set, an event container begins at the begining of the first event it contains, and ends at the end of the last event it contains.

Events can be specifically added to an event container (Need to figure out some UI for this), if this is done, the event cannot move outside of the event container’s start or end date (if start/end/duration are not defined, the event container just stretches when the event is moved)

When viewing the event details display for an event container a list of all events it contains should be visible. Those event’s event details display should be accessable from the list.

If a date is not specifically in an event container, but it’s date is between the start and end date of the event container than it should be listed in the event container’s event details display under a list titled “Concurrent Events”.

Event containers have the standard event’s reference to a document, however they also have references to “Loose Documents”. The event details display should list them and allow you to access them directly. There can be as many as the user wants.

Events can be in multiple containers and event containers can be inside event containers.

Story Arc

Story Arc’s are broad catagories of events. They do not show up on the timeline, and do not span a period of time. (For a quick example, lets consider a novel. A book begins telling the story of how Grandpa Smith aquired the family farm. It jumps ahead 50 years to 1945 when Johnny Smith lost the farm. This story arc does not span events in the skipped 50 years, nor does it contain events which happened in WWII. It does contain events around 1895 and 1945, but only specific events in those time periods.) Essentially Story Arcs are just an abstract list of references to events.

A Story Arc has references to events. Terminology: These events are “in” the story arc.

A Story Arc has references to documents of it’s own (any document referenced by an event in the story arc is automatically included in this list)

A Story Arc has references to “Loose Documents”. (This catagory works like the normal reference to documents, it’s just a different catagory)

Story Arcs have a Title field, Created On, Shipped On, and Retired fields. (Same functionality as events).

In addition Story Arcs have a boolean “Closed” flag. Defaults to open, saved when the user modifies it. The Story Arc Also saves the real date when the Arc was closed.

All Story Arc’s should be accessible on a list in the software. Their details (listed above) should be accessible on a detail display. All the events and documents they contain should be listed there (and have their event details display accessible).


When events in the timeline view are filtered, the events which do not match the filters should not show up.

Filters must provide additive functionality (which means, if multiple filters are defined, entries are included if they match one or more filters), however, subtractive functionality would be nice, but low priority.

It would also be nice if a text search was available. Events would match the text search filter if the search for text was found in the title, catagory, subject or notes fields.

High priority filters:



Contained in a specific event container

Concurrent with a specific event container

Contained in a specific Story Arc

Is/IsNot an event container

Has/HasNo Document or Content associated

Created Before/On/After a specified date (Or Retired/shipped date)


Contradicted/Not Contradicted


The software should provide functionality to create a special copy of the database of events. We’ll call this a “client copy.”

When creating a client copy, the software must provide functionality to mark allevents which end up in the copy as shipped (note: the marking takes place in the master copy of the database as well as the client copy)

All events, documents and content have a few additional fields in the client copy. These are:

* Unlocked [Bool] Defaults to true, specific functionality to be provided at a later date.

*Date Unlocked [Real Date] The date which this item became unlocked.

*Unlocked By [Text] Short text (additional functionality at a later date)

*Additional Notes [Text] Arbitrary text saved between sessions.

When a user has a client copy as his primary copy of the database and the user recieves a new client copy, the software must provide functionalit for importing all the values of the additional fields from the old client copy into the new client copy. (the old client copy does not need to be kept, and the new copy coul d be a patch instead of a full database, whatever is easiest and provides the proper functionality.)

If an item is marked as Unlocked=false, it is not visible to the user. (Remember that these fields do not apply to the master database.)

Event Colors
I have a low priority idea about event colors. The idea is half baked, but might make the UI a lot fresher and nicer to use. First, an idea of what they might be used for:

An event’s secondary color would be the color of the border of the event on the timeline view. The primary color would be the color of the background of the event (AKA behind the title/date etc) on the timeline. The timeline background would be white, with a gray or black line along the middle. Although they could show up in other places as well. (Alternatively text could be secondary colors, and text backing could be primary colors)

Now an idea of where the colors come from:

A color would be defined per Story Arc. When an event is in a Story Arc, it inherits the color of the Story Arc as it’s primary color.

A color (seperate from the primary and secondary color) would be defined for each event container. Events in that event container would inherit their secondary color from one of their event containers. Event containers would inherit their secondary color from an event containers they are contained in.

Split/Combine Ticks
If a user clutters events too closely together, they may be forced to place two events on the same tick (for instance, if a user sets up 1 tick to be equal to 1 day, and then two events happen on the same day, one at noon and the other at 3 PM, than those events will seem to happen at the same time. This is undesireable.)

A low priority feature: The ability to split or combine ticks. The user can specify “split all ticks in half”. This will double the distance (in ticks) between all events, double the duration of all events, double the number of ticks per User Time etc. Combineing ticks would have the opposite effect. Essentially this is changing the “resolution” of the timeline. This is a low priority feature, but perhaps consider it while creating your timeline implimentation. (The above density problem might be completely avoidable with a decent design).

Some external requirements

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).

Multiple users must be able to work on a database at the same time. This can either be through making the database diffable/mergable (for use in SVN or CVS etc) or some type of multi-user server that tracks edits in real time (like File Maker Pro or Access).

UI Mockups

I iz artist.

TLMStart.jpg is a shot of the utility just after it’s opened up the Star Wars Story Universe file. You can see events along the timeline in the center.

The Lore Manager Start Screen

TLMElementSelect.jpg is when the user clicks on the Clone Wars event, and it shows all the links that this event has. (I drew the link between Battle of Corsucant and the Clone War backwards. It should be red and facing from the battle towards the war, since the battle has a DURING link to the war).

An element selected

TLMInfoDisplay.jpg is when the user Double-clicks the Clone War event. This dialog box comes up and displays the information stored about that event.

The Lore Manager Info Screen

Additional Optional Reading

Appendix A: This is a very old summary of the software, feel free to read it so you can get a better understanding of the direction, but don’t get caught up in contradictions, and don’t accidentally let one of these features sneak in if the feature isn’t in the design document posted above.



Basically, the whole thing is a Lore Repository
It will be a utility to keep track of game lore, be it written content, pre-recorded sequences in the game, references in movies, letters from non-player-charecters (actors) in the game, or other. It will also keep track of various discoveries and inventions according to player actions. Which means it will have to interface with the game servers (and game client). How it does this is fairly open. The servers could just write specific triggers “Advanced Alchemy invented by Player X” to a file, and then the lore database could read that and start distributing that info to players. Then the client would have to be able to recieve basic commands from the utility (this could be something like running the program and pointing it to a specific cutscene to play. The utility would have two modes. Developer mode, where lore is authored, controlled and distributed from. And Player mode, where the lore is displayed (and unofficially distributed).
The tricky bit comes follows: The game server should have access to the developer’s utility database, and will control the distrobution of individual piece of lore to the game client. The game client would then store the lore pieces in the players databases. Then the player can open the database anytime he wants, and read all the lore he’s discovered.

The communication protocol is completely up to you (with perhaps later optimizations by the game team for performance sake), same with the actual implimentation of the database. None of the communication between the server or client and the utility has been written. But both of those pieces of software will have performance issues to worry about. With that in mind, you have free liscence to do whatever you want with the communication protocol. (Between the utility and the server or between the utility and the client, but not between the server and the client)
However, you may wish to keep in mind that our server and our client would not be the only ones to use the utility.
Somehow this utility should get to other game developers,(via GPL or some other (commercial?) liscence) so they can use it to impliment their own lore databases
So I guess another feature request is that there can be multiple games which use the same utility, but have different universes (non-overlapping lore)

There needs to be atleast a windows utility but Linux also would be nice.


These features are just what I can come up with by thinking. Since what it is has never been done before (to the best of my knowledge, I’m not even sure what to call it), I can only guess what might be useful. So those are kinda the features for version 1

Features:: Full GUI (Office Suite feel[google and check out “Magic suitcase”])

Data Must Be marked as: Unshipped, shipped(date), Retired(date), Contradicted(in case of error, and a reference to what contradicts), “Facts extracted”(to mark that documents have had all relevant facts extracted to individual FACTS, easy to get or challenging to aquire(maybe several graded levels 0-256?)
Each entry must have various user defined catagories, and relevant story arc’s and chapters, expansions, and sequals also. Maybe Non-Game Lore

Data must cross reference with other date. Must be able to display cross referenced data intelligently together.

Must display timelines, with different data groups (mineral discoveries or power plant research etc)–

Must be able to reference specific FACTS from documents, for quick reference. Facts must note referencing documents

Should link to ingame replays of special events, or external movies.

There are some other “features” too. Data exporting, so the developers can take their database and distribute it (ship) to players.

Should include a “release” version which allows players to collect lore, both from company releases of files, and from ingame documents collected. Game client should be able to faciliate transfer of documents between players.

Should include plugin support for various games, so ingame linking is more convinent.

Must include easy “export” so the internal lore database can be made into releaseable patches for player databases. It should include filters for Contradicted, Released, Easy to get/Challenging to aquire shipped, retired, and data types (timelines as opposed to FACTS)

Must catalog all notes by when they were created (IRL time), when they were shipped (IRL time) and relation to game time(in case of pre-current lore, this can be a negative value). [these values must be filtered out when an item is “shipped:]

There should be an arbitrary dating system to keep track of when in the story the lore happens/is written, and also when it is discovered. This value must be able to be masked to one or more “in charecter” dating systems (ie “20 years After the Bomb” or “Stardate 982398.82”)

Should also include rudimentary patch tracking system, so notes can be added about the current state of game balance/culture. (Perhaps included with a “chapter summary”)

Notes should be able to be marked “Out Of Character” to convey non-lore information.

And there should be a way to organize lore items by “Story arc” and “Chapter” and “Event” Each story arc would have chapters, and each chapter would have events

More Optional reading

Appendix B: This is an old requirements document that I wrote long before I knew anything about software design or requirements documents. Much of the information here is outdated redundant or incorrect. However, it still might help understand the thrust of the software. These are not requirements, DON’T BUILD THE SOFTWARE BASED ON ANYTHING IN THIS POST!



Some terms are introduced before being defined, keep them in mind and read on for their definition in the relevant section.

-contains atleast one story world
-can contain as many story worlds as desired
-has a master “tick” timeline measured in metric ticks (1000 ticks is a kilotick, 1000 kiloticks is a megatick etc)
-Each story world is seperated an approximate number of ticks (or world years) When created these two story worlds are an “unlinked” pair of story worlds
-Story worlds may be linked with a specific date. At this point they form a new story set.
-Other note: a tick is a different number of days on earth than on pluto since pluto’s days are like 400 earth days or something)
-Universises can contain “loose documents” which are not associated with a specific story world, but are apart of the lore of the universe (creation story which is not a part of the story world)
-Universe can contain notes which can be read by the local user but are never “shipped” (maybe export notes to a text file option)

Storyfolder AKA Event Containers:
-A Storyfolder is the tenative generic name for a StoryWorld, StorySet, StoryArc, or Chapter.

Story World
-Contains atleast one StoryArc
-Contains as many StoryArcs as desired
-Atleast one User Time set, which contains dates in an In Charecter time. (ie Emperial Years, Days Since the Bomb, etc.) Remember that User Times can be based on other User Times (one quint is 1/80th of an Emperial Year) there can be multiple User Time Types per world. (ie two kingdoms with different dating systems)
-Each set of World Years should have a conversion factor to universal Ticks. As such, World Year conversions are possible vicariously from one User Time set to another.
-I think StoryWorld’s can’t contain “loose documents” but if they can, I don’t care. (see universe)
-Worlds can not contain notes which are not shipped (see universe)
-StoryWorlds basically function as folder for Story Arc’s
-Most content will be shipped as StoryWorlds
-A StoryWorld is the equivelent of a game.

Story Set
-Basically a Story World which envelopes all Events which the two source World’s contain. (It’s like paper clipping the two Story World together)
-Story sets can’t contain data items, but they can contain loose documents and notes
-StorySets should have the ability to contain other StorySets in the future (I’m not sure if I want this feature or not) At this point the GUI won’t include the ability to do this.

Story Arc
-A story arc is one cycle of storyline (ie, The tomb of the great demon Bar’hul is uncovered at the begining of the arc, he gains power, at the climax of the arc, the players defeat Bar’hul and the arc winds down as players clean up the last of his remaining minions.)
-When one Arc is finished, it’s marked as “closed”, and a new Arc is created, immdiately following the previous story (there can be “blank” time at the begining or end of an arc if the next story doesn’t start immdiately. However, the arc should by default end at the date of it’s last event and the blank time in between should just be untitled.)
-Each arc contains atleast one Chapter. It can contain as many as the developer wants.
-Arcs can contain loose documents.
-Can contain notes which are not shipped

-A chapter is like a chapter in a book
-Each chapter can contain events (these are not “loose documents”)
-Each Chapter can contain notes that are not shipped.
-Chapters should have specific start and end dates, and there should not be any overlap or empty space between chapters.
-Start and end dates(real time) are not set until the chapter is started (the first Content is shipped) and ended (the last content is completed). In game dates can either be set by developers, or matched to the time it takes players to complete the chapter.
-Documents can be shipped before a Chapter begins (or after it ends). These documents ship dates are timelined inside the time period of the next chapter, even though they belong to the current chapter.


—->[ ] Denotes a Submenu
———- denotes a break in the menu
| |Denotes a pull down for a menu
Description of menu items

New Universe
New StoryWorld(in this universe)
New StoryArc
New Chapter
Open Universe
Merge Universes*
Close Universe

*I’m thinking the Merge Universes option is really gonna be complicated, so we can leave it out of the first version (unless you wanna figure it out[or I get creative at some point])


Create Internally Edited Document (Text)
Link To External Document (like a movie file etc)
New Content Marker
New Note
Import (Item from other universe)
Change Data Statistics
Change Content Location

I forget what change data statistics means, maybe it means you can overwrite statistics like when an item was shipped, or maybe it means stuff like where things are in the game… I forget. More on this later

|World Management|
Ship updated Items
Update Shipped Package
Ship –> [Item
Test Ship –> [Item
Complete—> [Chapter
Reopen—> [Chapter

Dating System
Data Item Catagories
Split/Combine Ticks

When a new Data item catagory is created(by writing a new data item) (Edit: I stopped mid sentence and forgot what a Data Item Catagory was, maybe I meant that data items should be able to be added to a catagory (or any number of catagories) so as to easy viewing and searching)

Split/Combine Ticks takes one tick and makes it into several, or several ticks and makes them into one. It makes all the nessecary conversion changes from world years to ticks. (World years are static, but the conversion numbers are not)

Timeline View: (AKA Default view)
View Document
Filter Documents

Timeline View:
StoryWorld colors are the border of a StoryWorld Block, StoryArc colors fill the arc, Chapter colors are contained in the Arc. Timeline view fills the workspace with a white field and a horizontal grey line. Along the line are cross marks which represent ticks. When a universe starts the ticks should be about 1 or 2 cm apart.

Users can zoom in on the timeline and the ticks get farther apart. StoryWorlds, StoryArcs and chapters vary in height on the line depending on the zoom. If the Storyfolder is outside both the left and right edges of the view window it should also completely fill the verticle axis. Height of Storyfolders are are

Filtering hides documents which don’t fit the filter options

Search displays all documents which match match the search options. Both search and filtering can be used at the same time.

When a user selects New from the File Menu it starts at various points in the creation wizard.

Click File—> New Universe
A Dialog pops up asking for basic info
|New Universe Name:
| Next Dialog box moves to “StoryWorld Creation Wizard”
|New StoryWorld Name:
|Product: (This is the name of the game, or book whatever etc)
|World Color: |Initial Dating System:
|Name of Primary Unit of Measurement (Equivelent to a year):
|[Text Box]
|Number of Ticks per unit:
| Storyarc is an optional pulldown menu with choices: none, new,

If none is chosen, the wizard finishes and the program goes to the default view (usually timeline mode). If new is chosen Next progresses to the StoryArc creation wizard. When the wizards eventually exit a graphical representation of the StoryWorld floats on the tick timeline (ticks are unnumbered OR numbered relative to a certain point, OR numbered relative to the first existing StoryWorld) and where the user moves the mouse the graphic moves, where user clicks the world sticks and the SWorld locks into the nearest tick. (This might be better as a radio button instead of a menu)

|Story Arc Name:
|Arc Color: |Begining Date: (In Intial World Years)
|Intial Chapter: |—————————————————-
| ==============================================
|Chapter Name:
|Chapter Color: |Begining Date: (In Intial World Years)
| Chapter colors relate to the arc they are in. If the arc color is blue than choices for chapter colors can be sky blue, sea blue, dark blue, navy blue, greenish blue, primary blue, pearl blue, royal blue, etc.