Asset Creation Process

* See also Player_Created_Asset_Collaboration_System
* See also Game_Editing_Tools
* See also Types_of_assets
* See also Player_Creation_Contests
* See also Player Created Assets
* See also Initial World Composition
* See also MMORPG_Creation_Database
* See also Tap_into_the_Players_Creativity
A Creation Process used for the Rapture Reborn MMORPG which utilizes PLAYERS to do much of the Content Creation.
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
== "Help Us Build Rapture" - Player Involved Creation Process == 
-
Players Initial Assistance generating Pre-game 'Starting' Asset Data 
A Limited Set of Startup-Production Players To Provide : 
* Time/Effort/Manpower
* Willingness to Recreate that Original Rapture 
* Know-how/Knowledge/Skills/Creativity 
* Useful Tools Found/Added-to
* Access To External Materials
* Money ( InvestmentLegal Issues Abound About 'Unpaid Workers' which have to be handled properly. )
They get an Early Look at what the Game will be and be a part of making it happen
From the "Rapture Reborn" Company Gamemakers :
* The Vision
* Cleverness/Innovation ( to make a superior new kind of game )
* Know-how/Knowledge/Competency
* Dedication/Perseverance - The Will to Achieve something Hard
* Honesty, Fairness and Directness to the Players
* Lack of a "For The Buck, Above All" Mentality
* Old Game Asset Data to mine
* Test Servers to 'prove' Assets
This initial stage a more a Closed Process with Trusted Players, 'counted on' to get good usable Content going before the Playable Game can be Launched.
Assumption is : There being a largely working Game Engine -- which will still likely need much adjustment and additions.
A 'critical mass is required before further BROADER Player involvement in the Creation Process.
--- --- ---
Development Phase :
* Game Engine Confirmation - Everything else is dependent on this being complete and usable. This includes NETWORK/INTERNET mechanisms/infrastructure.
* Most Company work is establishing/perfecting the Mechanisms through which Player Creations will operate. This is a difficult task, as the programming involve is many times that of a static game Solo Player game and 'simple MMORPGs. 
* Client Graphics Features defined and optimized ( for all platform variants ).
* Basic Templates for Asset types complete. Behavior Scripts developed for NPCs and Splicers. Scripting for Player Interactions with the Game and its simulations.
* Game Engine made operational - ( Server and Client working as designed - all OSs/platforms ) .
* Developer Testing of proper functionality made and confirmed ( minor problems identified for further fixes )
* Initial Assets (all flavors) tested to prove they work. Development and testing of Templated Skeletons for Mission/Quests, and the more complicated Assets.
* Company gets ALL the [Game_Editing_Tools|Creation Tools]] 'beaten into shape'. It is Best to find the deficiencies early. It is far more effective fixing things early than to have to fix them later - It may seem obvious, but many game programming companies (not just for single games) in their expediency 'Leave it to be Fixed Later' (Frequently NEVER), and then Publish/Sell what is effectively a defective 'Prototype' ( possessing many serious problems ). These short-sighted companies may not understand that they then pay heavily when many (millions of) potential Players learn and reject/dont-buy something which is known to be massively defective. Player-used Tools REQUIRE alot more polish and 'bomb-proofing/idiot-proofing' than Company developer-used Tools ( AND Something Like This MMORPG is a far larger project ).
* Proper Documentation, Process Tutorials, and Examples written for Player use ( Some appropriate Players would be selected for Documentation review and improvement ). Lore and Canon guidelines made ready to guide the Player Creators.
* Collaboration Repository (Web-based system) made operational and IDEIDE - Integrated Development Environment Tools made to work properly. Forums and other communication facilitating systems operational.
* Standard NPC interactions ( Shopkeepers/City-Officials/Murderous-Splicers ) defined and built as Templates, and tested for adequate/flexible behavior/operation ( facilitation of 'Personality' details will be added subsequently ).
* Extraction/Conversion Tools/Process for 'Legacy' BS1/BS2+MP/DLC content proofed ( very specific to that existing data ). IDE Tools made to work for a MASS 'slice and dice' recycling process - to then ne Importing into the MMORPG's Data Formats.
* Seed Data for MMORPG Game World is planned ( What Rapture parts/places/locations will initially exist, and what will be left for Auto-generation later).
* Auto-Generation mechanisms created and testing ( to be ready for mainstream application as a significant element of the MMORPG ).
----
Alpha Phase ( Proving the Collaboration System process works ) :
'BEAT the system into SHAPE' before large amounts of Assets get created ( and would need tedious reworking/retrofitting (and retesting) to patch to work with any significant changes ).
* Selection of Alpha Testers ( Some vetted Just like Ryan would have 'vetted' who could go to Rapture. Players selected - preference for those with abilities/inclination to test/identify/report problems effectively ).
* At this point the Company developers have sufficient parts of the Client/ Server/ Tools working so that Players can start trying to use them to do the Player-done Creation Process, within a real Game environment. Pre-made Asset Examples provided to 'play with' - get the learning curve started - knowledge base of early users to adapt/optimize process for later Creator users.
* Restriction of Test Player use to functional testing ( not creating additional Assets for the game yet ). Players should be able to 'play with' Example Assets, and have them applied to (run on) a Test Server where they would operate correctly. A Sandbox World setup as a stage to test the future creations on.
* Documentation is proofed to show it will be sufficient for Player's need (understandable and complete). Additions to be later added via the Community Process.
* Working the 'bugs' out of the whole Collaboration Process : Players use the Process to demonstrate all the features work ( process of : setting up "Projects", creation, submitting, vetting, adding to active game system ). Needed Adjustments get made.
* Alot of heavy developer debugging will still done at this point. Players to have clear understanding this is a system 'still under development', and they should look for and report all problems. AND the Company quickly fixing the problems.
* Test Servers will (as usual) turn-over frequently as new code/template versions with major fixes are put in. Automated Confirmation Retesting applied against the updates done before more general use.
* Work done with the more complex Asset aspects ( scripting, prop templates, NPC data sets/templates, Quest Templates )  which would thoroughly exercise the Server program code and Client mechanisms. More sample Assets would be built just to prove the various parts of the scripting system works with them. These Generic test Assets can be used later to Retest the system after fixes have been made ( this Auto-testing Set will be continually added to and improved ). More detailed combination testing of ALL the Game Mechanics ( interaction of objects/environment/Players ) would be manually done.
* Many Game Mechanics/other general problems WOULD turn up and be fixed ( best done BEFORE large numbers of real Assets need to be reworked/retrofitted - for any fundamental changes ).
* Preliminary REAL game Assets extracted from 'Legacy' data to be tested by Alpha Test Players to prove that extraction process works.  Deficiencies get fixed and then act as a 'stage' for more complex testing ( missions/quests/auto-generation/etc ... ).
* Placeholder 'generic' objects defined to use in combination testing -- where you can setup a scene with all needed Assets, even though they don't have all the final detailing yet ( ie- a generic human figure that can do animations and 'reacts with' most of its default behaviors/reactions ). Generic containers, vehicles, building sections, weapons, machine components, etc ...
* An Initial (Existing) City layout planned/reviewed/improved ( Seed data defined for Auto Generation extensions ). Initial Production game Player activities to be targeted and facilitated.
* Alot of planning for Beta phase, with priorities for what Assets will need to get built up.
----
Beta Phase ( Build the initial game Assets, and testing functionality in the gameplay environment ) :
* Creation Tools are ready for Creator Player's use
* Beta Testers ( Players selected - for general creation skills ) - Opening up to larger number of Players to help start building the initial start game assets.
* Build up the Collaboration community - creators, advisers, vettors, collaborators ( most probably will be bugs to be worked out and for the many players to 'train' to use the collaboration mechanism ).
* Develop Collaboration experts - members of the player community who will be responsible for the 'peer review' ( and get the Company personnel who will do the Official Inspections trained up also )
* Test Servers need to be fairly stable - but still likely to face major 'fix' and improvement changes.
* Company employees start tearing apart the existing 'Legacy' BS1/BS2/MP/DLC data to for conversion to 'objects' and farming out to players who will do the rework into MMORPG data.
** Work Slicing-up existing buildings ( BS1/BS2/MD stuff ) up, and converting them to work within the MMORPG's new modular system.
** Props, lots of prop objects ( extract from the 'levels' data ).
** Create the object state ( new damaged/grungy ... ) variations -- The Textures/3D-Meshs for all the Prop objects (and sub-components)
** Rework human figures and add more action animations ( Citizens don't physically act like Splicers too much - a greatly expanded palette of actions )
** Citizen NPC Behaviors (living their lives - or at least appearing to) built using generic templates.
* When the REAL assets are built they can then be placed in a growing World ( which allows further real additions using those assets ). Placeholders can be replaced as the assets are built.
** Build initial sets of quests ( even 'missions' of typical MMORPG quality would be a start ).
** Testing the economy system and all the fabrication/construction/shop/'Team' interactions.
** Verify all the player 'helper' interfaces
** Exercise the Auto-Generation ( both the small 'room' type variations but also the city expansion mechanism ) as REAL Auto-Generation Templates are built to match the Seed Data requirements.
* Continue until the Existing City layout and dependent assets are ready.
----
Gamma Phase ( Mass Testing of game - normal 'beta' test ) :
* Most initial game World data is ready ( missing bits will be built and added if needed )
* Servers loaded with start/release data state.
* Extended Server loading/stability/stress tests done
* Large numbers of players running real game play activities ( playing the game ) on the Test Servers.
* Full game world operation to test all aspects ( do test of process of patching new assets ).
* Late fixes (if any).
* Collaboration Players get head start on new asset submissions ( new Assets submitted when game is operational ). More extractions from old data as well as new creations.
* All Servers readied for Game-Start.
* Planning for first post-start game expansions being made ( more props/locations/Quests ... )
----
Game-Start :
* Rapture Rises Again...
* Company has saved 'oodles of money' making the game and have a modular/auto-generation/collaboration system that can be used for creating additional MMORPG games ( and much of it usable for Solo games as well ).
* Everyone needs to keep an eye out for loopholes and deficiencies in the game ( Players are creative and will do things testers never think of ). Things that can cause major unbalancing of the game have to be handled immediately.
* Company does some work on New Content, also guides 'Player Created Asset' Collaboration to 'flesh out' more game play.
* Lots and lots of new PLAYER CREATED game content starts pouring in to expand the game.
* Game industry says 'Whoa, Wish we thought of That !!! ' ...
* "Profit !!!" ..."Profit !!!" - The South Park 'Underwear Gnome' Joke ...
----
----
----
== Required Components of the Collaboration/Publishing/Vetting System : ==
* IDE ( Integrated Development Environment ) the basic tool used for Player Asset development/creation.
* Asset Creation tools to create/modify ALL assets with all data -- in correct game formats. Importers for external formats used by third party tools.
* System to make requests for specific assets needed for the game ( either variations or to fill a specific game function )
* Guidance from Company/Player experts as to what object types should have priority to fill gaps in available types ( or for consistency of coverage -- Do we need a twentieth new 'Chair' when there is only 2 types of 'desk' and one 'couch' ?? ) Extra incentives may be needed to help fill 'gaps'.
* Forums for discussions between players on the entire collaboration subject ( including testing procedures ) - some people are good at thinking up good ideas and others making the ideas into something useful. Easy/effective communications are central to success of the whole mechanism.
* Repository of existing game assets/templates are to be available to use as starting points for creating similar assets.
* Easier than starting from scratch (saves alot of work). This facilitates Upgrading of existing assets.
* All accepted assets are open for inspection and cloning ( there is no locking-down, if someone is capable of making significant improvements then that is good for the game ).
--- --- ---
Process Security :
* Certain Identities may be established by a proper certificate authentication ( via IDE used for control of all official Submissions ) that access the final decisions ( ie- the go-ahead to pass an asset to the company ... )
* No existing assets can ever be lost/damaged by defective/disruptive submissions ( the usual feature of a source control system ) 
* Forums would have the usual login required for postings, to control Spambots and disruptions caused by the usual mentally deficient/defective people. Moderators would keep the Forums 'cleaned' of irrelevant posts.
* Company would be required to supply sufficient secure backed up server resources for ALL the asset data  repositories.
* Secondary Collaboration : Some groups of Player might feel that they can do a better process collaborating and could set up their own communities to confer/design/create/vet assets.
* ALL Assets still have to go thru the official process ( peer review and company acceptance )
* Sub-communities with goals of 'localization' ( translating to different languages ) would be likely. Such tasks might be quite significant ( think of all the text translations for every NPC quip and statement and quest story, let alone any voice recording and sign translation )
--- --- ---
Documentation of All Asset Template Definitions ( game mechanics related )
*Must contain all attributes needed to define this assets use/function/behavior.
*Examples of template use help alot with all the many attribute even ordinary objects ('the chair') have ( saves time  to know which ones to leave 'default' ).
--- --- ---
Mechanism to Assist in Passing Partial Works Between 'Creators'.
* Many Asset types which produce in an Object Instance are actually made up of many simpler component Assets.
* The whole cannot be activated on any server until all the required pieces are present ( They have to be grouped together on one IDE so that the automated tests and packaging can be done correctly ...)
* All IDEIDE = Integrated Development Environment Assets are exportable, and the data files are transportable to an IDE on another machine.
* A good Search mechanism to find similar Assets or Links for documentation for Asset proposals and for any already-in-progress asset projects ( so the user can see if someone else already working on the same idea ).
* Post and Search mechanism for 'Looking for assistance' by Players who need collaboration to finish their Asset.
* A Method for Feature Request (to game company) for game mechanics addition/bug fix
** With proper description and explanations included and with specific details of what the change will affect
** Backwards compatibility is a key requirement for all game mechanics changes ( to minimize rework of existing Assets ).
* System of Escalating roles privileges for successful creators.
** After a creator has proven ability on simpler tasks, then more complicated assets are allowed to be submitted. ( This helps cut back on poorly designed/executed Assets that WILL get rejected and thus waste other peoples time and effort ).  Users who continue to submit garbage need to be identified so they can be filtered/blocked/marked so as to not waste other Players time/effort.
* 'Dif' Tools to highlight the 'changed' part of Asset data from the previous version - helping reviewers to zero in on what needs to be tested/inspected ( if it is assumed the old version worked correctly, any changes would be the source of defects ).
* Proper Attribution of Credit for the work done to the Player who did it ( design/creating/vetting/bugs/upgrades )
** Somehow enumerate 'effort' if multiple collaborators (see 'score' below') were involved.
** Often there are multiple sub-assets done by different creators or the same asset is passed thru several authors ( ex- basic creation and then polishing ).
* IDE for player ( Client program/system of the creation system ) to handle the transactions facilitating the Collaboration Process :
** Talks to Server collaboration/publishing system ( automates routine actions, preferences, etc ... )
** Lists the users ongoing projects (selection of current project)
** Lists states/schedules of the users project(s) ( see the process details below )
** Access to common tools ( various editors /code inspection/test tools/ validation tools/simulators/etc ... )
** Keeps track of checklist for submission process ( including interactions with community reviews )
** Logging of project status changes and feedback
** Asset Search front-end ( including search wizard taxonomy helper )
** Notifications (mail tie-in) system tracking of project(s) progress
** Assists with Downloads of various info ( assets/templates/documentation )
** Paperwork fill-in helpers ( for various required descriptions/documentations/notes )
** Collaboration Assistance tool ( posting to seek/accept/coordinate collaborators - sub-projects ). Various parallel notifications to the people working on a project.
** Integrated Debug Tools with Ability to replay recorded 'bug evidence' of specific cases. Recreation with appropriate  simulation tools.
** Posting mechanism for the Pre-submission/Peer Review phases ( can run available validation tests and packaging )
** Links/Wikis to Web-based information - Forums/FAQs/Documentation/Demonstration sites
** Largely automatic ('push of a button') Backup of IDE data (local and/or to server) -- nothing is worse than losing  days worth of work when you computer craps-out.
** Note - Many of these things could be done manually but as time goes on ( hopefully alot would be spotted in the pre-release activities ) tools will be made more convenient and routine/frequently used mechanisms streamlined/auto-assisted. Ease-of-use is important to a system use by a wide audience, who don't want to fight with the interfaces everytime they want to get something done.
** Quickload feature for test servers to allow the IDE to upload new test assets onto a test server ( and from there  parts onto a Client ) so that they can be tested in situ. More complicated assets require groups of other assets to interact with ( including NPCs and Player avatars ) so an 'arena' style instancing system would be done.
* Inspector (Privileged User) additional IDE features
** Listings of pending 'inspections' and their status (incoming list)
** 'Expert' commenting/markup Tools ( can record 'bug' evidence for problems found )
** Runs various inspection tools/viewers/editors/simulators/commentators etc ... The Tools are rigged up to run the data packaged by the author with the least amount of effort and similarly the review is packaged and sent back.
** Votings ??? ( some Asset reviews are via consensus )
** Review checklists ( inspection tasks are tracked for each reviewed asset project )
** Messaging system for consultation with other 'Inspectors' ( used to send partial Objects to other 'experts' for their opinions )
* Test Servers with the Developer Test Tools Enabled for common users.
** Allow players to force situations they want to test - to allow them to run Scene Definition Scripts ( Tools to help with this ) to set up quite complicated pre-defined situations.
** Debug Info from Objects and being able to view/inspect internal state.
** Full Server code is probably too complicated to be run on a Players machine ( besides being proprietary ) -- So 'test Servers' need to be available quite early on to allow players to test their more complicated asset creations ( ones with  Game Mechanics interactions in the scripts and intra-NPC behaviors ).
** Since the 'Instance Bubble' mechanism exists as a normal feature of the Server Architecture, many small independent 'Sand-Box bubble instances can be used by players for their testing. Cloneable 'typical' scenes would be available to streamline context/situational testing.
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
==Object Instances Capable Of Being Created 'On-The-Fly' ( via auto-generated using the Template Assets ) :==
* The 'parameters' come from the context the Object is being placed in and also are specified from the setup Script that is defining all the Objects that are to be placed in a 'scene'.
* All details are resolved/finalized/fully-built so the object can be used (activated) in the game.
* NPC/Splicer object instances built to appropriately fit a specific situation ( the Player just walked in on )
* Prop instance 'dumb' object that is used to populate the game world as a detail.
* Quest Instance (product of a Quest Scenario Template being run):
** Represents an active quest associated with a player ( its data will control the quest state, specific details )
** Quest Control Script was defined/parameters-set to customize it to the current situation
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
Collaboration Process Aspects:
* Open submission of Upgraded/Improved Objects ( any existing asset is available for potential upgrading by players who think they can do better )
* Open submission of totally new assets ( something that doesn't exist or is significantly different )
* The Collaboration Process is setup to minimize rework ( immediate rejection of defects instead of wasting further time on something that will have to be redone again later anyway ).
* Creation is to be made as simple as possible for players (with the least skill necessary).
* A Collaboration Process is set up to make use of players for vetting Assets before it goes to Game Company personnel ( much  of the process would have well specified acceptance criteria, with early tests by automated methods to cull bad  submittals )
* Requires EULA/whatever that boilerplates 'Player Created Assets' are FULL property of the company once submitted.
** Covering final right of company to accept/use an asset in the game worlds
** Usual warnings about players submitting incorrect/inappropriate/plagiarize/copyright-infringing
** Company will remove any bad/invalid assets that slip past vetting process
* Requires system where NO submitted info is ever lost. Proper backup and versioning will be done. Incremental  work/improvements of assets can cumulatively achieve optimal assets.
* Dependency on tools specific to game data format and importation for formats from outside tools (standard formats).
--- --- --- 
The Game Company Will Supply Many Significant Tools to Help Streamline Creation Process :
* 'Mod' tools are one of the extra costs that often make a good 'Player Created Asset' system prohibitive. Open Source tools (and modular sub-tools) will be used when possible ( and cut that expense ).
* Tutorials for common tool usage are very helpful (an understatement). Some things still take skill (like 3D shape editing) and others are just mysterious until player shown how easy is to do.
* BioShock Rapture Official Lore/Canon specifications/guidelines - required for subject content for assets being created.  Needs to be well detailed to help minimize submission of inappropriate assets. Updated/corrected as issues 'not covered' come up.
* Technical details for game mechanics interfaces (for scripting) would be specified properly to allow players to code effectively, as well as with mechanical correctness. Especially important for existing 'Templates' that perform things that DONT need to be coded again.
* FOR EVERYTHING INVOLVED ---> Forums to address definitions/misunderstandings/corrections to Canon/Lore doc. With standard User registration security for access to cut down spammers etc ... Moderators to keep postings within the appropriate subject
* Catalog/DB/Search taxonomy system for defining asset flavors/templates -- for easy reference of available assets to facilitate upgrading or variants -- using existing assets as a starting point.
* Need tools that do a 'dif' to highlight changes from a previous version, to make it easy to see what has been changed .  Tool for reviewers and inspectors (for vetting to concentrate effort).
* Contests and Challenges can be offered to encourage development of 'needed' assets ( to balance out work done on more 'popular' Assets and to encourage more complicated submissions ). Many player creations require supporting assets to 'round out' a proper game experience. - ie- a new boss with lair/location/props/etc ... would be good to have several quest/mission scenarios added to interact with the 'Boss'. Asset Creators would be 'guided' into generating these associated details.
--- --- ---
Goal - Minimize Asset Memory Requirements and Processing time for Behaviors : 
* Possible/preferred reuse of existing attributes/data ( textures/sounds/scripts etc ... )
* Tutorials showing how to minimize resource ( memory/CPU/Rendering ) use for final objects - compacting textures, AI  optimizations, etc..
* These things have a major impact in a game that has so many interactive objects around the players)
* Will have FAQs and Examples of efficiency improvements of all kinds, showing common mistakes, best practices, etc...
* Guidelines for how much resources (CPU/Memory/Rendering) an asset should consume ( There are maximums that the automated tools will check for )
* Standard limits might be waived if no way is found to otherwise fit a 'superior' asset.
* Author ratings might be (re)awarded for assets that come in well under resource limits and with the asset still being acceptable ( this might be hard to judge ).
* Automatic tools to measure and report resource usage ( data counting easy, rendering load test a little more complex )
* Techniques for minimizing Resource use should be documented and recommended to authors.
* Templates should be written well optimized as they get reused over and over ( and add any inefficiency to object created  with them ). Same should go for all documented Examples that should always exhibit 'best practices'.
--- --- ---
Proper Handling of Major 'Game Mechanics' Changes ( Fundamental way the game code works ) :
* ANY Changes to game mechanics MUST be well documented and announced/made available to community WELL in advance ( and communications posted as to impact and possible effects on existing Assets ).
* Library/Docs Pre-distributions of pending changes would be made available to authors, etc...
* Changes may cause rework of existing assets ( automated retesting can detect any catastrophic effects of any change )
* Prefer to minimize this and get most fixing/extending done in Pre-Release period. Often such changes will directly effect - Templates internally use changes ( not requiring rewriting objects that use them ).
* Mass Testing of all game object types can be done using the automatic tests (as a start) with minimum human work.
* Most new object attributes won't cause issues, splitting/specializing attributes CAN cause many issues. Default behavior attributes should make least difference in behaviors. Author of assets should be notified to allow them to retest their own.
* Game mechanics must be 'versioned', so that new changes can be pretested by the collaboration community. Test Servers with the new version levels would be deployed. Client simulators would run ( the version patched Executable and Assets ).
* Authors with asset projects affected by proposed changes may be automatically identified ( traced by the library/templates their assets make use of ) and notified to hold work on their assets until all the Game mechanics changes are tested and accepted.
* Players can submit defect reports against changes to Game Mechanics ( perhaps a mechanism can flag all things that make use of a particular feature that has had changes, and certainly any Auto-Test mechanisms can be run )
* Completeness - Does it accomplish what was defined to do ( a missing endcase, etc ... )
* Not being backward-compatible - It will break existing Assets( when it should be designed not to )
* Design-Error - Serious missing part of design or execution does not match the original change request
* Breaks the System - Defective. Detected either by Automatic or Manual Regression Tests. Asset scripting is NEVER supposed to disrupt the Servers, but that is achieved by the Server code be designed correctly.
--- --- ---
Let's Make A Door :
* Largely 2 dimensional ( most 5-year-olds could do a passable one - the shape on a Basic Editor )
* Sometimes differences between 'inner' and 'outer'
* Can be 'textured' with available base surface types ( and colors, etc ... ).
* Cutout transparent component of inset window panes.
* Shiny handle/frame/control features ( metal effects on a separate 'surface' plane - with '3D' automatic extrusion adaption )
* DOOR activation part of a Standard 'Door' Template ( animation, locks and such )
* Attributes for damage/destructibility - Standard class sets already defined
--- --- --- --- ---
.
.