Player Created Asset Collaboration System

* See also Asset_Creation_Process
* See also Player Created Assets - Things for the Game which Players Can Create
* See also Game Editing Tools and Apps
* See also Types_of_assets
* See also Rapture_City_Layout
* See also MMORPG_Creation_Database
* See also Object and Assets and Templates
* See also Vetting_of_Assets
* See also Saving_The_Game_Industry
NOTE- I realize all of this is very boring to some people, but it does take alot to explain something so different/revolutionary ( from how games are currently created ). These are just the Ideas - Imagine how stultifyingly boring my specifying ALL the full details ( about how this whole Process should work ) would be ...
--- --- --- --- ---
==Summary==
Player Involvement is what makes it work, not just for the creation part, but for the vetting process and even decision of when an 'asset' is enough of an improvement or sufficiently different for use in the game. And after that ( the individual Object Asset exists ) is then making use of a group of Assets to combine into more complex set arrangements usable within the game.
Communication is using common forum and message posting systems ( and download/upload to data repositories ). A significant component of the communications is simply passing ideas around before any asset is even created.
Players can help/assist other players to get done what is needed for the final creation.
Collaboration : different players have different skills and abilities and there is a spectrum of different roles using those abilities - from Programmers/Scripters to 'stage settings'. A Created Asset may have many Players supplying different components to make the whole - One the '3D' shape, another the many Textures to make it look right, another the basic Behaviors to make it act correctly, and another to combine it with other Objects that get placed correctly as a cohesive group. Other Players make good Inspectors or Testers who can tell if an Asset is what it needs to be - meets the requirements to be submitted/published for use in the game.
Web based Tools: More than a little of this Asset processing can be done with a combination of web Apps/web pages and many program applications. There are many people with web experience ( both for App creation as well as ordinary usage of web interfaces ). Many Open-Source/free web oriented creation tools exist and player themselves can create additional tools and things like 'wizards' for common tasks. This web use can go a long way to improving 'creation' efficiency ( I've seen this done for games like NeverWinter Nights, and for many "mod'ing" tools for many other games ). Many times, it is just one Player creating a clear walk-thru on how to Use a Tool that will get other Players past a steep point in the learning curve.
VERY Important aspect : Making sure that all added content Matches the 'Lore' and the 'Canon' of the BioShock Rapture Universe ( the final arbiters being the Company ). Guidelines would be published from the start, but likely would have to be added-to/expanded/elaborated on, as the whole project moves forward ( and improvements are needed ).
--- --- --- --- --- 
Measure Twice, Cut Once - The Carpenters' Saying :
HERE relevant to having a PROPER systematic Vetting of created MMORPG-Assets BEFORE they can ever cause side-effects in the production game -- which then takes even more work/effort/time to clean up the side-effects ( and it is hard to patch Player Confidence ). THAT Goes Double for anything with a potential Legal Issue. Actually : This is simply Smart Process all along, TO NOT WASTE PEOPLES TIME. 
That is : Thorough examination and testing done as part of the Creation Community Process ( and good Tools to do it effectively ).
-
LATE Correcting 'Artists' - BAD :
SO a MMORPG Player just spent hours putting the final touches on THEIR Game Asset contribution -- They DO NOT want to Hear that they did not fully read the Designer Specifications which makes THEIR 'piece of art' NOT what was meant for the game, or is just WRONG for the setting, and so to be Rejected. That kind of occurrence needs to be 'nipped in the bud' quickly and efficiently ( within the Creation Process ), lest their Time/Effort be wasted, and the Player 'back away' and in future avoid this crucial creation element of this MMORPG.
-
Consider : How much of Infinite BS's Bioshock:Infinite content was Created, and after another story rewrite THEN had to be abandoned ( or chopped up and shoehorned-in where it really became strange/wrong/lame ) ??? That, then done many times, with so much waste, resulted in that game being delivered Late and Overbudget and just being Inferior to what it might have been. Those 'artists' were PAID, and so might just shrug on their way to the Bank. A volunteer Asset Creator might not be so complacent.
--- --- ---
Creation By Collaboration With Canon Contradictions ? :
Watching the Wikis and Forums, and seeing how opinions/interpretations differ even for things largely already defined in the existing games, I see that there would be issues about the guided direction for the MMORPG's Storylines and difficulties to find consensus. There is already the existing Plots/Canon/Lore with their Contradictions ( 'Way too many' in the Infinite BS's magic polluted BaSx content ) and gaps/Vagaries. Extrapolation from there then would go into an envisioning of Rapture's future ( luckily not too far later, as most people IMO don't want it to mutate too far from what they have seen ).
Arguments about the story direction can go on forever, and some people specialize in doing little else. But hard decisions have to be made en masse early to define the content of the MMORPG, so that the Player Creators can follow it all for their Asset creations.
---
An idea is : With enhanced ability/efficiency for easier Creation, you could allow multiple versions of the Canon to exist in the MMORPG. 
Common Assets would be in the majority, and the differences would be created by those who want the Storylines to go one way or another. Separate Game Servers could host the different plots. In Example :
* One for a Classic Non-Infinit-ized Rapture version 
* Another having the BaSx Quantum Columbia intertwined plotlines ( with Tears and crossovers to Columbia still happening 10 years later ).
* Some endeavoring Players might re-create significant portions of Columbia (better this time ?) to allow this interplay.
BUT Would this Divide the effort the MMORPG would need to achieve critical mass ?? Too many small differences and confusions -- certainly in the Community efforts, where you now need to decide if something is Canon-Neutral to be available for general use or which way it needs to be Vetted or what flavor it is targeting. Potentially A critical 'Mess'.
Small vignettes ( treated as Splicer Delusions/Fever Dreams ) are simpler than creating several whole full sized worlds ( and different game mechanics ).
--- --- ---
Creating the Creation Community :
It would take a significant amount of organization to get the process in place ( the Process mentioned in detail above in the 'Wall-of-Text' ) -- I never said it would be easy. It would take some well organized people in the Creation Community ( both Players and company people who know what they are doing ) to keep it all on track and usable/working for the large numbers of Players needed to Create the mass of content a MMORPG requires. I actually saw this kind of thing work in a small way years ago for the game Neverwinter Nights, with very little company support and quite feeble tools.
This new paradigm is needed to get the current state of Online Games past the 'Company-Only' bottleneck which is giving us a 'lamer and lamer' product, as production costs increase ( much of the MMORPG gaming has moved backwards from what we had 15+ years ago ).
The whole Creation process is designed to 'Vet' the submitted content, and bounce it back to the submitter at the earliest moment, so as NOT to waste other people's time. All the criteria for rejection would be well-spelled-out to minimize effort on explanations - which would always be given, and would be required of anyone who declared an Asset unfit. There will be differences of opinion, but solid definitions/policies can eliminate many arguments.
'Bugs' or 'issues' should be caught as SOON AS POSSIBLE before alot of time and effort is invested - Thus eliminating Waste, when Whatever-is-Created has to be significantly redone (or even abandoned).
The Creation mechanism allows spreading the creation task out across people with a wide range of available skills, and allows Players weak in one area to use what is produced by others particular-expertise. This is done via an 'Open Source' style collaboration built into the system. The Tools will have to be good and easy to use, which is a whole costly achievement all by itself. The system would allow for many partially completed Assets to be accessed for 'finishing' by other Players. 
An example of this specialization is 'Arrangements' of existing Objects/Types of Objects into cohesive groups (a Scene Asset), which would take more imagination than technical skill to create, but which are constantly used within the Game World.
--- --- ---
Wisdom : There is a Fine Line Between Good World Building, and Rambling on About Pointless Crap.
A few players out there would be genius at doing this. So let's find them ...
--- --- ---
Goals:
* Apply the expertise and imagination of the player Community in an efficient way to create GOOD content for the game.
* Minimize the work needed from the company to allow them to concentrate on their role in keeping the game interesting.
* The Process should be self-improving - to make it work with increased efficiency and ease if possible.
--- --- ---
BioShock MMORPG Fun Starts Even Before The Game Does : 
Having Player Creation of much of the game's content ( via a well organized Player community ) -- Even if the Alpha and Beta Phases ( Players reworking the original BS1/BS2/MP/DLC content into the new game format ) takes 2 years, many Players will be having fun doing the creation and other Players who would be exercising (testing) the growing game mechanics and new Assets ( bigger and bigger chunks would be put on the Test Servers to test all the game features ). THAT'S Much better than endlessly speculating on some Forum, and wondering if they are going to push the release date back yet again. By the time the game starts, a large number of Players would be familiar with the creation tools/process to continue adding further new content. I'm sure the 'tools' and 'community' web interfaces can have lots of 'advertisements' embedded to help pay the way ...
--- --- ---
Requirements For the Player Created Asset System to Work :
The plan is for Non-Company people to do a Vast Bulk of the work ( which the Company isn't supposed to pay to create - Saving alot of money, which makes the whole game project viable monetarily ).
Coordinating a Community ( which to be successful has to be fairly large ) and sticking to stringent requirements for the process of building Assets for the game. Genre like 'BioShock' needed to get sufficient people ( later, once tools/process shown workable smaller genre may leverage the work already paid for ).
Alot of improper/invalid/insufficient submissions ( and people's egos ) will have to be dealt with efficiently.
Must be held to strict process criteria ( efficient testing and rejecting of problematic Assets to wait for 'fixing' ).
Proper documentation for Tools/Process is absolutely required ... slow learning curve for tools will lose alot of potential users. Players contributions must be facilitated.
Game Company must get original Assets from Existing BioShock Rapture games (BS1/BS2/MP/DLC) to allow recycling ( a significant head start, time-wise, money-wise ). The Creation Community will take time to 'get up to speed', especially for the more intricate Assets ( Quests/Missions ). So having alot of pre-existing materials will improve initial state of game.
The Game Company is responsible for providing a complete (comprehensive) initial set/system of modular Templates/game mechanics/definitions/specs. Any segment which is missing will hold up the Games progress. Missing elements will need to be filled in fast as organizers discover what is missing and prioritize efforts.
--- --- ---
Lore/Canon/Genre Adherence :
The Creation Community would have fairly strict adherence rules, and a well published Policy/Set of Guidelines about what contributions will be accepted, and what will be immediately rejected. The worse thing is to waste other people's time - the Players involved reviewing such Assets would not be being paid for their efforts and limited patience.
The Canon/Lore can be expanded to either fill in what happened between the previous detailed history (interpolation) or to extrapolate into the future time - the MMORPG takes place approximately 2 years after the Solo games (BS2/Minervas_Den) stories. 
The Game Company will have the (final) decisions about what will be allowed and provide additional Guidelines which are then used to judge Assets. The details have to 'fit' the previous knowledge or be a correction made for original conflicts/gaps/vagaries in the plot details ( IE - I'm not sure if 'WHEN Suchong Died' was/is resolved - There was alot of debate in the Forums - a MMORPG Creator, trying to elaborate on his activities as plot for some Quest/Mission, might need to have that clarified ). A whole section of the MMORPG's Community Forum will probably be discussions about these conflicts in the existing Lore/Canon, and how to resolve them.
So again, Players who wish to create history related Assets ( Flashbacks/Ghost Stories/Mission/Quest/Documentaries/etc ... ) would be requested ( as part of the normal process ) to submit the exact details/references on any history ( Canon/Lore ) being used in their Asset for a pre-review. This is to save everyone time. For rejections, Asset Reviewers may be able to quickly point to the Documented Guidelines where the divergence/conflict is spelled out, and send it immediately back to the Author for corrections. New Clarifications might be needed and added to the story documentation. The Reviewers ( and open Commentary Forum ) may be able to point out supporting information which at least can bring out related facts and hints for a valid resolution. Recommendations/suggestions which allow compliance can be made at the same time. Resubmitted Revisions would have their history and previous conclusions for the initial rejection ( If those problems are not fixed it should be thrown immediately back to the Author ).
This is the kind of activity that bloats into a major undertaking. Player creators (Authors) having to spell out proposals for Canon/Lore extensions they need, which would be reviewed by other Players, and eventually would go to a Company Employee designated to make decisions about what extensions/elaborations to allow ( including all the 'issues'/complications identified ). If rejected, the Company is also expected to supply a real reason, and provide clarification ( of what has to be adhered to - which would be added to the Guidelines ). The ( properly organized ) Company employee would have their own internal Guidelines/policies and notes to organize and coordinate that activity ( for continuity and cohesion ). A rejected Lore extension would be documented in the tracking system ( with its rejection reason ) to allow other Players to see THAT idea was already rejected -- to short-circuit other Players later trying to submit something similar ( this gives the Player Evaluators/Commentators something to point to for quick rejection reasons - so as not to bother the company employee again ).
How much can the Player Community Reviewers/Deciders be relied on to do all this work before Company personnel are involved ( like actually deciding lesser issues ), isn't clear. They might be able to give a 'provisional go-ahead', if in their judgement, it would likely be accepted or require only minor adjustments. A Player who has their idea initially Community-rejected might still force submission to a Company authority --- But that needs to be minimized, or everyone will try to do it for their 'pet' bad idea ( and the point is to minimize/streamline work for the few employees the Company is likely to want to fund ).
Of course, after the Asset Author further creates the Asset and it is later found divergent from the Canon/Lore/Genre, it can still at that point be rejected ( the review process validates at many points in its progress ). That stops any further effort to fully test the Asset ( which can take significant work ) until it complies.
Validation Components :
* Policy ( can spell out various general limits of what will be allowed )
* Guidelines ( more specific limitations )
* Known facts database/wiki ( expanded as Assets are added to the official game )
* Existing Assets ( You want to check if someone else has done it already or touched on the information you want to use )
* Projects in Progress ( see who else might already be working on the same thing )
* Change-lists to make plain recent decisions/additions to all of the above.
* Rejected Canon/Lore requests ( educate creators as to why/how things get rejected )
--- --- ---
Creation Community "Critics" :
Something put in my mind ( from a comment seen on a Forum ) about people belittling other people. Since my proposed MMORPG system has Player Created Assets, ( and you KNOW there will alot of faulty, repetitive, feeble submissions -- Assets AND Criticisms ), somehow you would prefer people to NOT get discouraged by derisive (or intentionally hateful/malignant/contrary/attention-starved-trolling) comments on something the (Author) creator put effort into. Even valid criticisms if done wrongly can have a negative effect. You hope to encourage them long enough for them to get better at producing their project -- To finally create something that is 'good enuf' (acceptable) to be used in the game. Many Assets are not simple 'Shake The Box' creations ( are harder than people think to do correctly, so to meet THIS game's requirements ), and often will take repeated cycles of fixing/correction and improvement. Getting something working in the simulators at least can help - showing progress being made...
A Forum mechanism can be moderated sufficiently to keep a lid on alot of such counter-productive criticism. A criteria for filtering critical comments would be REQUIRING the Commentator to actually justify their criticism ( intentionally invalid comments and Commentators would need to be quickly ejected so as to prevent wasted time ). Guidelines and requirements for the Assets would be made plain so they can be simply referenced as a reason. Many things would still be subjective and many people have their own opinions about what is good or bad (or proper). In any case, the process would require substantial attention/effort from Forum Moderators who largely would NOT be paid, to keep control over what might be a very large Community and a tight Process to produce the needed Game Assets. Players who continually are abusive can be blocked from being able to comment on Assets in the system ( and no anonymous comments allowed, no sock-puppets either - the Commentators are held RESPONSIBLE for their comments ).
Positive Encouragement will be a vital component, by experts who often will spot an easily fixed flaw or explain what needs to be fixed to enable finishing the Author's effort.
Spotting Redundancy - Even in initial design, Authors can be told "that part is already available by using this template or that sub-Asset or Tool", so that they can skip 'Reinventing the Wheel' and get to the creative part that they are really interested in doing.
Observation - Part of the proposed process is the 'Community' being able to look at a work In-Progress and facilitate corrections ( thru comments/advice ) early, instead of wasting alot of time if it is left to go down a wrong path.
In the end, there still may be a number of people who ignore criticisms and produce an outstanding Asset, which when seen ( played with in Open Review ) will justify itself more than was evident by simply being talked about. And thinking about 'explorations', there still is a place for Assets which may have been Rejected, but which still are outstanding in themselves to serve as ideas/starting point for someone else to improve on/make appropriate for the MMORPG. There can be a "Museum of Rejects" to serve as illustrative examples of how Assets can fail validation. Some people will get on an ego trip and simply make trouble when their pet faulty idea/Asset is repeatedly Rejected. The system needs to handle such people with the least effort by others.
--- --- ---
How To Keep New Created Content From "Going off the Deep End" : 
I've looked at some more fan fiction stuff and its largely angst driven teenage rebel characters with close associations with Big name Rapture personalities, anachronistic weapons/objects and world/cultural associations. Add lots of differently named Splicer variants with just bigger combinations of the same existing abilities. ( Sorry no 'lost' sons of Ryan, sisters of Eleanor, evil twins of Sander Cohen ... OR TITAN Big Daddy ).
* Start by only using props from the original games ( 'Chucking' all the 'Proscribed' ones, like the Canon-breaker BaSx content ).
* Strong Process Directions/Instructions/Warnings ( making it clear what will be accepted and rejected - particularly involving legal infringement issues ).
* Detailed Canon/Lore specifications for Assets applicable to the MMORPG game ( period stuff 1940s era, as examples ) Whole 'hyper-linked' World of Rapture database as a resource.
* New personalities - References to Defined Characters must adhere to guidelines, and not introduce new entanglements or conflicting/cluttering events ( as BaSx largely has ) -- definitely NO 10 more technology projects that Suchong was somehow ALSO involved inDr Suchong turning into a quantum device engineer in Burrial At Sea was stupid enough.
* Quality, of course, there would be standards for that as well. 
* KNOWN Buggy Assets won't be installed into the running game worlds.
--- --- --- 
Efficiency in Creation Community - How to Handle the 'Lookie-Loos' :
* FAQs, Tutorials, Docs to aim the clueless at -- Don't waste time repeatedly explaining the same answers to same questions ( and PUT the stuff into the Docs to facilitate that AND make it findable. ) You cannot stop Community people from being helpful to lazy people, but with good documentation the Basic Queries can be aimed at the extensive online materials. (( A good internal Search Engine which uses the 'AND' function by default would help - versus the commercial internet ones that return stupidity saying : "146,000,000 results found", and use 'OR' so to maximize the chance of returning an ADVERTISEMENT they sell and the user having to plow thru extra pages of irrelevant links. ))
* Early rejection whenever possible, and with fix-it advice (if possible). Standard Rejection Reasons with references to Documentation on standards.
* Registering Community users to cut out 'chaff' users ( also accountability for people involved )
* Have lots of examples to play with that wont impact the primary creation/submission processes ( many things are more obvious with a working example ).
* Creator Ramps to limit complexity of 'First Efforts' ( and often winds up being the last THAT person does when they get bored with it ) - Players work themselves up through more and more complex Assets, developing skill/know-how so that what they produce is NOT insufficient/faulty and half-arsed and almost automatically certain to be rejected.
* Automate alot of the processes so that many interactions "are not touched by human hands". Completeness Criteria which prevents submission if parts of an Asset are missing ( Collaboration allows passing around partial Assets, but that is a separate process ). Checklists make plain parts of an Asset expected to be completed for actual 'Submission' ( partial Assets would be freely handed around during the consultation phase or progress comment phases ).
--- --- ---
Game Asset Creation 'Want Ads' :
A large part of the Asset Creation Community activities is to create needed Assets for the game ( to get a decent representation of game objects first and foremost and then specialize/refine later ).
Postings online with descriptions/specification of what is needed. This can be broken down into separate elements to be worked on by more/different people ( or for half-finished works a request for the missing elements ). 
There would be standards for 'official' submission of these requests, which vary from simple Wish List entries to very detailed descriptions, which might describe very specific aspects ( ex- could include a picture of a Real World object that has a certain 'look' the requestor wants ). As usual, informal Forum discussion can be done endlessly outside of the official 'Want Ad' system ( some people are 'idea' people and can be brilliant in that way, yet get bored of actually having to fit into a process needed to organize real production activities ).
You would want somekind of task assignment process, so that multiple people don't waste their time working on the same thing ( collaboration is a separate issue ). Different elements ( shape/textures/attributes/behavior scripting/template data ) can often be worked on in parallel once certain constants are locked down.
Demonstration Credits. People who put work towards an object get Credit Listed. THAT is a whole 'nuther' system to be created/implemented to properly give credit where it is due, and to not have loopholes to those who might try to scam the system -- particularly if some kind of creation rewards are given - even if it is just an advancement ramp where creators can move up to more complex Assets after they have demonstrated their skill.
The already completed components/elements can be pretested in the online sharing mechanism ( Again : important emphasis on NOT wasting peoples time - bugs/issues are to be discovered early ).
--- --- ---
Lore/Canon Adherence and Reasonableness :
I've read some of the BIOSHOCK 'Fan Fiction', and frequently the Authors are not too careful about sticking to the Genre/Canon/Lore, including :
* Not understanding the 1940s/1950s time period/setting. IE- mentioning cellphones in a 1950s World, or even 1960s is a bit Anachronistic, and a bit too advanced even for Rapture ( or worse -- a 'wrecked' Rapture ).
* Behaviors of Main (Canon) Characters that conflict directly with what we've seen in the games/Novel
* New Relatives of Canon Characters (persons) who don't really have any reason to exist, or to have real connection/resemblance to those Main personalities --- Except to take advantage of 'name dropping' ( kind of like the ending of Infinite ... )
* Talking about Weapons that did NOT (or Could Not) exist in Rapture ( AK47/Uzis ) without any proper reason/plausibility given.
Some people may not realize that their creativity has to be constrained in many severe ways ( to be done correctly ) and finally ( be forced to ) realize that specific ideas just don't fit into the Rapture game world.
No doubt there will be a "Museum of Bad Rapture Assets" ( http://museumofbadart.org/ ) where rejected MMORPG Assets would be displayed and explored ( likely it would be an outside company venue to prevent lawsuits over various 'bad' content, or claims of 'feelings being hurt' ). Complex Assets, like entire choreographed 'levels', are creatable using the Game's tools. They could be viewable via the various Test Simulator tools ( much development work is to be doable on a Player's Client machine to off-load Company Servers/Networks and to speed up testing turn-around ). 
I can see all kinds of absurd Assets being created to amuse other people, as is done in so many other games Mod Communities -- You can go well beyond a funny .JPG with this MMORPG system. ( This creativity would be only seen OUTSIDE the Published Assets -- Unless they actually could fit in - and then 'Why not use them'. )
-
The Explanations for an 'Asset Rejection' is ALWAYS to be given, and references to the specs the submission violates would/should easily be supplied. Hopefully, examples of 'bad' Assets will be seen by many others to prevent them from submitting similar mistakes and wasting Their's and Other's time/effort.
--- --- ---
Vetting Player Creations - Quest Storylines :
Looking at some of the BioShock fan-fiction, reinforces the idea that 'Player Created Asset' content has to be well vetted. Not just for Lore and Canon adherence ( which will have to be expanded to fill many gaps in Rapture's story and logic ), but also for becoming too detailed and long ( most MMORPG Quests have summaries (often one line) that just tells you what you need to do without always having to read some temporary Quest NPC's life story to figure out whats expected of you ).
Perhaps such long Quest backstories can be made into books/newspaper articles to be 'found' in the New Rapture Library ( which the Quests would reference ). This would be another Asset that would be accessible 'offline' on the tablet interface...
Who does this Vetting ??? The first battle line will be the published standards/Guidelines that the Game Company will require submissions to adhere to. That allows simply referencing the well-documented Guidelines for a rejection instead of some long opinion fight ( there will be enough of this for other things ).
Example - Asset has references to a well known game-historic individuals. Mentioning new information needs to be controlled, as too many storytellers love to be 'name-droppers' of characters who should have nothing to do with the story OR worse do something contrary to how they have already been defined.
Usually, the plotline of a Quest would be submitted first, with a summary/outline/plan/design of what Assets/settings/interactions/story the actual Quest-taker would be subjected to. It would often be counter-productive/a waste to create polished and complicated sets of game Assets at this point if significant changes need to be made to the Quest's plot details.
The initial phase is for Players in the Creation Community to make Open Comments ( and quickly detect any negatives -- invalid/contrary aspects in relations to the standards/Guidelines ). If flagged as violating the standards/Lore/Canon, the Asset ( Quest story in this case ) goes back to the Author immediately - any further vetting would be a waste until it adheres to the standards ( other comments suggesting improvements can also be made ). If insufficient detail is submitted, it can be rejected for that reason ( a 'Wizard-interface' will assist in guiding the submission and filling in required details ).
References to Lore/Canon supporting any related mentions in the Quest would be included in the submissions. A Quest's subject matter may be 'controversial' ( a 'grey area' for the Canon/Lore ), and a request would be needed to be filed to a Game Company employee for judgement. If accepted, Official Lore/Canon would be adjusted to fit the new 'facts' ( -- Authorized Player's would likely do most of the work amending the Guidelines/documented Lore/Canon ). References to the documentation of these 'facts' would be kept for later re-verification as the Asset is fleshed out. ( As usual the official information would be subject to debate, but THAT needs to be tightly controlled to avoid contentious 'Opinion Swapper Wars' so common in Wiki-land ).
The Player on seeing the initial comments could ( would have to if invalid ) withdraw the Asset for rework/improvements/resubmission ( collaboration of this kind is actually encouraged and simple ideas (possibilities) seen by others can drastically improve a plotline and other details ).
The next phase is harder, as 'story telling' being 'good' or 'bad' is much more subjective. After the initial summary is accepted, the Author expands the idea to the full Asset. The Quest's story should integrate with the Quest scenes/situations and actions/goals, and these things may subsequently need to be improved/modified/elaborated to fit better ( to make it a good/adequate Quest ).
Once the Quest's preliminary info is accepted, then all the rest of the Assets and scripting to make the Quest operate would be created/assembled by the Author. These would be submitted again, open for full Community inspection ( including actually running it as a simulation ), comments and then full Vetting ( which includes detailed functional testing to make sure it does what it was designed to do ).
For the Quest's plotline text ( what the Player 'gets' when actually doing the Quest ), shorter is usually better, and 'full accounts' would be blocked off (optional expando) as supplemental, but the key elements would be retained for the basic story text.
Partial submissions for comments/help/collaboration can be submitted along this process to assist the Author, until the full Asset is ready for actual submission.
As with all Assets/Content, the Game Company will have the final say ( and if they find some new reason for rejection, THOSE reasons WILL be added to the Guidelines so that people's time won't be wasted the next time. ) One would hope that most policies/standards are decided early to prevent the need for reworking/changing already accepted Assets.
--- --- ---
" Just The Facts Ma'am " (Asset Summary) :
The 'vetting process' of the Creation community includes intercepting things that would break the BioShock Rapture Lore/Canon EARLY ( short-circuiting that path, before anyone put any significant effort into it - including the Author ). 
"Measure Twice, Cut Once" ...
As EARLY as possible, an 'Asset' project would present its ideas of what it constitutes :
* The Situation (in general terms) - especially what Lore/Canon it might interlock with ( Example - that Private Eye in the BS2 Paupers Drop Level - who's details are fairly vague at the moment, but who might have been further elaborated upon by other authors already -- when the Asset is being presented ... )
* What a Quest-Giver wants done. Where, How, Who, When ( What settings are required, what 'known' places are involved --- "Go to X" with X being a specific place or type of place ( giving an 'in' to making the Quest randomizable ).
* What the Player (Quest-Taker) will get out of it. Flavor of payoff ( loot, skill, Prestige, etc) ( and what partial payoffs since Quest are meant to be a bit better than your run-of-the-mill MMORPG pablum ). 
* What will result as the Quest is done : terrain locations(basic requirements) and contents, NPCs interacted with, information found, 'twists'/unexpected occurrences.
* Known Characters/history/timeline references ( And how - mention/description of any new MMORPG_Lore/Canon 'facts' that will need acceptance ) included any Special Twisty-ness intended.
* Other details would be specified of how/what mutatable the Quest is planned to be - Allowing the MMORPG's Auto-Generator to change details to make Quest semi unique ( Quests vary in how much can be changeable and may need to retain exact details to stay cohesive -- depends on various inter-dependancies ).
--- --- ---
Player Asset Creation Community COLLABORATION Assistance :
Matching up Creators looking for Projects (long or short) with specific specialties with the Authors of specific projects to get specific aspects done. Some Assets are fairly complex and most Creators don't have all the skills needed to complete ALL their aspects or to the degree they would prefer. There would be templates/tutorials for common Assets that would be examples of how to do the different aspects and tools to lead the creator thru the process, but efficiency and artistic ability take more than that.
The specialists would have exhibition space online ( where else ... ) demonstrating their abilities so that the Author might see possibilities they may wish for their Asset ( just the example might be what the Author needs to decide what to do themselves ).
The Collaboration Process creates a channel between the specialist and the Author to pass Assets and comments/progress back and forth.
Examples of Specialty Work :
* Object Texturing - Normal/bump maps are something many people don't even know exist but these are used to greatly increase the realistic look, without adding dimensional '3D' data that costs excessive processing.
* Scene Lighting - sometimes is more a matter of artistic abilities and the knowhow of achieving the desired effect for the specific Game Engine..
* Scripting - Sometimes particularly intricate or different solutions are needed to achieve a desired behavior and a particular problem requires the knowledge of a experienced Scriptor/Programmer ( When the rest is more routine, and the Original Author can handle it ). Very often a chunk of code can be adapted without requiring complete new creation - specialists know about them and can speed up the work significantly.
* Testing - pre-testing of an Asset to identify problems before the official submission process ( doing it when it is the most efficient - without the overhead of having the Asset openly inspected/rejected/reworked/resubmitted ).
* Dialog creators (and Proofreaders) - some people have the knack for making the 'speechifying' very much better.
* 3D shaping can be an art (or a chore for the neophyte). The shape of an object often turns out to be only a tiny part of all the data required to make it work in the game.
By getting specialists get the Author past the 'hard parts', much more will be successfully produced instead of leaving the entire ( often complex ) creation to a single person.
--- --- ---
Culling of TOO GRAND Content Additions Which Some Players Might Want (and even start) :
The Novel says that Rapture is a City of about 20000, and I've taken the liberty of expanding the total population of the 'Rapture Colony' to be more like 40000 total around 1958, so as to allow for all the producers of raw materials and manufacturing (many in outlying areas) that a real Rapture would need ( as well as some normal population increase - 1946-1959 is at least half a generation ).
I've also made assumptions that there was a larger remaining population than you might think, with the way the 'civil war' and Sofia Lamb's murderous tyranny were described/portrayed. Firstly, this was made possible by Ryan using alot of resources to keep things running during the %27civil war%27 Terrorism, which he eventually largely won. And secondly, by many outlying areas isolating themselves from the 'city troubles', as well as later City factions organizing things 'Post-Ryan' ( Sofia Lamb really only controlled what many saw as the 'armpit' quarter of Rapture ).
Still with 40000 people max, even with a exaggerated number of 'rich people' and exceptional achievers, there were severe limitations as to what institutions the City might support - versus some Real World city more than 10 X its size, having a much larger external supporting infrastructure. Rapture really only had the population of a medium size town.
* Businesses would mostly be small operations ( larger companies would be conglomerations of small businesses ). Successful businessmen, if efficient, or first-to-market might easily gain monopolies ( with too few customers for rivals to break into a saturated market and compete with the strong existing company ). 
* Minimal government meant many things had to be done by individuals or small groups of like-minded Citizens. Ostentatious projects eventually run out of money without profits to support them ( or build them in the first place ), or some deep-pockets interested in the project.
* Economic shifts might be exaggerated ( ie - the Financial Crises in Rapture - like the early one which bankrupted the AE, and a later one when confidence in stability was broken by the Kashmir_Incident - with Atlas's goons murderously disrupting normalcy ). Rapture's economy would be more brittle than bigger entities in the Real World.
* Another aspect of Rapture's small size is : it would be hard to keep secrets for long in such a small ecosystem (the Fontaine's smuggling being hidden/un-provable for so long was a lame plot mechanism). Clever people figure out how to reverse engineer other's products and might have half a chance to break into the market if their improvement was to manufacture/produce it more efficiently(cheaply). Huge monopolies ( requiring Real World economy-of-scale ) would be much harder to create ( limitations to mass-production ) when the markets just were not that big.
* Research and development costs are amortized when it results in mass-production - but Rapture is tiny. Smaller production, without economy-of-scale leads to higher unit price ( meaning fewer cheap goods for consumers ). Fundamental in Rapture - Concentrated Genius could cut/bypass R&D overhead significantly ( making it possible to create affordable things that normally wouldn't exist in a place so small ). Add the effects of Brain Boost to increase this happening.
The people responsible for the new MMORPG Lore/Canon decisions need to keep control over things getting too Large/Grand for what Rapture was - to be within its microcosm's limitations ( and morso for New Rapture which is only starting to grow and is many times smaller than the original City ). Some allowances may be allowed for prestige projects, but practicalities have to be considered for the majority.
An example would be the 'Rapture Philharmonic Symphony Orchestra which ( even in Raptures 'Golden Age' ) would more likely be a 'weekend' amateur arrangement, with some philanthropic funding ( or would that be NON-altruistic, with ulterior motives of ego and maybe advertisement ? ), and doing 'gigs' for City 'Bigwigs' egos and likely much commercial work for TV/radio commercials ( to keep them in beer and spaghetti for their weekly practice meetings ). As in the past, Chamber Orchestras would be far more common ( and would overlap with much of the musician population ).
Still, Ryan wanted some grand views and inspiring settings in his city ( and had them built using HIS money ), but there would also be much that was mundane. It is fully possible that the improved abilities for production ( all the advanced enhancements Rapture's exceptional people might bring ) could allow/support more excess, and having personalities and groups try to outdo each other with ostentation.
--- --- ---
Tool to Compare (Diff) Assets :
Players submit improvements to existing Published Assets, but if 'improvements' are re-submitted the Players doing the Inspections need to zero in on the differences. It is also a way to gauge the risk and possible need for more extensive inspection ( ie- any time scripting is changed, can cause all kinds of bugs/side-effects which requires extensive retesting, assuming previous testing had got that far).
This Diff Tool does a line by line, Asset data point comparison with the previously submitted version and highlights insertions/deletions/changes/new Assets/missing Assets. Types of changes are classified by criticality : Inspectors zero in on those first and if a problem is found there it can short-circuit the need for any further testing - because the Asset has to go back to the Author anyway.
Tool is also used on submitted improvements ( Assets submitted as improvement on a published Asset ) some people are real good at 'polishing' things ( instead of themselves producing complete creations ). A fundamental part of the game will be Players submitting 'improvements'.
--- --- --- 
Control/Prevention of Anachronisms for Rapture Asset Creation :
Canon and Genre and Lore - Guidelines would be well spelled out with online explanations of all limitations.
Mechanism for submitting questions to 'the Game Company' to get a judgement ( The Creation Community would pre-vet before bothering a Game Company employee ). But final authority is the Game Company when there is a difference of opinion ( or some aspect is touched which hasn't been defined yet in the Guidelines ).
Cliches alluding to things outside the normal Rapture setting ( vague/indirect references ... are OK - its part of the fun ) :
* "I coulda been a contenda " being muttered by a Splicer, would be amusing. 
* "It was like I saw in the Matrix" is too direct reference to Movie that wouldn't exist for 30 years on The Surface. 
* "It was like we were in some kind of matrix of delusions", would be indirect enough.
* Direct quotes from Shakespeare is OK. Direct quotes from Dirty Harry is Wrong.
The game is largely based on the way the World was in the late 1940s/early 1950s, with minimal new introductions later. That would be a fundamental limitation.
--- --- --- 
Need to Document/Track/Coordinate The BioShock Lore : 
Changes/additions/corrections/clarifications/conflict-resolutions to facilitate the MMORPG's extensions of the 'Rapture Story' ( needed to guide Asset Creation for MMORPG context -- Which is extrapolated several years past the last game episode - Minervas Den ).
* Inquiries for new issues proposed - allow community comments that may lead to resolution/conflict or request for clarification/more information
Asset creation requests get priority ( Players can dither about Sinclair's favorite cigarette brand in their free time )
* The Lore/Canon Database ( all that info - who/where/what/when/how and conflicts/contradictions/resolutions )
A huge (say again "HUGE"!!!!) Wiki-type organizational tool/DB to cross-reference all the information ( including situation of sources ) and new decision points about additions/corrections. ( Note - tight control over changes - may need 2 tiers of 'talk' on actual content ( which wouldn't be changeable by unauthorized users ).
* Timelines (and sub-timelines when it gets really detailed)
* Directories for personalities/locations/associations ( lots of inter-relational detail )
* Definitions/glossary ( the city does have alot of its own slang and Rapture-specific terms )
* Thematic explanations/interpretations - interrelations between all the information - fitting into (overall) Super-plot
* Lots and Lots of (consistent) Cross Referencing
* List of outstanding proposal issues ( to facilitate input from Community to help resolution )
* Forum(s) for discussion - community consideration, open proposals of solutions for issues - opinions, hard/soft/gaps 'facts' (and discrepancies/conflicts) referenced. Arguments kept civil and to the point.
* Process rules/Guidelines, Policy declaration ( optimizations to avoid wasted effort )
* Logs of recent decisions (official decisions) - 'whats changed' ...
Document how all this organization/process itself is to be done needs to be spelled out ( making clear the goals and reasons things are done a certain way ).
--- --- ---
Of course a WIKI for MMORPG Info/References :
A Player Community Clearinghouse for Genre data/information ( including references to all Canon )
Required for the Asset Creation Community to get their stuff right.
NON-Vague Story details have to be worked out, and Canon Clarifications made.
Themes/Idea sources ( links on web to sources ) fitting the 1946-52 era ( when Rapture went off grid ... there was some leakage post 'isolation too )
Slang/colloquialisms to use for Mission ( and by other Asset) writers, etc ... Old movies ... )
--- --- ---
SCRIPTING FOR IDIOTS :
Much game 'Scripting' (simplified programming) is fairly trivial complexity, but difficult in its completeness/detail/balancing. Good Tools to make it as simple/clear as possible are paramount.
You want an 'idiot proof' BASIC script system, which just about anyone ( after a simple Tutorial ) can make use of. Many of the 'scripts' are of limited scope by being part of a Template, like : a calculation (equation) for an attribute, or some Filtering criteria/Activation conditions, and such.
Predefined Templates for commonly done logic patterns ( cut-n-paste-n-customize ) can help alot
For program like chunks - No code loops, simple linear program flow ( with if-then logic branches if required )
Access to Object Attributes (and easy/understandable documentation of ALL the Object Attributes)
--- --- --- 
Idea Clearinghouse for The MMORPG's Creation Community :
Idea Collaboration would facilitate fleshing out the idea of what the Asset is and how it fits into the Game -- with different people adding for different parts of an Asset.
Some people are good at coming up with ideas but not with executing the rest of an Asset's creation process, and others have not so much imagination, but are technically proficient once the details are spelled out for them.
You would have online a whole selection of such ideas with various levels of development ( from vague summaries down to minutiae ) and presentation trying to illustrate the idea ( like showing a freehand sketch and not just a text description would get somebody started advancing the idea towards a game Asset ... )
Many requests would be made for specific Assets to 'round out' the selection of props/effects available to be used for larger Asset Assemblies ( Quests, auto-generator templates, etc ... ) to be able to build the various aspects of City life and all those wondrous things out there in the rest of Rapture. Example- motorized bicycles would be useful for some segments of the City and to the surviving 'suburb' communities who are also trying to recover/expand. A working prop object is needed usable by NPCs and Players. All the bits and pieces to make an operating object (especially a vehicle) is actually quite a large project ( even assuming we have operating bicycles in the game already ). All the details have to be decided, and spelled out so that the many sub-elements can be created.
The Collaboration System (online) would also have an area for requests for 'add' ideas to expand on in-progress Assets (example - a Quest dealing with a ruined bicycle factory needs a personal story dealing with Old Rapture, bicycles and the person who created and ran the business - to fill in some backstory that intertwines with 'Raptures Story').
Again, a key idea in making all this work, is to cut out waste and do the design and planning well ahead so that people don't put effort into something that would be discovered to not fit later ( and waste the Player's time/effort ).
--- --- ---
Player Qualifying for Creation Submissions :
* Point System for Created Assets :
** A way to limit how fancy/complicated a 'created' Asset can be. Particularly for Quests/Missions which are supposed to be only of a certain difficulty and effort to complete. Different factors like number of locations involved or terrain difficulties or number/strength of NPC opponents or length of dialog trees can be a rough measurement of how complex an Asset is.
** Players just starting to create Assets may be required to first create simpler low point Assets, so they can prove their competency before moving on to a more complicated Asset. Players should not jump immediately into building a full NPC with new unique behavior patterns ( which requires lots of complex scripting ) without doing simpler Assets first.
** Not sure how strict these measures should be and they may need to be adjusted, but the important thing is NOT TO WASTE ASSET CREATION PROCESS PLAYERS TIME dealing with floods of poor submissions and to drive them away with tedium of handling such.
--- --- --- 
Player Gets Idea for Something to be 'Created' : 
* Community discussion on Forums/Postings for ideas of things worth adding/improving in the game. Players make suggestions proposing additions.
* Tutorials and documentation of existing Assets can give players ideas ( if not what to do, but how to do it ) - Quests (in particular) being more complex, and with many optional ways to be designed.
* Game Company may make requests for additions - Community-wide Postings of official Asset requests ( Asset of type/variant with detailed description of what's needed ... specifics ).
* Postings of requests for collaboration - Authors who seek other to work on their Asset to add their abilities to creating an Asset for the game.
* Design - the player contemplates/plans what is required to actually create the desired Asset.
* Design - A Template that defines part (building block) of another Asset can limit what the resulting Asset instance can be and do. Built into the Templates are maximum/minimum values allowed for specific attributes and the scripting that might make use of parameters passed to the Template when run check the values to be within limits. An example would be a 'low-end reward loot' Template which would be part of a Quest/Mission as a reward given the Player ( the Quest would have a 'reward loot' Template specified for it and would have to run under the limitations imposed by that Template ). The Template's script code when invoked to 'reward the player' for a successful Quest result would generate appropriate reward loot for the mission that the Player could then take as inventory. Since only 'reward loot' Templates can do this operation, every Quest that produces loot would have to have one of the 'reward loot' Templates defined as part of its data specification. When a reviewer is looking at a submitted Quest to see if its valid, looking for any 'reward loot' Templates would be logical, and if it happens to have a 'Greater Loot Reward' Template incorporated when the Mission should not generate that kind of reward, then it is obviously invalid.
--- --- ---
Issue for Player Created Assets System - Asset Stealing :
Within the Game's Creation Community, Assets can be reworked by other Players and resubmitted to the game ( part of the incremental improvement and skill pipeline ). But there may be an issue of assets being taken from the community asset system and 'borrowed' for other companies games or other uses.
Liabilities :
* If possible, want to make use of existing Open Source tools to help create asset components ( textures, meshes, etc ... ) to utilize players previous experience/expertise. Game company would prefer not to 'Reinvent the World' for its toolsets.
* Asset data must be transportable to players computer for work ( leaving it open to being intercepted ).
* Assets can be 'reworked' by a second Player ( export to non-proprietary forms for use with outside tools ).
Possible Counter-Measures :
* Legal protections, but is often hard to trace data to prove a case.
* Proprietary data formats within the game system ( including client database and published asset data ).
* Most assets to be edited WITHIN game's own tools ( forcing proprietary data ).
* Importer from generic/commercial tool formats, but no export
* Alot of the functional data is unique to the game engine and game mechanics ( template attributes and scripts ) which are not really usable anywhere else.
* The Tool system on the player's client machine can be made to keep LOCAL-ONLY copy of non-proprietary import data for subsequent modifications (and then conversion again into the Creation Systems proprietary submission formats).
* Assets being 'reworked' by a second player would need to be done in proprietary format ( unless non-proprietary 'working' data is passed intentionally to the second player -- not done as part of the automatic system ).
The Creation System Process already has Process Policy and measures to intercept and reject (or remove) 'stolen' assets, and severe warnings and legal declarations about any use of Copyrighted materials.
--- --- ---
The Creator Player Sets Up the Asset Project :
* Player decides they want to work on a new or requested Asset (or looks up existing one for 'upgrade' or variation). The Player may need to find collaborators to do entire Asset (aspects player may not be able to do by self).
* Player looks at examples/tutorials/docs to see what's involved in creating THEIR Asset. Templates especially can prevent them from 'reinventing the wheel'. Similar Assets may already exist that already do must of the desired functionality.
* Submission of intent for creation project to work on a specified Asset (upgrade/variant/new)
* New Taxonomy(classification) - If Asset is a 'new' type of Asset, then a new Taxonomy will have to be added to System for future use. ( Example - chair/bench/couch already exist but player wants to add a 'beanbag' that does not yet exist ). Any new Taxonomy would need be formalized in the Asset System and transmitted back to the users IDE (to be inserted into project data ). The user would supply a description of what makes the object a 'new type'. New taxonomies are formalized by a designated Asset Inspector who will setup the appropriate data in the System.
* An "OK'd" (accepted) new (proposed) project would have its unique Project ID added to the Asset Project database and would be sent to the player's IDE.
>>> SEE open-source Systems ( like Source Forge ) to see how some of this kind of project stuff is done.
* If multiple collaborators exist then a signoff of intent by secondary collaborators is needed ( accepting their participation in a project's collaboration ).
** Primary collaborator had job of pushing others to get their work done or cancelling them and finding replacement
** A schedule for completion may be part of agreement ( some sub-components likely will have to wait for other subcomponents they have dependency on ).
** Some Assets like textures may pass thru multiple collaborators with different operation carried out by the collaborators.
** Arbitration may be needed if a collaborator does not cooperate in the group project. A collaborator may quit or be removed from the project. Partial work ( done by the removed player ) on an Asset (working data) may be retained and further work be carried out upon it by others in the project group.
** Placeholder Assets may be pre-supplied so that a dependent creation process is NOT held up.
* All data required for the Asset is downloaded into the Author/creators IDE ( all Templates for the taxonomy 'type' of Asset )
* If the project is an upgrade, the Player downloads the existing Asset ( and uses it as a starting point ).
* Often there are validation Test-rigs and design/help docs for the Asset type/Template or more specific ones for a 'upgrade' Asset ( an existing Asset ).
--- --- --- 
Players Performs the Creation Work :
* Player now creates/modifies Asset - building either alternate variation of Template or an exact 'instance'. If multiple 'collaborating' Authors then each creates their own part of the Asset project ( placeholder identities must have been requested/obtained to identify each part do the IDE can coordinate between the Authors ).
* Use various tools to create/modify the Asset data. When the Asset is far enough along, testing/debugging can begin to verify its functionality.
* Create the Assets documentation - identifies/references the Official Asset Request made by Community ( contains details of what the Asset is SUPPOSED to be ). Description would include reference(s) to any official Asset (Template/instance) used as starting point - if an 'upgrade. What makes this Asset different from all other Assets should be described in detail.
* Player has 'local' working database on PC work machine ( with a backup System being integral ). The raw working data is local and will be packaged later for submission and transmission.
* Player has same inspection/testing tools available to Inspectors to Test the Asset for correctness (The Player IS expected to pre-vet their own Asset ).
* TOOLS - testing all the STANDARD object interactions - effects (and combinations) fire/shock/water/etc... to see basic reaction behaviors - manual observation would be done beyond simple checking that handlers are present and working - cosmetic/presentation are not something automatic test tools can decide.
* Note - auto-tests are expected to be generated by the Author along with the Asset itself to test any specific features NOT covered by the standard (Template) tests. The process will be documented online and a wizard in the IDE will assist. Some tests may be automatic others will make use of a 'Test-rig' and script to exercise the object but with manual inspection of the results (expected results would be documented) and others tests would be a description of the behavior under manual testing ( which is often needed by objects like NPCs, which interact in complicated ways in different situations ).
** It is expected that the TESTING part of an Asset will be one of the most frequent collaborations, with players with a talent/skill in proper testing helping to finish Assets. The review processes will have a mechanism to add additional testing to an Assets project to improve its auto-testing ability. ( The test tools will facilitate this by being able to record testing procedures for reuse ).
* Asset Author may post a packaged "Work-In-Progress" Asset to an appropriate forum - for pre-inspection comments or assistance with development problems. ( Problems can be solved very fast with knowledgeable experts online - often with a reference to a FAQ or an example or other documentation for common issues. )
* Collaborating Authors can update each others projects with the sections they are working on - there is a check-out mechanism to minimize conflicting changes ( typical 'source control' software features ... )
* If the creation process is taking to long, Renewal and extensions need to be given on Asset projects schedule ( done thru simple interface on IDE )
* If the Asset is an auto-generation Template, then the Author has to provide 'generation scripts' that invoke the Template to create a real Asset that can run in the game world. Multiple examples exercising all Parameter combinations are expected. User would use their local test tools to run these 'generation scripts' to prove they run successfully. ( Fitting script execution is excluded as that requires full Server functionality NOT available on the IDE ).
--- --- --- 
Initial Submission :
* Submission Packaging automatically done by IDE ( failing Format test with abort process )
* Player fills out submission 'information' ( checklist of required info of a submission )
** Text description/documentation of what the Assets new/improvement/variation is ( to assist evaluation )
** Asset or Template ?? If Template - Documentation of how to use Template ( parameterization/subcomponent substitutions ). One or more example instances is preferred to be submitted with a Template ( Author should have had to make them up to prove Template worked correctly - such examples can become part of auto-test or semi-auto Test-rig for Template ).
** If the Asset is a 'collaborated' Group submission ( Multiple Asset with dependencies on other Assets ), the description needs to explain all dependencies. ONE player does the official submission - requiring all the separate parts to be fully updated on THAT player's machine before submission ( which would happen alot when serious testing was under way on the complete Asset ).
** If the Asset is only partially tested (not unusual) then the deficiencies in testing coverage will be explained.
* Submit as is made for 'candidate' Asset to the Community System - submitting all Asset + Information + Docs in entirety ( and samples etc ...). Automatic process does most of the submittal.
* Packaged Asset is sent to the Community System for 'peer review'. The Asset will be marked SUBMITTED status.
--- --- --- 
Peer Review phase (Community review):
* Asset is Locked in the System (so cannot change during review process)
* Automatic tools check the incoming submission for proper Asset format ( fail = immediate rejection) - this includes auto-verification against all specified definition Templates - of all the Asset's data attributes ( makes sure data which is specific to each Template is valid - all values assigned are of the correct type and all REQUIRED data is specified ).
* Dependancy check - check if all Assets the submission is dependent on already officially exist or are part of THIS group submission ( new Templates may be submitted as part of a specific Asset creation and have to be included ).
* Test Execution of Auto-Generation examples made to demonstrate correct generation behavior ( If behavior fails to generate objects, then automatic rejection ).
* All Asset source code/data/submission information is posted ( all information that makes up Asset ). Is now made available for download on the Community System for open 'testing'. If Asset is an 'Upgrade' of 'old' existing Asset, a 'Dif' (differential) tool can highlights any changes/differences.
* Asset Instances ( directly or 'rigged' use of auto-generation to create testable Assets ) are made available on simulators/Test Servers for open review ( sandboxed with any sample environments and exercising scripts ).
* Community now looks at the submission ( groups may split them up so the peers don't overlap their effort ) Submission is Open to entire collaboration Community.
* Manual Inspection for inappropriate content - using viewers and pattern scanners ( automated but tuned as new patterns found ). If found then Asset is immediately rejected ( forwarded to a judge for the actual Rejection ).
* Template instructions/documentation can be somewhat subjective - for accuracy/completeness/clarity ( user may need collaborator Author who is better at doing documentation ). Commentary on any deficiencies will be made. Severe deficiencies will cause rejection and request for rework of Asset to improve it.
* Testing done manually :
** Visual/auditory inspections ( animations, lighting effects, etc ... )
** Manual inspection of object look/sound/behavior ( copyright infringements/inappropriate materials ). Tool should exist to extract/assemble all text, sound clips, etc ... for easy review.
** Many 'types' of Asset objects have documented sets of defined tests to verify proper functionality. Example* a 'chair' test documentation should mention having a tester see if an Avatar in the test-Server can sit in the chair (all different ways) and do various other actions upon it. A semi-automated test script might 'stage' a NPC/Splicer doing the actions of sitting in the 'chair'.
** A favorite 'rigged' test is the 'effect cannon' that can bombard an object with all possible game effects so that tester can observe and see that effect behaviors are correct.
** All testing tools should be able to record 'tests' in-progress to record any observed bug behavior ( to be sent back if a failure is detected ).
** The tester will observe correct behavior/functionality, but will also look for clumsy/poor presentation of the objects operation (sound/look/animation/timing/etc ...) and will comment/report deficiencies.
* Comments are to be made by peers about insufficiency/defects found ( and for omission of expected behavior, not just incorrect behavior ). Official comments are submitted by an identified peer ( so the peer can be rated for their ability to inspect/test correctly ). Evidence to back up the spotted defect is submitted. Incorrectly/maliciously made rejection comments will cause downgrade of 'reviewers' rating.
* Submission of 'Bugs' ( with supplied simulation logs/rigging as proof ) attached to the Object. A 'Judge' will decide if the deficiencies warrant rejection of the Asset. Note - incorrect/malicious bug writing will be identified and Author can lose privileges/banned.
* Peer reviewers may post proposed fixes/recommendations back to Author and append new tests that demonstrate problems.
* Judgement is made on Asset complexity (likely failure) and level/type of review skill required ( ie- behavior requires more extensive testing by someone who understands behavior endcases ). There will be standard criteria for complexity levels ( can be largely automatically analyzed ). Authors will gain higher rating for SUCCESSFULLY creating acceptable complex Assets (over simpler ones).
* Judgement - a Community Judge evaluate the comments - to decide if there are any grounds for rejection. This should be made by experienced 'judge' who reviews commentary evidence.
* Rejection - Asset was found unacceptable to go further in submission process.
** Specific Reasons always given for rejection.
** All commentaries are accessible.
** The Asset will be marked REJECTED status and be sent back to its Author(s) for correction (and later resubmission).
** The tools should show/highlight the bugs found and reference rejection reasons/problems they address
** Arbitration process - If Author disagrees with initial assessment an Arbitration judge can rechecks if a mistake (it happens) made by reviewers and the Judge who agreed with the evidence for rejection
** Resubmission can have the 'Dif'(differential) tools run against the rejected version to highlight what was fixed.
* Pass - Asset was found acceptable to pass on to next phase of official inspection ( to the Player Expert Inspectors )
** There may still have been Suggestions of improvements ( that were not seen as 'blocking' acceptance ).
** If improvements were 'suggested' then it would be Authors decision to go ahead without modification
** The Asset will be marked Community ACCEPTED status.
--- --- --- 
Vetting by Inspecting Player Experts ( The Player Vetting phase ) :
Vetting_of_Assets
* Once the submitted Asset has been looked over by the Community for obvious reason for rejection, then more detailed examination is to be made by 'experts' who have more skill at finding deeper problems.
* Automatic tests are run again ( rejected immediately if fail - test System subject to review/correction if it failed here - should have been caught before it got this far with same automatic tests run by Authors IDE and by the Initial Submission System )
* Asset is auto-magically again made Available for review/testing on a Test Server and for the various Asset viewer tools.
* Rating made on Assets complexity to determine types of review/testing required ( ie- behavior scripting requires more extensive testing ) :
** Some Assets are just played/viewable media and require just human inspection
** Some Assets are very basic ( have no behavior of their own beside ) are standard subcomponents for combination Assets
** Some Assets are modified previously accepted Assets and have only had one aspect changed (upgrade/variation) that is independent of other functionality (that would not have to be fully retested - only the part that changed)
** Most prop Assets are largely passive ( just reactions behaviors for 'effects' ) and are inspected for appearance and correct reactions when subjected to 'effects' ( like being set on fire ) - Visuals/Sights and sounds and transition of state for all effect types and possibly combinations of effects.
** Some 'props' are tools that are used by NPCs and players to manipulate other objects in the game. They need to be tested to see if they carry out their function for various 'tool' actions they respond to ( ex- a rifle fires, but also can be used as a club to smash things ).
** Complex objects like a new NPC script for reaction to a situational factor ( ie- being chased by an enemy ) have to be tested in-situ to show that they react correctly. A NPC would be created having this behavior ( should actually be supplied as a 'example' with the Asset ) so that it could be tested.
** A Dialog tree should be tested for all of its logic branches ( some include specifics about the NPC/Player the 'dialoguer' is talking to or the current situation ( ex - vendor in a shop that is out of merchandise will cut the dialog short by telling user to 'come back later' instead of going thru an empty menu of products )
** All variations for different Client platforms will be exercised if relevant. Sometimes something new or slightly different can effect the tweaked rendering Systems or other aspects.
* Inspectors may prioritize what Assets they work on depending on whether the Asset was requested as a priority.
* Inspectors look at all aspects of the Asset ( particularly what the Author says is different about it )
* Many Assets defined as Type Templates are supposed to have a battery of semi-automatic tests that exercise Asset interactions combined with manual inspection ( You fire the flame at object and it catches fire - does it look/sound/act correct ? ... )
* Inspectors are encouraged to improve/add additional semi-automatic Type Template tests to the existing sets ( these standard tests have their own review process ). New semi-automatic Type Template tests get updated and distributed to all Inspector's IDEs.
* Reviewers may add/modify additional tests specifically for the particular Asset as part of their testing process Automatic tests are very useful in later retesting of all objects when broader changes might be made to the Game Mechanics. Manual tests are good to document to be used later if retest is needed ( Semi-automatic tests have setup scripts to 'stage' the situation where the asset will be observed by an Inspector ).
* Reviewers make sure that the documentation that goes with the Asset is sufficient ( Templates in particular due to their intended 'reuse' by other players ). A Patch-note summary should be included.
* Expert Commentary phase pros and cons - reason for Acceptance -
** Candidate Asset gets posted to appropriate reviewer groups ( some reviewers specialize or have appropriate skills )
** New Assets must be sufficiently different than equivalent existing Assets - variation worthy of being added
** Completeness ( all state views are composed, all reactions to effect types are handled correctly by objects scripts/data )
** The different parts of an Asset are checked off by appropriate Inspectors.
* Who picks these 'Experts' ?? How are they qualified? Somehow their abilities and capacity needs to be identified ( may start by taking 'volunteers' and then getting rid of the ones who don't work out ). Same would go for the 'Judge' who looks at a summary of any issues discovered about the submitted Asset and makes the final decision (for this phase at least).
* Judge - at end of review time period, a Judge assesses all review results/commentary/opinions/auto-test failures/votes
** Some reviews are subjective ( ie- a reviewer claims its copyrighted material with the judge would look at to agree/disagree - and may have to consult other 'judges' )
** Some from different reviewers considering different factors - Many reviewers are specialized in the different Asset aspects ( different aspects addressed by different sets of reviewers )
** Voting (?) System by 'vetted reviewers' ( reasons are sometimes a subjective decision ) - Rejection for something that is subjective - look and feel of Asset rather than pure functionality - may need a consensus rather than a simple decision by one judge.
** Picking who is a 'judge' may be an interesting process ( subject to trial and error as group of competent Community members is found to fulfill this role ).
** Judge will make sure that proper information about Asset Priority is included to pass on to the Company Inspectors.
* "Failed" - Failed review results always are to have a Reason given by the Reviewer - Any reason for Rejection should be documented, so as to be obvious, and preferably include recommendation of how it should be fixed ( If the Tester has a test that was done that is semi-automated, then THAT should be referenced for reproduction later ).
** Author who feels they were rejected incorrectly can appeal to the Community to look at the rejection evidence ( Judges can make mistakes also )
** Feedback to the Community about 'obvious' Asset rejection issues/reasons which the Community Peer Review did not catch. What went wrong and what needs to be changed to improve the process.
* Pass - submission found worthy of passing on to company Inspectors
** The Asset will be marked EXPERT ACCEPTED status and will be submitted to the Company Inspection phase.
* Grade for innovativeness/ major improvement/ versatility(parameterized variations)/ self-test work to go with Asset. Creator players (Authors) have a vector of scores for their different areas of abilities. Might be presented to the Community as examples of 'excellence'.
--- --- ---
Game Company Verification ( Company Vetting Phase ) :
* Some one has to monitor company staff who do this final inspection to make sure that they are not just 'rubber stamping' any 'Passed' Expert Player Inspection results.
* Asset are transmitted to 'Official' Asset inspection System. All automatic validators are again run against the new Asset ( always worth double checking especially when fully automatic ) - this also confirms that transmission to Company System was complete and intact.
* Asset has 'Pending Official Inspection' status
* Minimizing labor preferred for paid company personnel - their work mostly should mostly be oversight of the process.
* Company Inspector will read recommendations from player reviewers for Priority to add ( ie - a missing Asset type that would be very useful for ______ or if Asset is response to a 'Asset request' made by company to fill in gaps ). There will be various reasons for setting deployment Priority.
* Asset will be Classified for deployment priority ( a priority queue of new deploying Assets will determine if a 'Client Startup Patch Mass Download' should be done versus 'Streamed Download' or 'On-The-Fly' download by Client ).
* If Asset is chosen then will get a 'Go for Test Deployment' status. Other Assets may be put into groups for later deployment.
* Multiple Assets are grouped together as a 'Revision Set' ( That would eventually be posted to the 'live' Servers ). Grouping them can help determine if there are any unforeseen side-effects. Test Servers will be setup to include the entire Revision Set of changes so that proper testing ( matching what the 'live' Servers will have ) can be done.
* Revision Set is packaged exactly as it would be deployed to Game Servers and to players Clients.
** Packaging for distribution to Clients ( 'on-the-fly' or patch) - largely automatic.
** Packaging for Server data patch (Server-side code/data) - largely automatic.
** Packaging of Patch Notes that will go to the general player Community. Company staff make the information presentable for delivery to ALL the players.
** Packaging of documentation for the Player Development Database to available for further use (ie - Templates ) and collaboration (upgrading). Is mostly the data provided from the Authors with additions from the 'experts'.
* When ready the revision will be deployed to a Test Server loaded with real game data ( taken from one of the running Game Worlds ) and be exercised with Client downloads.
* Revision Set is now deployed ready/available on Test Server ( auto installation/deployment - don't waste company personnel time with some tedious manual process ). Testers will have their Clients loaded in exactly the manner customers will get the revision - all variations and all platforms.
* Company Inspector will look at/test Asset in situ ( as it would operate on a live Server ) to see if it behaves correctly
** For simple Assets this can be very short inspection - 'the chair'
** For more complicated Assets ( like a Dialog Tree with its many endcases ) there can be alot of detailed testing
** Most of the detailed that was SUPPOSED to be carried out by the player review process.
** VERY important Assets will get a more thorough company inspection.
* A subset of 'trusted' players ( and the Authors of the Assets ) should have a change to test their Assets in this final form to try to catch anything they missed. ( The verification of the 'Revision Set' may take a while - like 2 weeks or more ).
* Rejection :
** If an Asset has defects, Asset will be pulled from the Revision Set and marked as REJECTED.
** Reasons given are recorded and will flow back to Author ( and the rest of the Community )
** Will also flow back to player 'Expert' Inspectors who 'signed-off' on the Asset ( They need to know what went wrong - WHY they didn't catch the problem )
** If this Asset is part of dependencies of other Assets then THOSE Assets will be pulled as well ( like anew Template ).
* Acceptance :
** Priorities for how quickly the Revision Set should be distributed ( ie- soon as possible if a problem is effecting running the Game Worlds and is impacting the Player's game experience. )
** All submitted Asset Projects in the Revision Set will get status updated with likely schedule for when actual posting to "ACTIVATED" status.
** Revision Set is marked "READY FOR DEPLOYMENT"
* Patch Notes for Players:
** The Usual offline (web) publishing ( but hopefully better than the feeble one-liners most companies provide )
** Any changes effecting Player interactions would have to be published ( preferably ahead of 'the patch' ) to alert Players to game changes that might make the game act differently or new options of things that they can do ( this applies to Templates in particular ).
** Significant new additions would be announced - like expansion of the 'Outside' areas that can be explored or a new 'video' recorder mechanism that can allow players to create 'in-game' media that can be applied to the various media channels ( mail attachments/in-game TVs/public archives/exports from game/etc ... )
--- --- --- 
Game Incorporation Phase : 
* Revision Set (containing new Asset submissions) are incorporated into the game ( Assets get added to Official Asset dictionary )
** Dependency - Client component deployment must be put in at same time as Server Deployment ( Forced Client data update Download or changes all pushed into the 'on-the-fly' streaming upload data source in the Server )
** Dependency - Assets that use other Assets MUST have all their dependencies met with Assets also currently deployed.
** Distribution mechanism for Client side data - some published on-the-fly ( small or localized use like Quests ) and others as a 'patch' (critical ones added on startup) and others as 'stream' to Client ( medium priority ones that should be there ahead of use ).
** Restart Patch - Patch requires Client RESTART ( like patching the Client program itself ) - usually is forced by a short Server Downtime where the user has to logout Client.
** Patch - High priority - usually much used Client data like common menus but also may be complex Assets that are best transmitted as a group.
** Stream - lower priority - individual Assets will be downloaded in background and be put into the Clients "Asset Atlas/Encyclopedia" for future use. If the Asset is 'activated while the Player is Online any 'Patch' Assets will be used.
** On-The-Fly - infrequently used Assets - Client can still do 'Load Ahead of Need' so the Asset gets to the Client before it is actually presented to Player ( for a 'shop' dialog at Chauncy's Fish Emporium, it doesn't matter if the Player has to wait a few seconds for the Client side dialog components to be transmitted from the Server to the Client ).
** Depending on how well the MMORPG's Console Systems handle background disk operations (while the Client is running the game), their Revision Set Data may have to wait to be activated via a Client-Restart type patch to the "Asset Dictionary"/Atlas database.
* Asset Submission is Actualized ( Revision Set is posted to Server/Asset-to-Client deployment )
** Packaged Data is placed in appropriate Download Servers
** DEPLOYED flag is set ( marking Asset as accessible )
** Retrieval is immediately tested an verified via a test Client that acts exactly like a players Client. Client code will check that all dependencies are fulfilled.
** Passes - ACTIVATED flag is set ( which allows player's Clients to download and use the new data )
** Fails - should not, but if it does then something significant needs to be fixed as this mechanism should work like 'Clockwork'.
* Activated status for Asset :
** (All) Server component is in place (if any)
** (All) Client component is in place ( patch is deployed for next Player login ) or ( download 'on the fly' will operate )
** Update the Asset System database marking the new assets as the new official data.
** When the Client now does a download, it will get the Asset in its entirety ( completeness of the client side database )
** Patch notes for this Asset and documentation are posted to the Player Developers Database as 'ACTIVATED' and will be available for further reuse in any new asset creation. ( IDE constantly checks for revisions to Templates and even base assets a project may use and will notify the Author so that corrections to in-progress projects can be made )
--- --- ---
Post Incorporation :
* Clients will get the Asset data sent to them whichever mechanism is used. And corresponding components are ON the 'live' Server.
* Players have mandate to report defective/invalid Assets IN-GAME ( with reward System of some kind ). This is another important component of the whole 'Player Created Asset' scheme due to the greater amount of content THIS game will have ( I'm appalled sometimes at how long even simple defects are allowed to remain in some MMORPGs and it makes you think that the company really doesn't care, as long as they are raking in the money ).
* A Report mechanism tool (in Client) with built-in recorder to assist documenting issue seen (bug evidence)
** It is highly preferred that in-game GMs (Game Masters) do not always have to get involved in bug issues ($$$$ saved)
** The Client Bug Tool ( If it can be aimed at the offending object and the specific culprit/situation can be identified ) might report back immediately to the bug reporter if the bug/problem has already been reported ( was matched against a bug database ... not always easy to do automatically ) so that THEY (the Player) doesn't waste any more time demonstrating the bug or have expectations of the Bounty reward.
** The reporting player could get at least a list of similar reported bugs ( so they could decide if its already been reported )
** Important for the reporting player to get credit for finding a real bug ( as a general incentive ).
** Obviously has its use when testing on a test server by the general testers ( where it is preferred to catch the bugs ).
* If a defective Asset is identified on 'live' game :
** Decision by Company Operator may be to Deactivate that Asset ( depending on effects of the 'Defect' ) - If deactivated, then the Asset will be no longer available for object placement/generation or running of a Template and the Client will mark it in its Asset Atlas so it wont be used.
** *** Inter-dependent Assets Issue - if other objects have a dependency on the defective Asset then they would have to likewise be deactivated or a applicable substitution found - reverting to the previous version if there is one.
** Server Asset marked 'INACTIVE' (pulled) and will not be used further in running game.
** Any INSTANCES of the Asset may need to be pulled from Game Servers ( with default substitution if possible ) instances created with a Template may have to be 'Adjusted' ( the Company usually has to create a script to make the appropriate adjustments and the Server swept for objects that used the Deactivated Asset - which takes alot of work ).
** Patching mechanism (streaming) will direct Server and Clients to modify their Asset Dictionaries/Atlas with the changes.
** THIS is why catching any/all defects is important to do BEFORE Assets deployed to live Servers because of the amount of work ($$$) it will cost to correct the problem. At least this mechanism can make fixes immediately instead of your usual MMORPG that you have to wait a long time for the next 'patch'.
* Defect/Bug needs to be Recorded in-detail - with automatically collected evidence, including any situational data ( since objects interact with each other - Any kind of data like that will make it much easier to identify exactly what the defect is ). Comments from the bug reporter will continue to be useful to specifically describe the bug.
** In-game tool would record the in-situ situation ( some kind of snapshot of the local area on the Server ) to allow later semi-automated recreation on a Test Server.
** All this data will be attached to the Asset in the Player Developer database ( collaboration system ) so that Author and the community and the company can see exactly what the reported problem was.
* Making Improvement to the Vetting Process :
** After a bug found - Why did the Submission Inspection/Testing Process NOT find this defect ??
** What can be changed to catch it and similar problems inside Vetting Process - like additional automatic tests or semi-auto scenarios ( more Test-rig situations to test - to put asset into as part of normal testing ).
* Defect is kicked back to *Process Designer Group* for improvements to automated/manual processes
** Notices sent to reviewers ( warnings of 'Deficiency of Process' )
** System database is updated with deactivation of Assets (revert to predecessor) and mark as 'Pending Bug'.
** All projects using the defective Asset as a 'base' (variation/upgrade projects) would be notified of the defect ( and later the IDE would pick up the corrections ).
** Some defects take a long time to surface and many other Assets may have dependencies ( and MANY game objects may by then exist using that Asset ). SO getting the Vetting Process to find bugs BEFORE they go 'live' will save alot of work/effort trying to fix them afterward ( something many companies DON'T realize and they skimp on proper Quality Assurance ).
* The problematic (rejected) Asset is sent back to Author(s) for correction of the defect ( and then to restart submission process - with corrections well marked/indicated/explained ).
** Detailed info/description provided ( including logs/recordings/other evidence for easy re-creation )
** Preferably with a Test-rig script to demonstrate the situation in which the error occurred and to show that it is fixed. The test would be added to the tests run against objects of the same Type.
*** Example* arena script with 'the Chair' with the Flame cannon firing at it showing that it now catches fire and burns properly - this test is semi-automatic and needs a human to watch and confirm, but the setup of the test would mostly be automated.
* Objects that pass the official submission process will always be available for Demonstration/Observation/Testing on a Test Server. In-game test tools are able to identify ANY object (Taxonomy) so that it can be fully identified. All Objects can be dropped into a Test Server - part of the general debugging functionality. This allows improvements/Update to Assets - where the player doing the 'update' wants to see how the object behaves already so that they can plan improvements.
--- --- --- 
Expressed Appreciation :
In the MMORPG Game's Community, there should be a way for players to express their appreciation to those who created the things in the game that they find good/interesting/enjoyable. This entire Collaboration system is meant to improve the games over what the Company can do. Part of the incentive of some of the player Asset Creators is having their abilities and imagination recognized and a feeling that they took part in helping to improve the game.
No doubt there will be accumulations of unfinished/abandoned Asset projects ( it is expected in a volunteer system ). Disk space is cheap these days. If the Assets never get submitted, then there is no effort wasted on anyone else's part ( projects will 'timeout' on their schedule and not be extended/renewed ). Some players knowing they will not be able to fulfill their project, will RELEASE their project, so that it might be picked up by other Players.
Some in-progress/stalled Asset projects may be adopted by a new Author - after the original Author did not Renew their project ( some people are better at finishing a project than starting them - and vice versa ). This allows partial efforts made by Players to still be used to eventually produce a game usable Asset. Likewise seeing the failures of other Players can be very instructive and even just give ideas to players for what THEY might want to do.
--- --- --- --- ---
ALL SO MUCH - NOBODY COULD DO THIS !!!! :
You look at this whole process and say 'too complicated, it will never work'. It would take some work to create ( I've mentioned that the extensive tools/process for this can be equivalent to creating the game engine itself ) and some effort to get a player community organized. But consider that those tools and processes once developed can be reused over and over for multiple MMORPGs the company could develop. Likewise when the bugs are worked out of the community it is a model for the next one ( and can skip the teething troubles of the first one ).
--- --- ---
For People with No Imagination, Who want to Create a MMORPG Mission - The Rapture_Reborn Story Generator :
Build a Random connected Story ( using a 'Wizard' interface, with 'pull down' plausible story options, and with sufficient Mission Validation Logic to make sure the parts fit/stitch together adequately ) with detail fill-in-the-blanks ( provided with suggestions and handy defaults ) when desired. 
Predefined ( and often self-fitting ) groupings/prop-assemblages/terrain sets of placeable Objects eliminates much of the work on fiddley minor details. 
Then there is some randomized content filler to vary things a bit ( make it look somewhat different to every Player that plays through it - grungification/defacements/leaks/lighting variations/etc ... ).
Greatest of all ( brought to you through the magic of Templates ) -- Automatic Scenery composition/Production. This all uses the MMORPG's Auto-Generation system to immediately build and view the creation ( even quickly flip through a selection of random factor application/variations ). 
The static parts of the Mission design can subsequently be overridden/adjusted/reapplied/tweaked until the previewed 'Mission' looks close to what the Player wants for their scenario. 
Option Selections are made Coarse-detail-to-Fine of flavors/options/sub-options to customize/refine the result. 
Automatic validation logic is part of the Template system ( the editor visually flagging/invalidating/blocking any conflicting/non-cohesive details/elements that occur).
Tools : something like this have existed for various games over the years, but were secondary products to their game and made by a sub-staff of company people. In The MMORPG, the Player base would be called upon to improve/expand the capabilities/ease-of-use to make it all work far better.
Preexisting (World Map) Rapture locations can be used for a prologue path towards the Scenario's built-on-the-fly main setting ( "There's a guy who wants to get in touch with you, and he'll be at the corner of Freedom and Commercial Streets at 7:oclock"... which directs you down that manhole wherein the sewer area has something of interest ... )
The Game Server creates a temporary "Bubble Instance" ( a made up place on the Server ) at the game-time for a Player running the mission. Props/terrain/NPCs/dialog are placed logically for the play-through in some generic locale which later isn't to be found ( plenty of non-descript places in Rapture - its big ... )
The point of the whole system is to allow Players to Create without having to bother with a myriad boring insignificant details ( with ease, so to maximizing the number of Players who can do so ), AND to create Mission content which wont interfere or have to be tediously integrated with all the others.
--- --- --- 
Canon and Lore - The Rapture Universe : 
With the Player Created Assets integral to the MMORPG, someone will have to be the 'authority' to make decisions about shaping additions to the 'Rapture Universe' and whether submissions for plot elaborations 'fit'. Original developers like Ken Levine and the other designers probably won't want the job ( except for some (paid) consultation about 'big decisions' ) and would delegate the job to others. In the hierarchy, non-paid advisers ( the Player Collaboration ) would have to exist to do alot of the 'grunt work' ( to match the business model's needs ). Publishing and sticking with extensive definitive guidelines can short-circuit alot of repetitive 'dumb questions'. Having early 'open community' commentary ( collaborative Vetting ) tasked to find glitches/invalid submissions, would greatly lessen having to refer decisions to company-paid 'authority' ( as well as stop/prevent the Player Authors from wasting their time on something that would be rejected ).
--- --- ---
Name-dropping is Very Easy. 
BaSx was a bit excessive with that -- Making references in text/recording costs virtually nothing compared to the work creating new terrain/major characters, etc. Watch :
Audio Diary, Joe Blow : " Hey I was down at Neptune's Bounty the other day trying to buy fish for the Bistro, and you wont believe the crowd of cops around that place now. They're poking into every corner and prying up floorboards with crowbars. Ryan's security honcho Sullivan marches in and out of Fontaine Fisheries pretending he's Dick Tracy, while there's almost nothing to be had at the Fish Market any more. I wish they would get this shit all done so's I could just go to Lotz & Sons and actually get the tuna we need for our customers in Olympus Heights. That Fontaine bastard had it coming, but why do the rest of us now have to suffer ?".
-
SEE, It is SO easy to attach new content that way to the previous games, but alot harder to NOT to attach in the wrong way and pollute the game's Canon ( or just plain overdo it ). An important part of the Creation Community's process is to keep that kind of thing under control, as every-other fanboi will want THEIR story to be linked into the 'big names' and events from the original Solo games. Indirect references and information that fills in more of the culture/society/interconnections/events of Rapture hopefully would be done by large numbers of these both as paper documents/letters, newspapers/media, and the Audio Diaries.
I could see a whole Hypernet diagram/chart of interrelations and references to existing MMORPG Assets to help prevent duplication - And worse, conflicting information. Such a Tool would help spot gaps in the sub-stories and be used to post raw data waiting for fleshing out and conversion to in-game Assets. Submissions would be subject to the usual vetting and comments process. 'Form letter' creation wizards with many style Templates would then assist in making the actual Assets ( Heh, and then various 'Grungifications' which can be applied ).
Voice acting requires much added effort, so it may be allowable for Text type Audio Diaries to exist ( Voice Synthesis is still rather cruse/primitive as yet for this kind of thing - so far ).
--- --- --- 
There Are Players Who Are Better At ORGANIZING Than At Actual 'Creation' :
With the complexity of some Assets requiring multiple Object pieces and multiple Talents, there would be players who do more organizing than actually making these bits. Likewise DESIGNING isn't the same as MAKING. The Collaboration System is a good bit involved in allowing the Organizers and Designers interacting with the Creators and Makers (and Tweakers).
--- --- ---
Running Jokes Accumulate Funniness ( Its a Law of Nature ) :
Need several/many ( even if they are initially lame by repetition, they then get better with increasing Player additions ... )
Just what you need - the 'comic relief' NPC 'Team' member who does/says stupid things that get you killed (or not). Getting AI to say things at the appropriate time is actually fairly hard. Logic to NOT have them repeat the same things too often isn't so hard. Timing is important for such humor.
Absurd Arguments between your "Team' members reflecting some of the myths and superstitions which Splicers had, or opinions about what's going on in New Rapture ( There is a reason YOU are the Team's Leader, and make decisions ). Again, having some relevance to the situation can be important.
--- --- --- --- ---
.
.