--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --
The Database : ( another key component of the 'Player Created Assest' Process )
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --
. .

"Graph" type Database that allows fluidly linking information and its interrelations (and defining data of all kinds). A tool like this is needed to keep track of all the many thousands of seperate design issues, created 'Assets' and game world data, before/during the game development and later as the Asset Creation community continues to produce more content for the game (tracking and organizing all the Asset projects).

The game company would use it to organize everything related to the game - including the Lore/Canon of the MMORPG. Assets would be inserted as they were planned, defined and the built. Game mechanics details (documanting object attributes that effect how object interplays in the game) and all the initial object types (Temoplates for example - 'Chair') would be added. Those information skeletons would be accessed by the players to build up actual Assets.

Old 'known' (BS1/BS2/Novel) plot personalities/places/things would be added first and then newer items reflecting things added for the MMORPG (example - all the various storyline info about the new character 'Johnny' -- who was an accidental Delta clone, and where he fits in the newly created New Rapture plotline).

Initially players/employees do the slice/dice of the old BS1/BS2/MP/DLC content, incorporating them into the Database (and filling in gaps of needed item). Data items required for the new game mechanics/aspects (example- submarine game mechanics) are added and what is missing will be defined and added as it is created. More 'old' Assets will continue to be added after the game is running (and player will consult the Database to find out what has already been done).

New fill-in general details of the game Lore/Canon will be added (many requested by players for clarification/correcting discrepancies). Those game scenario details will shape all the specifics that will need to be created (guiding the creativity of the player creators). Database information will define what is SUPPOSED TO EXIST in the game and organize the planning for the entire game scenario -- how things interrelate so they can be built up correctly/cohesively. Decisions have to be made and then adhered to to avoid discrepencies and having to later make corrections if some change is needed. Having all that information consistantly and completely organized and easily searched will help the whole process.


The Database is divided up into several main sections :

- Lore/Canon - defines the game scenario to match the intended fictional Rapture universe. I would expect a copy of the Novel and all the various existing game text Assets would be incorporated and 'hyperlinked' and indexed to provide quick access to various Rapture 'facts'.

- Active Templates - define all types of Assets that have been 'published' (useable to make object IN the game world). Those now part of the Asset Dictionary.

- Seed Data - defines predetermined placement of things in the game from the start (alot of general placements for the parts of the world that the auto-generator will later build). This will correspond to data prebuilt in the game server database.
Part of this information is a symbolic city map that defines zones and areas reserved for certain functions (useful when whole sections of the city doesnt exist yet in any real detail).

- World Data - world specific data (server instance) that tracks important abstract factors used in Gamemaster moderation (like high level guiding of factions - things 'programming' is too hard/expensive/inflexible to do -- includes ideas for events and contingencies to help keep each specific world interesting). Each 'World' (server) has its own unique sub-database.

- Creation Projects - tracks player creation projects (players first define what they intend to create so it can be vetted to match the Lore/Canon and what elements that will fit into the game world (i- a player creating an effect for a 'neat nuclear explosion' would be told it doesnt fit -- but would be suggested to instead persue underwater submarine explosion which once existing could be useful for some quest plotlines)

- Submitted Assets - all the 'completed' Assets which players have submitted to be included to the game. These game creation projects are being vetted using the rigorous process (previously defined).

- Process definition - The Database contains all the data/information on how the creation/submission process is carried out (with alot of specialized processes for the different kinds of Assets). Scripts for auto-testing and manual steps make up part of this info.

- Tutorials - a whole section of the Database includes tutorials for how to create Asssets and make them complete enough to pass the submission process.

- Ideas - an assemblage of ideas players/employees submit for consideration.

All of these sub-databases can cross-index their information.


Roles and Data Access :

There is a system of User Role permission based access for different kinds of data (some is exclusively company controlled, some restricted to Community Authorities (like rejection of projects submissions) and projects not yet submitted are controlled by its author(s). Subsets of grouped data can have different permissions. Attached "Comment" datapoints have a different permission (most anyone in the community can offer a comment about an Asset project... ).

Database is Accessible to all PCA creators - "Read-Access" - Used as a central data clearinghouse for the game developers. The IDE tools interact directly with the database.

"Write-Access" data for new vetted Asset entries (PCA submission process for adding to the DB). Various parts of the 'Creation Process' IS filling in the Database with correct related info (with wizards guiding the documentation process). This defines completely what the Asset is and how it relates to other Assets. When an Asset is submitted, accepted and added to the published Asset set (Asset Dictionary) that data gets added to the big Database (in Active Templates).

The Vetting process would be integrated with the previously discussed Asset Vetting steps of the 'Asset Creation Process' -- the whole Process is thoroughly integerated together via the Database. (example - the Creation Projects Database will show that a project for creating a particular type object is 'in-progress' and anyone else contemplating creating a similar one can look that up. Likewise projects looking for collaboratrion will be listed.)

"Change-Access" allows changing existing data (modifying existing data is different than adding new data/relations). Anything that uses the modified data is linked to it and those things can be found to gauge the impact of a change and what/how much work it might take to propagate the change (there can be ALOT of dependencies - including by Active objects in a game world).
An example is : a correction being made when an invalid copyright infringement must be eliminated from the game - all active object must be changed and templates changes to exclude the offending data.

Some parts of the database is accessible to general players (not just the Asset Creation developers). Some New Lore is "public knowledge" and 'Suggestions' would be able to be filed (which includes 'Bugs' or 'Mis-Design').


Data to Track -- all game related data points including :

- Lore/Canon 'facts' (sourced from BS1 BS2 MP DLC contenet and the Novel)
--- - Known NPCs - Bios (likely expanded)
--- - Existing Businesses - names and descriptions (players will create more for expanding city)
--- - Locations (plazas, buildings, facilities, points of interest)

- New Personalities - NPCs (2000+ unique NPCs in the City) - as new stuff gets created it becomes useable by the auto-generator (players create bio achetypes for these that help define how the NPC behaves).

- Organizations/companies/societies - NPCs have memberships and roles in the New Rapture 'Society' thats helps define their behavior.

- Creation Projects and status

- Design and planning and Documentation


Types of data :

- Supports Rich Text with imbedded hyperlinks to all kinds of data

- Supports data groupings (with templates/records of 'required' data)

- Support for lists of flavors (value sets) for each link relation type (example- for classification object 'type' links, there would be a value of 'Chair' that would be the name of a set of all 'chair' type objects defined in the database). Some information types have fixed sets of data and mnemonic 'Keywords' can be used.

- External pointers like web URLs. Data can be references to external documentation (adjacent document storage in database servers).

- Map data - For Seed map (static) with fixed detail (common to all worlds)
--- - Plaza street and building locations
--- - Transportation networks
--- - Symbolic interconnects of locations

- Diagrams (graphic info)

- City locations/positions (coordinates or position in the symbolic city map)

- Tracking projects implementing details (links to creation projects)

- Datetime + Identity for tracking of changes to the DB (accountability for changes...)

- Pointers to existing (published) game Assets, and to submitted candidates

- Taxonomy Tree of templates (object types) hiearchical tree relations (from general to specific)

- Flag Markers differentiating NEW information --added beyond original Lore

- Canned Search Scripts - handy scripts predefine to assemble constantly used (and revised information)
--- - Players tools can also have these local

- Templates defining required data (like a schema) for relation linkages (different types of information for specific links)

- 3D data (meshes -- definitely useful for preliminatry visual designs)


Database Mechanisms/Features :

- A proper/regular backup system for the data (game company to handle this rigorously)

- Security - limiting data/task access and with proper verifification of identity - Logins (IP tracking) etc...

- Change logging (traceability and accountability)

- Lossless changes (changed data stays in the DB even if overwritten, allowing reversions)

- Search engine - allows finding info efficiently and easily. Search wizards for different tasks ( tie-ins (plugin use) with the many creation Tools and the IDE) --- - meaningful keywords used to define things (and use to look things up) - there would be a dictionary of these. Ease of use is important -- what good is a database if you cant find what you need??

- A Rigorous Submission process (incoming changes/modification, checks for correct format/completeness). Like the Asset Creation Process any kind of automatic validation/auto-rejection that can be done to save labor WILL be done (there will be enough work to do without wasting peoples time/effort).

- LOCAL DB - players own personal Database that runs in their client IDE (so they can organize their own projects with the same methods/abilities).

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

The Database program is just a tool (and a matter of integrating that tool into the others). The use of the database can be the hard part. Sticking to the process, entering the data appropriately, explaining how to access the data and make submissions is more involved.