FANDOM



Sitemap


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

'Player Created Asset' Collaboration System -- Part 2 - The Collaboration Process :

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


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.


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


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 competancy 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  handluing 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 whats 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 parameteres 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.


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


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 whats involved in creating THEIR Asset. Templates especially can prevent  them from 'reinventing the wheel'. Similar assests may already exist that aleready 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 subcomponents likely will have to wait for other  subcomponents they have dependancy on).

--- - Some Assets like tetures 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 dependant 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).


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


Player performs the Creation Work :


- Player now creates/modifies Asset (building either alternate variation of Template or an exact 'instance'. If multiple  'collaborting' Authors then each creats 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 includes reference to any official Asset (Template/instance) used  as starting point - if an 'upgrade. What makes this Asset different from all other sassest 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 (player IS expected  to pre vet 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 knowledgable 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 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 exercicing 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 excludedas that requires full Server functionality NOT available on the IDE)


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


Initial Submission :


- Submission Packaging automaticly done by IDE ( failing Format test with abort process)


- Player fills out submission 'information' (checklist of required info of a sumbission)

--- - 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 prefered 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 dependancieson other Assets), the  description needs to explain all dependancies. ONE player does the official submission - requiring all the seperate 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 incomming 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  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 sumbission is dependant 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 dont 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 migh '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' inprogress 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 automaticly 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 unacceptible to go furter 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' tools run against the rejected version to highlight what was fixed.


- Pass - Asset was found acceptible to pass on to next phase of official inspection (to the Player Expert Inspectors)

--- - There may still have been Suggestions of improvments(that werent 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 (Player Vetting phase) :


- 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  Sumbission 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 independant 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  dialoger 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 empy 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 specificly 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). Patchnote 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 correctluy 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 dont 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 timeperiod, a Judge assesses all review results/commentary/opinions/autotest 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 competant 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 have a reason given by the reviewer - Any reason for rejection should be  documented so as to be obvious and prefereably include recommendation of how it should be fixed.

--- - Author who feels they were rejected incorrectly can apeal 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 abililities. 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 'Offical' 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 (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 unforseen 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 Patchnotes 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 - dont waste company personel  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 SUPOSED 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 Community)

--- - Will also flow back to player 'Expert' Inspectors who 'signed-off' on the Asset (they need to know what went wrong  - why they didnt catch the problem)

--- - If this Asset is part of dependancies 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 players agame 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 (Templates in  particular).

--- - Significant new additions would be announced -- like expansion of the 'Outside' areas that can be explored or a new  'video' recorder mechnism 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)

--- - Dependancy - 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 dependacies met with Assets also currently deployed.

--- - Distribution mechanism for Client side data - some published on-the-fly (small or locallized 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 put into Clients Asset 'Atlas'  for future use. If Asset is 'activated while player is online any 'Patch' Assets will come in this way also.

--- --- - 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 doesnt 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 console systems handle background disk operations while the Client is running the game  their Revision Set data may have to be all via a Client Restart type patch to the client "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 dependancies 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 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 the 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  (Im appalled sometimes at how long even simple defects are allowed to remain in some MMORPGs and it makes you think that  the company really doesnt 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 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 automaticly) so that THEY (the player) doesnt 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 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 teh '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-dependant 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 be adjusted (the Company usually has to creat a script to make the appropriate  adjustments and the Server sweeped for objects that used the Deactivated Asset -- which takes alot of work).

---  Patching mechanism (streaming) will direct Server and Clients to modify their Asset Dictionarys/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 automaticly 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 specifily 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 Inspectrion/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 DONT realize and they skimp on proper QA).


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

---  Preferably with a Test-rig script to demonstrate the situation in which the error occured 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.


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


In the Games 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 can 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 projects than starting them and vice versa). This allows partial efforts  made by players can still be used to eventually produce a game useable 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.


---


You look at this whole process and say 'too complicated, it will never work'. It would take some work to create (Ive  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).


---


.

.

.

.

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.