FANDOM



Sitemap

'Player Created Asset' Collaboration System

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 arrangements useable  in 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 for use in the game.


Web based tools: Much 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 can go a long way to improving 'creation' efficency (Ive seen this done  for games like Neverwinter Nights and many modding tools for many other games). Many times its just one player creating a  walkthru on how to use a tool that will get other player past a steep point in the learning curve.


VERY Important aspect - is 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  elaborated on as the project moves forward (and clarifications needed).


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

'Help Us Build Rapture' - Company getting Players to assist in some of the initial pre-game starting asset data :

- Development Phase :

  • Mostly Company work.
  • Basic templates for asset types complete. Behavior scripts developed for NPC and SPlicers.
  • Game engine operational (Server and Client working as designed) .
  • Developer testing of proper functionality made and confirmed (minor problems identified for further fixes)
  • Asset (all flavors) tested to prove they work. Skeletons for quests and more complicated assets test.
  • Company gets ALL the creation tools beaten into shape (better to find the deficiencies early) - player used tools  need a bit more polish and 'bomb/idiot-proofing' than company developers would require.
  • Proper documentation, tutorials, and examples written for Player use (Some players may be selected for Documentation  review). Lore and Canon guidelines made ready for players.
  • Collaboration Repository is operational and IDE tools work. Forums and other communication systems operational.
  • Standard NPC interactions (Shopkeepers/CityOfficials/Murderous Splicers) built as templates and tested for adaquate  behavior ('personality' details will be added later).
  • Conversion tools/process for 'Legacy' BS1/BS2+MP/DLC content proofed.
  • Seed data for game world is planned (what parts will initial parts will exist and what will be left for  auto-generation later).


- Alpha Phase (proving the collaboration system process works) :

  • Alpha testers (players selected - prefer those with abilities to test/identify problems )
  • At this point the company developers have sufficient parts of the client/server/tools working that players can start  trying to use them to do the creation process and make them work in the game environment.
  • Restricted Player use to functional testing (not really creating assets for the game yet). Players should be able to  create assets and have them applied to a test server where it would operate correctly. Sandbox World setup as a stage to  test the creations on.
  • Documentation is proofed to show it will be sufficient for Player's need. Additions added via the Community process.
  • Work the bugs out of the whole Collaboration process - Players use the process to demonstrate all the features work  (setting up projects, creation, submitting, vetting, adding to active game system).
  • Alot of developer debugging still done at this point. Players understanding this is a system still under development  and they should look for and report problems.
  • Working with the more complex asset aspects (scripting, prop templates, NPC data sets/templates, Quest Templates)  which would exercise the Server code and Client mechanisms quite a bit. More sample assets built just to prove the  various parts of the system work with them. Generic test assets can be used later to retest the system after fixes have  been made. More detailed combination testing of Game Mechanics.
  • Many game mechanics/other general problems would turn up and be fixed (better before large numbers of real assets  need to be reworked - due to any fundamental changes).
  • Test Servers will (as usual) turn-over frequently as major fixes are put in.
  • Preliminary REAL game assets extracted from 'Legacy' tested by players to prove that extraction process works.  (deficiencies fixed) and to act as a 'stage' for more complex testing (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 dont have all the final detail yet (ie- a generic human figure that can do animations and reacts  with most of the default behaviors/reactions). Generic containers, vehicles, building sections, weapons, machine  components, etc...
  • Alot of planning for Beta phase with priorities for what assets need to get built up.
  • Seed data defined and existing City layout planned.


- Beta Phase (build the initial game assets and test functionality in game environment) :

  • Creation tools are ready for players
  • Beta testers (players selected - 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 personel 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 stuff) up and converting them to the new modular system.
    • Props, lots of prop objects (extract from the 'levels' data).
    • Create the object state (new damaged/grungy...) variations -- the textures/meshs for all the prop objects (and  sub components)
    • Rework human figures and add more animations (citizens dont physicall act like splices so much)
    • 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 dependant assets are ready.


- Gamma Phase (mass testing of game - normal 'beta' test) :

  • Most 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 saves 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 useable 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' collabortion 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...


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

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 avaiable types (or  for consistancy 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  offcial 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 deficients. Moderators would keep trhe 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 offical 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 assets that result in a 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 don ecorrectly..
  • All IDE assets are exportable and the data files are transportable to an IDE on another machine.


- A good Search mechanism to find similar Assets or linked for documentation for asset proposals and for any in-progress  asset projects (so 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 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 assest 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 highlite the changed part of asset data from the previous version - helps reviewers zero in on what  needs to be tested/inspected (if assume the old version worked correctly, any changes would be source of defects).


- Proper attribution of credit for the work done (design/creating/vetting/bugs/upgrades)

  • Somehow ennumerate 'effort' if multiple collaborators (see 'score' below') were involved.
  • Often there are multiple subassets done by different creators or the same asset is passed thru several authors (ex-  basic creation and then polishing).


- IDE for player (client of 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)
  • 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 convienent and routine/frequently used mechanisms  streamlined/auto-assisted. Ease-of-use is important to a system use by a wide audience, who dont 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 (priveleged 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 consensus)
  • Review checklists (inspection tasks are tracked for each reviewed asset project)
  • Messaging system for consultation with other 'Inspectors' (use to send partials to other experts for their opinions)


- Test servers with the developer test tools Enabled by common users.

  • Allow players to force situations they want to test (allow them to run Scene Definition Scripts to set up quite  complicated situations).
  • Debug info from objects and being able to view internal state.
  • 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 independant  'SandBox bubble instances can be used by players for their testing. Clonable 'typical' scenes would be available to  streamline context/situational testing.


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

Asset types:

- Basic Script code fragment (converted to bytecode) - logic and calculations and actions that can use and change an  objects data.


- Textures for objects - 2D color pixel map - skins for 3D meshes, 2D flat surfaces for signs and 'decals' and particle  sprites and 2D/isometric objects for Tablet Mini-games and symbolic icon interfaces.


- Shape Meshes -3D definition of points and triangles defining a shape (objects may have more than one mesh - base  object, deformations and subparts for fly-apart breakables)


- UV mapping for meshes against specific textures (used to map a texture over the mesh - 'skinning') . Same UV set may be  used on different textures that represent object state (dirty/clean/broken/scarred/destroyed/burnt/etc)


- Bump Maps for Mesh/texture combination (used to simulate detail shadows that which vary depending on view angle)


- Terrain Maps - large 2D grid mesh that represents single surface terrain (like the seabed that the buildings will sit  on)


- Navigation map (nav mesh) for 'Building Block' terrain :

  • Data that controls allowed movement paths - simplified from the shape mesh. May also be used for collision testing.


- Building Block template - a section of interior terrain (buildings and structures) defining floor/ceiling/wall  positions and openings and places where structural sub-components go (destructable interior wall sections and drop-in  'rooms'). Surface profile data indicates possible adjacent Building Blocks and utility connection matchups.


- Figure (human form) -- also for animals (cats, fishes, etc..) :

  • Mesh shape definitions of the 25 (or so) body 'parts' that move independantly on a human figure.
  • Each figure 'part' is independant object (with mesh/UV data), usually share a texture.
  • Clothing overlays allowing substitutions


- Animations for Human Figures :

  • There are hundreds of different Standard motion/movement actions performed by humans (all the parts moving in  concert)
  • Specific game figure actions play sequences of these movements
  • Animation sequencers - movements often have variations depending on results of actions or independant external  effects applied to the object (also syncronizations with sound effects, etc..)
  • 'Emotes' are usually simpler human animations of gestures.


- Animations for 'Props' :

  • Generally simpler mechanical actions for objects that act out their function (movable sub-parts)
  • Usually are repetitive/cyclic/reversable but can have multiple states (like off/on/fast/slow)
  • Can behave differently depending on object state (normal, damaged, wrecked) or being affected by external effects  (burning/shocked/etc..) Script logic controls movements and synchronizations (with sounds etc)
  • Physics engine does 'flying apart' of sub-components and collision animations (based on objects attributes) and the  various special effects like 'smoking' or other visual effects (synchonized with appropriate sound deffects)
  • When objects are 'repaired' their appearance is changed to the new state (which usually has a different visual  look). For some objects this may be a gradual transformation. Scripting to control fade-in/out and other effects would be  used to present a proper visual transition.


- Sound Effect Recordings :

  • Usually short and often cyclic (played over and over)
  • Different sound effect corresponding to object animation states mentioned above.
  • Effects applied against an object usually have a sound effect (and alternates) - like a bullet ricochet or a wrench  hitting a stone wall).
  • Incidental music might be used for things like combat or by quests or triggered by situation (players 'spidey  sense')


- Voice recording -- practicality says that these be minimized as they take up alot of data space and loading times and  should be short and reserved for lead-ins OR parts of staged presentation where they can be downloaded ahead of time  (like in a Flashback instance).


- Video recording -- simpler frame oriented animation boards (like the plasmid adverts) if not actual streaming video  (black and white for all those old 50s TVs around Rapture).


- Dialog Tree ('canned' interactive selection and response used by Vendors and Quest-giver)

  • Its very possible that EVERY NPC in Rapture may be able to have a basic dialog capability (alot would be shared  'defaults' with other parts customized for that specific NPC).
  • A 'Stage Direction Editor' would be used to compose any movements/gestures etc.. the NPC would make in the Dialog  (and even can choreograph what the player does in response - like the NPC handing an object to the players avatar and the  avatar doing the correct hand animations). This tool works at a high level and leverages off 'normal' pre-defined  animations/behavior responses instead of having to specify many tedious raw primitive animation/sound playing details for  every bit of whats created (Ive seen more primitive editors like that and you pretty much had to a programmer to do much  useful with it).
  • Spoken Text of course makes up alot of the Dialog Trees presentation, but even that can have 'substitutions'  directives within it (ex- NPC says: "Good Morning Mr $$PLAYERS_NAME_HERE$$, what could I help you with" ... to fill in  situational details into the presented text auto-magically).


- There will be alot of media created by players :

  • Documents containing pictures, text, diagrams, signs, links) which could make use of common HTML type tools to  produce (and open source libraries for the Game Engine - why reinvent the wheel...) for 'Browser' type functions. ---   All sorts of ingame media assets (bulletin boards, newpapers, pamplets, books) could make use of simple publishing  tools...
  • All assets would be limited to IN-GAME sourcing to prevent inevitable links to outside rubbish the game shouldnt be  contaminated by.
  • Alot of Company produced assets would use the same mechnism (ie- online help, hints, patch notes).


- Object Template (simpler ones for 'props', more complex for NPCs and 'quests') :

  • Used in the Auto-Generation mechanism to create data for an 'Instance' (active object in the game world)
  • Can be simple (a chair) mostly passive or extremely complex (NPC needed for a quest ex- a Boss) actively interacting  with its environment.
  • Attributes - data defining an object and its initial state (a variable set of data) Attributes include pointers to  other templates that in-turn would be used to create their aspect of the object.
  • Optional sub-assets (a machine made up of multiple parts that are assembled together)
  • Parameterization definition - supplied to be used to control Scripts that produce object variations.
  • Scripting to use parameterization to modify the base information to create variations, or to make the object fit its  environment (ex - adapt a local coloring 'theme', to adjust its positioning in respect to other objects)
  • Multiple templates may be called to create one object - to combine the data generated for different aspects.
  • Randomization of an objects attributes following templates guidelines


- Object Instance - fully resolved object with all details set/finalized -- some objects have to be VERY specifily  defined to make sense (and creating a program to do this is excessive work when it is not needed).

  • Attributes - includes set of data with pointers to common/shared assets and local customized data
  • Can be dropped directly into the Server World data.
  • Can still have scripting to have the Object adjust its placement in the World or create relations with other objects  in its Environment.


- 'Prop' Auto-Generation Template Scripts (scripts and data called to create a 'prop' instance):

  • Parameters are supplied specified that will control variations of what is build (can also control which of several  templates may be used for variations).
  • Environment placement position is supplied (so script logic can analyze and adjust things)
  • When is run it generates an Object Instance for a 'Prop'
  • Object can form itself to a requested 'state' (ie- damaged) and set its attributes to match whats proper for that  state.


- 'NPC' auto-generation Template Scripts (scripts and data called to create a 'NPC' instance) :

  • Goes beyond whats done for a 'prop'
  • A more complicated "Object Auto-Generation Template Script" includes NPC's behavior formation of reactions and  active AI with preference/tendencies/personality variations/randomization).
  • 'Fitting' - adaption to the Instance's proposed location (ie- a Splicer has a lair and props/equiptment and maybe  associates NPCs it allies with)
  • Associated props and inventory would be created to go with the NPC.


- Auto Fitting/Adaption scripts :

- Used by City NPCs and Splicers (and simpler objects) to fit themselves into the situation they are placed into. The  'aut-generator' uses invokes these scripts when creating new detailed terrain. Mechanism like this can be used to  'organicly' grow alot of the Initial Startup game data (saving alot of Dev work). Game developers can then tweak the  result afterwards to fine-tune/correct for the exact settings of the initial game World).

- Example - a generic 'citizen' being manually added to the City. Using scripts, an NPC (already specified/parameterized  to have certain skills) would be created and all its attributes adjusted to its environment:

  • Certain randomized attributes would be set that would shape the NPCs behavioral preferences/tendencies/personality.
  • A set of appropriate inventory and possessions would be created for the NPC (scripts run).
  • Register its ID in the City Database, setup its profession, bank account, skills.
  • Access the job database to setup an appropriate job.
  • If the NPC ran a 'shop' then an appropriate shop location would be allocated and that would cause a 'shop template'  to be run to generate the appropriate type and style and its contents/merchandise/supliers.
  • Would use the housing residence Database to pick a proper free 'home' location for its income level (and  appropriate a residential unit).
  • The NPCs Housing would be setup with appropriate items (via running a housing template) and populate it with the  NPCs possessions (activate more standard fitting and placement scripts )
  • After those were resolved the object would setup a daily schedule to simulate living a life:
    • Going to work/working(actually producing services/goods at the job)
    • Using transportation (pathing) to move home->work->home
    • Secondary activities for the NPCs 'spare-time (if is a 'go-getter' then might have a second job or go do some  'scrounging')
    • The NPC would locate in its environment the services it makes use of (build a list of 'preferred' places it  visits fo various needs)

- Note- all these things are done for City NPCs when the Game World is being initially 'shaped'. But a similar process is  used to on-the-fly add Splicers/NPCs into a newly generated area (when the city is auto-expanded) and also when a new  Ex-Splicer is added to the City's population. Quests instances can have temporary actors added that are'fleshed' ou much  the same way.

- Similarly if the game World changes signifcantly NPCs can have part of the same scripts invoked to RE-FIT (adapt)  themselves to the new current situation. It would be an adaptation feature all 'intelligent' objects would have. - Premade Seed Map (hand built data) for city growth pattern :

  • A Seed Map acts as premade data guide for auto-generation of new areas (and for alot of local filler details built  'on-the-fly', as when closed sections are fully resolved because of player proximity). Example- a sealed-off abandoned  shop is broken into by a player, it was originally left with details unresolved because it was not visible/accessible,  but when its needed the auto-generator was run and finalized details were built for that 'shop' -- which the player would  then see and interact with. Parameters defining that space as an 'abandoned shop' had already previously been stored in  the Database. This saves having Objects/details at a location that might never be visited by a player.
  • Generation of realistic results is rarely 'good' or natural when completely randomized. There are often patterns  things follow - similar/related details that exist in real-life. Making a program do that is extremely hard and alot of  work. Having a developer manually design those general patterns and set them into a 'seed map' database (guiding the  auto-generator) is usually a much simpler solution.
  • Example - design and layout of city streets to match seafloor terrain is actually a significant programming problem  to do automaticly (to have a program analyze it, calculate a solution and build it all from scratch). The street system  crosses the whole city and fits many irregularities (look at the Metro map in BS1  http://bioshock.wikia.com/wiki/Austen_Bathysphere_Map ). It would be hard to get a program to fit this in a  coordinated/cohesive way. SO the company developers would do the anlysis and build Seed Data that would represent a  validly fitting pattern and then leave lesser 'easy' details to auto-generation. The streets, Metro, Atlantic Express,  plaza/building locations, etc ALL have to fit together and are best planned out by hand.
  • The data in the Seed Map is directives and parameters used to run several phases of Asset Creation Templates for a  small section of the World Map :
    • Processing of this phase sequence can be temporarily DEFERRED (as in teh case of a player moving Outside and only  seeing the External appearance of a Building (can actually see many out there) and that part of the building would have  to be built to show the player. But the interior details would not YET be needed and could be 'deferred' for later.
    • Structural building - the large parts of buildings (objects) are created and tied into the other building  adjacent to them.
    • Interior structures - the various wall sections/floors/ceilings that inset within the primary structure.
    • 'Rooms' (preconfigured combinations of wall partitions and other details set many detail parameters specified for  later phases. Some 'rooms' in closed off sections of a builing may have their interior details deferred until a later  time - even when accessible parts of the building are already built fully detailed.
    • Utility systems - piping/electrical coduits, ventalation ducting details are tied together with the systems in  any already existing adjacent builing sections (the damage state of the utility stuff will cause the details to be  formed/applied appropriately)
    • Decorations for wall surfaces/floors/ceiling, lights, machinery, vents matching the parameterized themes and the  damage state of the location.
    • Add appropriate furniture/fixtures and other customizations matching the locations flavor data, all approriately  'fitted' to the walls/floors/etc... All of these also will match the damage state of the location.
    • Occupants - these may be 'deferred' for later creation/activation when a player gets close enough. Local  NPCs/Splicers. These often have their own sets of accouterments and possessions and modifications to the locations they  inhabit (they have their own adaption and fitting scripts). Occupants many be decided by a seperate 'faction' control  system that will decide what spawns are appropriate for the location.
    • If a players are nearby (ie- they are exploring a new ssection of the 'Wild') , then the NPCs will activate and  setup their behavior contrrol data to start acting appropriately to their environment.
  • The auto-generation still handles a huge number of details - but follows the overall cohesive pattern specified by  the seed data.
  • The auto-generation still can do additional 'fitting' and adaption and can introduce minor randomizations to make  things more unique looking - particularly by different combinations/substitutions of compatible .objects.
  • A major advantage is that the auto-generation can generate small areas using those predetermined patterns, instead  of having to analyse the entire city to fit to it properly.
  • Some Seed Maps have 'resolved' locations that are unique - where a fully detailed chunk of the world will be dropped  onto the map from the database (instead of having its details auto-generated).
  • Some areas are partially prebuilt -- like the 'known' areas from BS1/BS2 (ie- Dionysus Park) that are very unique  and specificly shaped structuarlly, but still can have many details filled in automatically (ie- generic trash and debris  damage).
  • More than one Seed Map will exist to define the World
    The Rapture City seed map (contains alot of intricate building/structure/infrastructure details for the main city  complex)
    Seafloor Terrain heightmap (contour map of full World - much larger than the area Rapture covers)
    Sea area seedmap (data for filling in details about what terrain/sealife/wreckage props can be found across the  seafloor terrain) - used to generate details 'if and when' a player goes to each part of it.
    Additional (smaller) Location Seed Maps (same detail level as 'Rapture City Seed Map") but that represent a bunch  of special sites outside the primary city map (like industrial complexs).


Scene Definition Script :

  • Script with a list of directives that run the auto-generator to create terrain and/or props and/or NPCs as a group.
  • Script can call a script that creates a single object, or a Script that creates a group of objects and places them in  the'scene' in the game World.
  • Script also has directives to control where the new objects are placed in relation to each other and 'global'  attributes like 'themes' and other parameters used to shape the individual objects into a cohesive 'scene'. To do that  there often is logic to analyse the local situation so to be able to fit the new object in correctly.
  • The Script can also modify/adjust objects that already exist in a location selected for a 'scene' to match the flavor  of what the scene is supposed to represent.
  • Example - Logic from the Seed Map decides a small Splicer camp site is to be placed in a newly created/detailed  building.
    • Say that 'One lone Splicer' is specified for the script.
    • A location in the new building is Specified (say the top floor).
    • So all the normal possessions a Splicer would have to live and the remains of stuff he would have used after being  there a long while would be generated.
    • The terrain might be 'grunged up' to represent a place someone has lived in for a while (yep, more tandard  scripting).
    • The Splicer itself would be created, with varying tendencies/preferences, and along with its appropriate inventory.
    • The Splicers 'fitting scripts' would be run to have it orient itself in its environment (ie- what its patrol routes  are, and daily schedule - Splicers sleep too). If the splicers behavior has 'a territory', logic woul run and analyze the  adjacent areas around the 'camp' to see what other things the Splicer would interact with (a lone splicer would likely  mostly 'avoid' things).
    • A 'real' Splicer would have to eat, so part of the 'fitting' analysis is to identify food sources the Splicer would  use to survive (rats?). Identifying such and having its routine behavior have it go to that food source (once in a while)  will vary its behavior and location when it might meet a Player (not just the usual MMORPG NPC standing like a mannequin  or walking the wame waypoint patrol path endlessly).
    • Notice - alot of these scripts are fairly generic and would be used for hundreds of other 'Splicers' created for the  game, but each case would be different because it is adapted to its environment. Much of the problem in existing MMORPGs  was that the 'scripting code' was often largely hand crafted for every location/situation. Writing a system of modular  scripts that can be reused to replace the bulk of currently customized scripting can leave alot more resources to  generate better/smarter behaviors.


- Staged 'plays' (something like the choreographed ghosts seen in BS1) :

  • A scripted set of 'stage directions' that control 'canned' actions of the ;actors'.
  • Actors can be ghosts, NPCs, sealife, animals, vehicles, etc...
  • Choreographed figure movements/sound effects/dialog/actions of multiple figures (and props)
  • Can be used for TV commercials/shows/vignettes by NPCs/Dialogs/Quest 'cutscenes'/Flashbacks
  • 'Stage' direction sequences created by an editor (high level) with alot of menu selections of the existing  actions/sounds/movements/synchronization.
  • The play is designed for a known 'stage' layout - either a specific location like the FootLight theater or some  generic location like a street corner (where all the best quests are usually given...).
  • First running a Scene Definition Script would set the 'stage' and create the 'actors' for the choreographed  presentation.


- Quest Scenario Template :

  • A complex template that performs many operations needed to setup/start/run/end/reward a Quest
  • Staging template (run to set everything up) - starts a Quest instance that will run a "Quest Control Script"
  • Location setup (determines buildings/interiors/props needed for the Quest's plot - resolves any variations quest  will have)
    • Running a Scene Definition Script to create the required setting.
    • Can include semi-random placement for involved NPCs and locations (fitting Quest's requirements)
    • Scripts for randomization might have to search for approprate locations (since the city changes as the game  progresses)
  • Props (determine details of objects to fill in locations with appropriate Quest objects in appropriate states)
    • Self-placement scriptlogic for 'auto-scenes' used with auto-generation mechanisms for all the incidental  details.
  • NPC definitions (create any quest related NPCs with behaviors required for the Quest's plot)
  • Text storyline (background details of plot ready to be presented to player - there might be a 'Staged Play' as part  of it)


- Quest Control Script :

  • A Quest is run as a sequence of 'phases' making up the plot, each having its own locations and props and logic.  (player finds the quest, accepts it, moves to a location, interacts, moves to another location, interacts , goes back for  reward, terminates...)
  • Each phase may have its own "mini-plot" control script,l run at appropriate time/circumstance in a plot sequence
  • Can have alot of 'parameter data' set by the 'Quest Scenario Template' into the Quest Instance(dataset)
  • Scripts logic may have a set of plot-tree logic branches to allow for different outcomes (success/failure/partials)
  • Choregraphed motions/interactions of NPCs and incidental occurances get shown to player (acted out)
  • Each 'phase' at determined locations/context where player interacts with the situations defined by the quests  plotline.
    • Can include prompting messages if player is off course in the flow of the quest or ignoring to persue an accepted  quest
    • Cancellation logic if the player took too long or didnt achieve objectives
  • Quest Server Bubble activation (if unique temporary location needed for quest plot) - directives to server to set up  contents of an instance 'bubble' (done on-the-fly) with details previously determined and populated with appropriate  props and NPCs.
  • Usually 'encounters' at the locations are choreographed with the NPCs acting out a certain activity. The Control  script would issue directives to all the actors as to their current behavior states/activities.
  • Usually there is a way for the Player to 'drop' a quest (sending a 'sorry charlie' to the Quest-giver or somesuch).  Quitting a Quest that the player accepted can often have repercussions (the Quest might not be really over and the  Quest-giver may still follow up with those repercussions).
  • Control Script at the Quest's 'end' cleans up stuff involved in the Quest (locations/NPCs/props/Instances)


- Game Events:

  • A staged World event not usually associate with any particular player ( a bunch of stuff happens and players react  to it however they want to). Is generated by a Quest Scenario Template.
  • Similar to a Quest Instance (the way it is auto-generated(customized) and setup/initiated and run)
  • Game Events usually runs for a set period of time or until defined circumstances (can be similarly controlled over  time by a Quest Control Script).
  • Example would be : a Splicer Raid on the city with Splicers going after a predefined objective and the cities NPCs  react accordingly and the Players can interact with the Splicers as they want to (probably a Blast-Fest). The events  control logic could make it take place in different locations when rerun -- likely with a somewhat different objective  and with a different mix of Splicers. As you might have figured out by now, VARIATIONS and unpredictability are a key  goal of much of this 'auto-generation' system). No Quests that you can write cheat books for, with an exact walkthru  spelling out every detail....


- Mini-games :

  • Tablet/palmtop sized game (also playable on a simulator on a PC, ? consoles) - limited to common resolutions for the  selected set of target devices.
  • Flash type animations, HTML web interfaces. Button-centric (minimize keyboard, wont rely on mouse style interface)
  • Interface with the game Server - game could be loaded (several 'scenarios') and later played while having no  internet connection and then later communicate the results to the server (transmitted on reconnect to internet).
  • Some mini-games might require more constant interaction with the Server.
  • Generally simplified graphics (dont want true 3D that low end palmtops/handhelds cant handle)
  • Sprites and Pixel art (seems that gaming is going backwards with this kind of stuff) ...
  • Usually associated in some way with the actual game world (City Office missions, Player running a business, etc..).
  • Another avenue of continueing 'playing' when a player cannot be on their game machine.


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

Object Instances can be 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 scipt 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 into)
  • Prop intance '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

NPC with Personality :

- The idea is to have NPCs which even though they may be 1 of 2000 Citizens of the City will be sufficiently different.

  • Live in their own residence with their own possessions
  • Have a job/profession to do at one of many places (work for the city, in a shop, for a player, etc..)
  • Have different skills and tools and associations.
  • Have difefrent preferences and tendencies which make them act somewhate differentlty in situations.

- Parameters supplied when an NPC is auto-generated will control how the NPC is formed (ie- an NPC set with a 'highclass'  setting will be adjusted to behave 'highclass' by an auto-generation templates that has variation options for that  flavoring).

- Slight random variations can cause significant different behaviors (Bell Curvse used to control randomness)

- Templates give certain sets/patterns of behaviors/tendencies/details matching archetypes of personalities

- Tweeking (customization/adjustrments) ontop of the Templates combinations (conflicting settings are  arbitrated/resolved)

- 'Bosses' get full pre-built customization (they need the cohesion and they need to fit behavior expected in a quest  situation).

- Professions and roles would shape the behavior of the NPC (more templates that run and shape the NPC). The NPC can  shift its environment to fit the given Profession and Role (ie- a craftsman will have alot of tools as possessions and  stuff laying around that the NPC would bet 'working on').

- Example - a cohesive selection of voice assets for a particular splicer type (voice reactions to different situations)  --- --> http://bioshock.wikia.com/wiki/Breadwinner http://www.youtube.com/watch?v=iiBrIX0EsiU

- Text speech (cant have recordings for everything unfortunately ...) is much easier to have LOTS of variation for the  same response/reaction. Must prevent NPCs who spout the same audio recordings over and over (one method of making  variations is to have shorter sub-phrases which can be recombined to say the same implied message (ie- randomize messages  start/middle/end, each with 3 different options gives you 27 combinations -- 4 each would generate 64 combinations  etc...)

- Generic City NPCs will probably need at least a dozen voice variations for the common vocabulary/sayings (probably  double that, though tricks like frequency shifters and speed changers might make the same recordings sound somewhat  different)


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

Collaboration Process Aspects:

- Open submission of Upgraded/Improved Objects (any existing asset is available for potential upgrading by player swho  think they can do better)


- Open submission of totally new assets (something that doesnt 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).


- Collaboration Process is set up to make use of players for vetting Assets before it goes to Game Company personel (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.


- Dependancy on tools specific to game data format and importation for formats from outside tools (standard formats).

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 Assset' system prohibitive. Open Source  tools (and modular subtools) 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 playersto 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 ---> 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 posting within 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/prefered 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 existsing 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 catastrophic effecst of any change)

- Prefer to minimize this and get most fixing/extending done in PreRelease 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 wont 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 (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

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


---

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.