Procedural Generation

* See also Auto-Generator
* See also Quest_Generation_system
* See also Types_of_assets
* See also Templates
* See also Object
* See also SkyboxGenerator
* See also Server_Bubbles
* See also Player_Created_Asset_Collaboration_System
--- --- --- --- ---
Q: What is Procedural Generation Programming ( for Auto Generation used for in a Game ) ? :
A: Procedural Generation == Creating 'On The Fly' Content in the Game World (created via algorithmic (programmed) means ).
An advanced MMORPG mechanism ( utilizing Procedural Programming generation ) would provide an endless amount of new playable Spaces for many Players to explore/work upon, and to re-develop their own little part of the City.
The content can be adjusted/tailored/varied to match custom circumstances.
This game has significant PLAYER MODIFICATION capabilities, SO it will always need more 'Wild' places to go Adventuring in and to seek materials/Splicers.  There would be a 'core' fairly-civilized area that will exist from the MMORPG's initial startup. But Players will expand outward from there - 'Conquering'/Retaking and Remaking the Ruined/Derelict parts of the City.
---
How does a MMORPG game, which will run for years and see many Players pass thru making their contributions, keep going without running out of space/resources/newness ??   That, especially when Rapture is effectively one big building, and which once developed stays developed ? 
Answer : an Auto-Generation system that can enlarge the game's City Map outward when needed.  A City built of a system of interchangeable/configurable 'building blocks' just requires more of them to be appended to expand its border areas ( before the Player sees the edge ).   These expansions CAN be done 'programmatically' ( with some manual guidance ) -- Using Scripted Rules which specify logical/cohesive building patterns with realistic limitations to make sure what is generated makes sense and fits together.  Once basic/general features ( the aspect whose fit/integration is the most restricting ) are formed, then more and more specific details can be filled in ( using common 'local' themes/styles matching the logical nature of that area and the larger situation ).
--- --- ---
Procedural Generation of Assets ( Automatic Creation of Many Objects/Terrain/etc ... from Patterns ) :
* Used for Assets with predefined compatible substitutions/repetitions/variations of patterns ( the way things fit together ).
* May require Irregular feature correction Rules (scripted logic) to control limitations/avoid illegal/incompatible combinations and various endcases ( to have things fit-together/make-sense as much as possible in logical combinations ). 'Fittable' Assets can be self-adjusting/fitted ( via programming code logic ) -- like stretching to fit gaps, or adding repeated extensions. 
* Templates are basically scripts ( small Programs with some Data ) which take parameter data, and with calculation steps expand/build into the full data the Asset Object needs to be displayed, and to interact in the game mechanics. The Templates used on the Client exist in a File Library/Encyclopedia of th e Players Computer which need only be transmitted once from the Server ( unless being resent when revised ), and thus saving on a great deal of constant data transfer. 
* Hierarchy of features - The master (topmost) Template invokes sub-Templates used in making up the Asset/Object being created ( those sub-templates in turn may call their own sub-templates ). There can be Different 'templates' for substitutable variations ...
* Parameters get set for sub-feature Templates - used to select options/control variations of those Templates ( parameters to activate/select option logic, coefficient values and selected equations, all which determine the "instance" Object's Attributes ). Parameters are passed down to sub-Templates as needed ( Templates can 'inherit' from higher up Templates ).
* Application of local "Themes" ( predefined common sub-feature options ) like : materials, external appearance (decorations, textures), and damage state/wear, etc ... can be used to cause a common flavor to be added to an Asset to make it (when created) FIT with similarly 'Themed' Assets in the same vicinity or situation.
* With Parameterized Templates, Assets can be defined with a minimum amount of stored data ( template selection plus parameter control, which algorithmically creates ALL the specific FULL detailed data defining the "instance" Object or set of Objects ). 
* Patterns of random 'control numbers' can be used to define/shape a unique Object (it's In-Game Data). Those save rando numbers when invoked and fed to Templates can consistently recreate the same Object (it's Full Data) "on-the-fly". Variations of the same kind of Object can be defined and created/recreated controlled by those select random numbers 
* An initial computations is done on 'First Use', with relevant data being fed to 'Formation' Templates which have scripting (program logic) to create/adjust/decide cohesive/fitted combinations. The resulting 'control numbers' are stored for subsequent use to generate the actual object (full data) used in-game. 
* Objects which get modified by in-game interactions/events/activities have additional; 'Mod' templates applied to them. When required those can, like the original Object's creation, be invoked "on-the-fly" to RECREATE that same current state of that particular Object (ie- with ADDITIONAL wear and tear, damage, corrosion, some dirty state, repairs, wet, Graffiti, etc ...). 
* When the Object is (disk) stored away outside of the programs memory ( like when the Player isn't nearby ) it can be compressed down to a compact OFFLINE parameterized data form ( minimizing what usually is a HUGE amount of specific data which would otherwise have to be saved somewhere ). Data for numerous objects thus can get compressed for storage until they are needed again. This is also used for storage containers and Player inventory systems which have limited access/usage. 
* Likewise,the Server sends data about an Object the Player sees in-game to the Client. That also is in a compressed/compact data format, helping to speed the download. 
(( Most games have generically define whole/Bulk data Objects in the Client's Level Files which are simply cloned when placed onto a Level Map. Some data imparting 'state' changes to the Objects ( when varying/play-modified from its standard form ) is still used, but in most games such are usually much more static and simple ( ex- An Object's current Damage Hitpoints used to impart a 'damaged' appearance ). ))
There are different data forms :
* The Creation Seed data - defined parameters specify options, also which local 'Themes' may influence/adjust.
* The Expansion Operational data - the 'builtout' full data expanded and used when Object is 'Active' - used in-memory while 'playing' ).
* The Contraction Stored data - data is collapse to a minimal encoded form for 'inactive' storage, including any/all mods to the original Seed data.
Templates can exist for many kinds of Types of Assets which might make use of Standard Objects and Procedurally Generated Objects. ( Template data has one copy that might be used by MANY objects - saving space ).
--- --- ---
The Possibility for Modes Expands with use of Procedural Generation :
Ex : "Foley" -- Adjusted Sound Effects 
Have A Game Setting Mode which adds 'Bonk' and 'Wham' and equivalent sound effects ( a further 'mode' with TV Batman placard overlays to cover up 'violence' ... ) to cover up the Game Violence ( and the potentially far more realist Game Violence ... ).
--- --- ---
Enabling this Game's Auto-Generation Advantage :
The real 'trick' of this MMORPG will be the Servers generating buildings automatically as the Player accessible parts of the City expands. Local Styles/shapes/uses would be semi-randomly defined following a general City plan ( Seed Data that is pre-defined so that the City's patterns will be cohesive ).
Effectively, a Server 'generator' program would do what the user of the 'Easy-Builder' does, and piece together a reasonable building interior for a given need/space. Much of Rapture IS repetitive in its structure, so that a program and a range of predefined template patterns might do a sufficient job of creating many different buildings. Prop details auto-generated within those buildings would further vary the look/feel of each location, as would the inhabitants.
Still there will be many UNIQUE pre-designed/assembled buildings ( taken both from the games and new ones created by the Game Company and Players ) that fit special key 'landmark' locations ( including whole levels we've been in before ... ) . The 'Easy-Builder' Tool would often be used for parts of those ( as those 'landmarks' have to be decomposed into unit/object sections anyway for the Game Engine to work with ).
--- --- ---
Consistency and Cohesion
There ARE different flavors/patterns of areas that have to have some consistency and cohesion in how they are positioned and fit together to make sense (and not look absurd).
The City Center should largely conform to what we've seen thru those ocean windows. But how many buildings did you see ? From what I saw there were quite a few visible as I looked out those windows. What was behind them in the murk ? Therefore we can always add more short and tall buildings connected by more Streetways (if needed) and further extensions of Atlantic Express and the Bathysphere transport system. Did you notice those transportation maps showed addition destinations "service cancelled' that we never went to ?? I would try to use that game information be consistent when expanding the city, but there is a great deal of leeway..
Certain key locations seen in BS1/BS2 ( Fontaine Futuristics, Fleet Hall, Hephaestus, Ryan Amusements, etc ... ) would exist and in very specific placements relative to each other. But what else was between them ?? Lots of space to fill near and around them even in those central locations. Who says there cannot be a rival to Kashmirs in the uptown area ?? Certain locations like Hephaestus looked like they were somewhat separated from the city ( unstable geothermal area you wouldn't want to build skyscrapers on ). Similarly Persephone was on the edge of a 'bottomless' trench which would help define at least one hard edge of the city map ( or define a different flavored area the player might get involved with - a chance to descend into that 'abyss' ).
Typical modern cities are laid out on a grid pattern, usually working around irregularities of the location. The inner city would likely follow such a pattern. Each rectangular section can still have different things within it, but the basic transportation would be built to follow the grid.
There would be outlying areas for industry/manufacturing/farming/raw materials that were not shown in the game. You would need such complexes to meet Ryan's attempt at being 'self-sufficient'. Connecting structures can always work around anything already previously located when expansion is needed ( rock Tunnels running below the city are handy for that ). The city can radiate outward with ever-widening areas to expand into. The further out you go and the more open space there is, building no longer has to follow the packed grid pattern and large complexes often are 'one offs' of more irregular shape.
Shopping Malls and Arcades would likely be generated in large coordinated groupings. They only get to a certain size before they are too repetitive in the shop types, but they have to be big enough to cover a sufficient range of products/services.  Once a Player 'breaks in' to a new unexplored Mall area, they will likely freely march around and look through the whole area.  It should all be ready (prepared) to be seen in every detail before that ( all details would be finalized ).  A 'Mall' might be linear or circular or branching in its layout. The desired overall shape would be formed from appropriate 'mall' type interconnecting building blocks and it would be made to fit the adjacent city.  Interchangeable 'shop' slots inside this Mall would be filled with 'shop instances' ( themselves generated to meet the local theme and the desired ratio of shop types, and cohesive in detail ).  There would be a variety of standard 'shop' sizes (maybe 5) that would be fitted.  Each shop might have multiple rooms and be filled with contents appropriate to its type ( and be in an appropriate wrecked state ).
--- --- ---
Self Rebuilding Assets - In Game Maps/Worlds :
The Mall map in Fort Frolic reminded me that various in-game Signs like this need to be modifiable as new businesses/facilities are added - Either by Players in the New City (New Rapture) section, or for old ruins which are filled-in semi-randomly (Procedurally Generated) when explored, or from newly added game Assets being installed.  Damaged wall maps/directories can have obscured/unintelligible names on them to hide the fact that the Server World hasn't yet been expanded to include those details.  With all the rest of the create-on-the-fly' mechanisms in the game, this kind of mutatable thing would not be difficult to make happen ( It IS how much of the game system operates ).  The Players have a complex map widget in their interface(s) which also would handle this process.
--- --- --- 
While It Is Building : Waiting for the Dust to Settle :
The mutable Scenery/Terrain (and damage) Auto-Generation used in this MMORPG does take some runtime to get sorted out - Between the Player's Client, the Server and its Database, and other Player Clients which might see the results.
The Server will resolve what effects and changes the 'actions' cause ( including moving INTO a new area ), and send the Mod'd data to the Clients, which will create the actual visual changes to the Objects involved - Placing decals, mutating 3D meshes, adding/subdividing objects so that they can be rendered. This is not always a quick process, and may take more than a few seconds to resolve. This is particularly true if 'actions' are continued, and their results are cumulative.
SO in the meantime, for a short while, various ways to obscure the affected Objects with Poor-Light/Dust/Smoke/Explosions hurling objects/raining down Debris/Blurring can be done to cover up these transitions. Allowing the full result resolution -- So that 'when the dust clears', all will appear as it should. Some of these 'obscuring effects' may be direct side effects of the actions ( think of all the effects an explosion has ) while others would be added s needed. Of course for things that happen at a significant distance the 'cover up' effects can be subject to Level Of Detail (LOD) and simplified .
Some of the 'effects' play out over time and have secondary effects ( like a spreading Fire that does damage as it spreads and can trigger other effect that in turn have yet more secondary effects ). Having things 'half obscured' will help cover for delays inherent in the MMORPG's communication network.
--- --- ---
Consistency - Ratios, Rules, Logic and Themes.
The amounts of different types of facilities needed and desired by the original inhabitants would be defined by proportions.  For every manufacturing plant/shop with X number of workers/employees, you will need some equivalent basic residential space for them, with some small number being upscale (for the management).  The same goes for commercial organizations, but usually with a larger percentage of 'white collar' workers ( who often have somewhat higher housing standards and goods desired ).  Service jobs have their own particulars.
There are certain amounts of different industrial/manufacturing goods production to meet the needs of the city's original population ( 20000 - though wasn't made plain that include citizens in outlying areas outside of the 'city' proper ).  Industrial plant space per worker is usually a much larger area than manufacturing or commercial space per-man.  There was wide spectrum of consumer goods produced for the population of differing amounts.  Each item produced often came from several raw materials which also would have to be produced/obtained.
---
Shops for consumer goods and services run on similar ratios with different mixes of items/services for different social levels.  Businesses are often 'local' to the consumers they serve.  In a City things can be interlaced - more than you find in suburb neighborhoods.  City neighborhoods do exist and they have their own themes/tones/flavors (example- Paupers Drop).  Types of establishments that would be present in local areas: ( food, sundries, clothing, furnishings, entertainment, luxuries, health, tools, media, social ).  We saw a sampling of such in our treks thru BS1 and BS2.
Look and feel -- Industrial/manufacturing plants usually have all the same grungy look and vary in detail by what machinery they use. Upscale shops have upscale decorations.
An Apartment complex is fairly consistent with a local theme decoration and the individual interiors (and Prop content) vary the most, matching the people living in them ( of particular social class/income/professions ). 'Rundown' often is the 'normal' state for lower-class rented apartment complexes. Of course, in the 'Ruins' any contents will be thoroughly trashed by the %27civil war%27 and years of neglect.
Basic color/decorative themes for Malls and Company office facilities have consistency within their whole. Government facilities similarly are uniform. Individual buildings could have their own themes with sub-themes for different functional areas ( managerial vs sales & customer vs office vs grunt-labor vs basement storage ). Company logos would consistently be displayed.
Many such formulating rules/limitations/guidelines would exist - from general to very specific and be divided into subsets applicable to Generation of specific object flavors. Whatever details are generate will reflect the ruined state of the City --- varying in spectrum from a state of being still lived-in by the 'wild' remnants, all the way to being completely flooded or even blown apart.
Certain City locations/landmarks identifiable from BS1/BS2 are remembered by the player and would be initially VERY specifically positioned on the World Map ( with their immediate connecting structures specified to flesh out the area ).  Some of them we were actually in and would be carefully replicated ( some will be actually expanded to fill in the many sections we never got to see behind those jammed/blocked doors/stairwells and unseen utility ways ).  Those locations are unique -- with exact detail ( add 7 years more deterioration for those seen in BS1 ).  Others we did not get close to would be specified only partially ( like the many tall/major buildings who's exact interior contents aren't known ).  The auto-generation can fill them in later to full detail if anyone gets to them.  General details of exterior shape/number of stories/their basic purpose would be initialized for them first, since that is visible from a distance ( like what lights are on and which floors are smashed ).  The many other finer detail would be left unspecified ( to be resolved to full detail when players get close to them ).
Details of the complete paths of the Atlantic Express, which has all that permanent track structure/known stations, which would be accurately positioned ( using the game maps/views for an approximations ).  The Bathysphere system is more free form and needs only the stations at the destinations with no real intervening structure ( other than open ocean paths and the cables ).  That Chrysler-like building we see is an obvious reference point with a prominent location.  The 'core' area of the City will have to be specified in full detail, as that is the place the first players will start and it will be accessible from the first moment. Tenenbaum's new rehabilitation clinic would be amongst these 'core' locations.
---
Pre-seeding the City ( Developer's pre-made Macro Patterns guiding Auto-generation ) :
Manual guidance to overall shaping ( and specific desires city features ).
Using logic/rules (mentioned above) as guidelines, generalities for different extendable areas of the city can be pre-laid out ( 'seed' data - created by the developers to create a cohesively/coordinated plan ). Simple generalities ( this area industrial/commercial/manufacturing plants, that area residential (upscale/downscale), downtown/uptown here, main throughfares from there to there ) via flags/coefficients would be marked out on a map grid, General 'flavor' markers would define the growth patterns used by the 'auto-generation' Server mechanism. Developer-created 'seed' data acts as a starting point facilitating less complicated rule-based decisions ( residential rules, industrial rules, outer city rules, interconnection rules, etc ... ) So, with hand-created guidance data ('hints') conforming to a valid City plan, some simpler logic decides on specific details to 'generate' ( It is much easier than trying to come up with a program to generate Realistic patterns from scratch - There will already be alot of logic to create just using hints to do a proper job for this auto-generation ).
Most City buildings and their interconnecting structures would be pre-built from basic external/structural shapes and a selection of cosmetic detail. It is much easier to make everything fit when you can shuffle all the possibilities before actually placing and locking down the plan. Locations would have to be reserved for all the required industries. Most of the gross details for these would be pre-defined, leaving fine/arbitrary details unresolved ( left to auto-generation later ). Most large industrial/manufacturing complexes would be pre-specified with much detail decided before the game was started -- They are generally unique and have fairly specific shapes and positions of buildings/machinery that really is easier to do by hand. Smaller more common installation can be located almost anywhere if they fit into a 'city block' in the map grid ( and so can be placed in different places in each Server World ).
After basic positionings are decided, Companies with name identities would also be set. Names are particular items that would have to be predesignated ( or picked randomly from pre-made candidate lists ) to meet identities/entities that we've already heard of (in the Solo games), and match the overall fictional naming scheme. Many others will be semi-generic names ( auto-generated combinatorics ) reflecting the population's demographics mix and genre. Multitudes of logos and other details will be created by players to be used ( like generic frames around company titles ).
Some 'generated' fine details ( used to individualize many locations ) may just be random pulls from a set of available options ( stores/shops/buildings/complexes/plants/plazas ). Some in-game locations may not have much original identity remaining -- having been largely destroyed in the chaos after 'The Fall' ( even trashed/gutted interiors will be auto-generated with appropriate details ). Some existing details may be of little consequence as a ruined shop being rebuilt and reopened ( in a recently stabilized area ) will likely be personalized (re-detailed) by the player doing it. It may be put to a completely different use and changed almost completely except for the external walls.
Again, whatever level of partial detail is preset or later fully generated, it will reflect a properly ruined state of the most parts of the City. For the final 'full' level of details, an important factor is how much useful material is left (versus what's useless) for the Players. This may vary quite a bit with some areas thoroughly picked over by years of Splicers, and others having been cut/blocked off early on which may be filled with lots of pre-civil war goodies.
---
Outside in the Sea there is also Terrain which Players/'Team' NPCs can access ( using diving suit/submarines/bathyspheres ). There are many useful things laying around, and more than a little City infrastructure out there (and missions to do). Heavy external wall/window repairs would be done from that side. That terrain would be more of a standard '2D' terrain mesh, in which the city buildings and structures sit.
There are different sections of that seabed surface - the solid rock the city was placed on, the edge that falls away, plains of silt, ridges and canyons, etc ... The interior windows would actually look out into that ( real view instead of the static Skybox we saw in the Solo games ). The various seascape settings ( those pretty glowing corals, kelp beds, etc ... ) and water volume with different types of Sea Life can also be composed of modular 'building blocks'. They are more independent of each other, so that 'on-the-fly' TEMPORARY auto-generation could be simply done for vast ocean areas outside the City. A similar pre-made 'seed' map grid pattern would control appropriate content creation in those areas.
----
== Auto-Generation (continiued) ==
The Auto-Generation system ( ontop of the modular world system ) makes it possible to create a large MMORPG World without having to hand craft it all (which is $$$$ expensive).   Templates ( generation patterns/rules ) will fill in all the finest details tirelessly (programmatically) once they are working.
Building the initial game World, developers can add seed data to pre-place certain features ( like the City layout street plan and buildings and the transportation systems, landmarks, etc ... ).  They would then use the Auto-Generation mechanism to fill in further details ( as far detailed as needed - as some sections wont be filled-in all the way until Players get near to them ).
Some buildings/terrain like those seen in BS1/BS2 (and DLC) would be replicated almost verbatim ( after conversion to work with the MMORPGs modular world system ).  There was quite alot of buildings you passed thru in the solo games, so some of it would be in the central area (Apollo Square vicinity ??) and be already fixed up/repaired, and many others further out still be in ruins ( or like Persephone largely destroyed/crapped over by 'The Family' ).
Different locations could be tweaked separately to adjust things for a certain effect (certain themes) - the 'tweaks' themselves are just scripts that force specific features and those can be generated by Game Editors.  The Auto-Generator is a tool that can be run to test ideas, make improvements and then run again til refined sufficiently.    Finally, the initial World data would be built to start off the game for the Players.
The parts of the World to be Auto-Generated after the game starts ( local details built on-the-fly ) can be different on each Server's game World ( just allow random factors to build them differently ).
A system like this does take a significant amount of testing to make sure it works right ( auto-placed jumbles of junk not so bad, but have to watch for 100 of something ridiculously valuable being dumped in one place as a bug ... ).   One advantage of a modular script system is that you can add logic/rules into the Templates to check for endcases and remove/correct aberrations before they get added to the Servers.  Likewise, a running Server's data can be patched for corrections after certain unbalanced things got into the Game World data.
As I mentioned in the BioShock Infinite forum about replayability, diverse variations and combinations that make encounters and situations different will be the way to continually give Players something new ( and maybe challenging when they have to 'think on their feet' ).  In A MMORPG, you don't "replay", but you can go someplace and find something different today and then go back tomorrow and face something else different (( No more Disneyland animatronics situations for cheatbook authors to give you exact walkthru instructions )).
--- --- ---
Events : 
One thing a system like the one I've described makes easier to have is GM coordinated 'events'.
It is much easier to control/facilitate enemy NPCs spawns ( they are no longer locked into a static World Map ) and Props can be added/removed/modified by calling the Templates to 'set the stage'.  They can be created in advance and tested before they are put into effect on a Server ( I've seen botched GM events on MMORPGs before ). The NPC behavior system means that actors in the Events can run themselves instead of having to be directed explicitly by GM commands ( which then are often slow and simplistic ).  With the ability to have many variations with minor changes, running the same Event again starts to require little extra work ( and they can be applied to other Servers just by moving the Event 'scripts' to each. )  GM salary costs unfortunately eat into profits ( and have been minimized into uselessness by most companies ) but at least this system would cut the work needed to facilitate GM run world 'Events' - if there are to be any.
So, Yet another 'Asset' to create via a 'Player Created Asset' system....    Seriously, when game companies start using such a system it will both decrease their Production Costs $$$, AND greatly improve the MMORPG Players experience. (( Of course, it seems none of them are really interested in THAT ))
--- --- ---
Random Name - http://www.behindthename.com/random/ :
Example of a tool that could be used by an Auto-Generator to fill in some game details ( for Player Avatar names(?), NPC names, extinct company names, etc ... )
Design Issue : Of whether Players are allowed to create their own names/identities (and bios ?). It may be preferable to NOT have some Players restarting their one allowed avatar character over and over (and over) til they got one random name they would accept ( and they often still would not be pleased with it sometime later ).
A philosophical question is do the Ex-Splicers have or even want their old identities?? ( maybe a possible justification for allowing the Players to choose new ones ... ). I'm not sure yet if there should be any remnants for them (including skills) from 'the before time'. It certainly would add more work to do it right, if there had to be pre-made identities - rather than starting them Tabula Rasa ( 'Brooklynese' for 'blank slate' ).
Self-Chosen names of course would be Vetted ( probably a manual process to catch subtle abuse some players might attempt ).
Vetting a Player's self-created Biography likewise might take a different type of work ( all that Lore/Canon Compliance and dealing with all the people claiming to be Ryan's/Cohen's/Fontaine's brother ... )
Another feature would be nicknames for Player's avatars (and NPCs). With the more detailed 'social' interactions being simulated in the MMORPG, you could have nicknames used between 'friends' or other informal associations instead of a simplistic(boring) 'one name fits all' system you see in alot of games.
Similar selection problem exists also then for 'Nickname' assignment to a Player's Avatar ( possibly alot more variable/creative ).
I preferably would NOT have 'earned' nicknames', like in other games where they have 'titles' and 'ranks' awarded. Kinda lame to have 10000 Players all with the same nickname for doing exactly the same 'achievement' ( or having them change day to day )...
--- --- ---
Procedural Creation of Figure Animations (and AI) :
What good is a well detailed human model if it moves stiffly like a Frankenstein's monster, or when you pick something up, your Avatar's hand visibly goes thru the object or you grip it in an impossible place  --- it can look obviously inept and stupid.
Sometimes a general 'representative' motion is sufficient, especially when you see a figure do it from a distance and any finesse isn't really visible - ( so you have a Level of Detail adjustment which can cut out ALOT of more rigorous processing ).  In high detail, the animation needs to be adjusted to fit the situation close enough to not look absurd ( when you pick something up, having your hand go thru it or you grip it in an impossible place it can look obviously inept and stupid ).
The actual movements for a general 'Action' may have many sub-details -- Like when you reach into a Pile of Stuff to extract one item - like reaching around some things (environment), or when pulling, part of the goal is to pull with force along a certain vector upon the target object ( when you attempt more real physics for the whole world system).   Minimum adjustments start from the initial positioning/stance/attitude/pose the figure starts in ( standing/running/crouched/etc ... ) and flows/transitions from, and then the desired final position when that action is completed or transitioning into the NEXT figure action ( a jerky sequence of nice actions defeats the whole purpose ).
Doing this is similar to Generating Terrain 'procedurally'. To generate realistic figure actions you have to involve the body's physical limitations/dimensions.  There are only certain ways the human body can bend, and how fast the parts can move in relation to other parts ( and even more restricted motions to appear to act efficiently or in a coordinated way ).   "Inverse-Kinematics" https://en.wikipedia.org/wiki/Inverse_kinematics is a  well known processing technique to bend a multi-part ( 3D 'boned' ) limb or body to match specific attitudes ( to put the end of a limb like a hand at the right spot ).
You would plan the sequence of motions work in relation to other objects present-- which if THEY in turn have complex behaviors/attributes or are to be manipulated special ways (ie- tools) require even more special specific movement details ( ie - throwing something to achieve a specific trajectory that lands on the target ).  SO the environmental situation is all part of the complexity.
Much of the processing should be done on the Client machine ( taking alot of load off the Servers and advantage of its GPU ).   Considering all the complexity, the animation system would employ basic Planner AI to solve all those simultaneous problems to find a solution to make your figure move in a (more) 'realistic' fashion to achieve its goal.  With a dynamic situation, this is  often in near real time.    A high level plan first determines what will actually work ( evaluation - which often is the bulk of the complexity ), and somehow this is divided between the Server and the Client.   Once decided and transmitted, the steps to perform the actions are usually straight forward to process.   
The same goes for mechanisms and machines which have movements and interactions, and which might show more detailed workings close up and less complex from a distance.
-
Procedural Animations Compressed Data :
Compressing motion/action data using equations, versus encoding as bone time/angle tables ( both avoiding bulky 'tweening' keyframes ) is very useful when you have lots of animated objects visible, and a limited data bandwidth ( all possible precalculated data pre-downloaded ).  This would be quite important as World complexity increases ( in THIS game which is attempting the Avatars and NPCs to look less like robots ).
Specific, timely, high-level data is transmitted from the Server, and the Client converts procedurally to the actual motions, adding/adjusting what finesse is appropriate.   Depending on the amount of AI processing locally, it might be efficient for the Client Avatar motions to be sent upstream (high-level to Server) and then distributed to the other Clients ( multiple viewers of the same action ).  No need for every Client to figure out every proper motion being done by every other Avatar (which is what is different from in a Solo game).
AND (for background routine NPC motions) - Semi-static generation (by Server) - to make various reused (incidental/filler) NPC action animations change periodically (over time) with different variations ( keep 3 or 4 different patterns, 'cached' so Objects in the same vicinity doing exactly the same high-level action would do so with some variation ).  Well-compressed (procedural) equation/coefficient data being streamed to the Clients keeps the data transfer low, and can be done as a low priority when things are less busy between the Server and Client.
--- --- --- --- ---
.
.