Auto-Generator

* See also Procedural_Generation
* See also Game_of_this_type_-_Difficulties
* See also Templates
* See also Types of assets
* See also Server_Bubbles
* See also Server and Client
* See also Object
* See also Building_Block and Buildings_and_Building_Blocks
* See also Player_Created_Asset_Collaboration_System
 "Programmed Auto Generation" as applied to Rapture Reborn MMORPG design. 
=="On The Fly "==
--- --- --- --- ---
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 detailed as needed - as some sections will not be filled-in 'all the way' until Players get near to them ( some even only when they are in hand ).
Some buildings/terrain like those seen in BS1/BS2 (and the DLC) games would be replicated almost verbatim ( after conversion to work within the MMORPGs modular world system ). There were quite alot of buildings you passed thru in those Solo games. Some in New Rapture's central area ( Welcome Center vicinity ??) would be fixed up/repaired already, and others further out still will be in ruins (or like Persephone largely destroyed/'crapped over' by 'The Family' ).
Different 'static' locations could be tweaked separately to adjust things certain effects/themes. The 'Mod Tweaks' themselves are just Scripts which force specific feature changes. Those would be generated by Game Editors. The Auto-Generator would have a Tool that can be run to test ideas as they would be seen in the game, to make adjustments/improvements, and run again until the desired effect is refined. Finally, the initial World data would be built to start off the game for the Players.
Many parts of the Game World are to be Auto-Generated AFTER the game starts ( local details built on-the-fly ). They can be different on each Server's Game World ( just allowing a few random factors to 'detail' them somewhat differently ).
A system like this does take a significant amount of testing to make sure it works right ( Auto-placed jumbles of appropriate junk is not so hard in a setting of ruins, but you 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 the aberrations BEFORE they get added to the World Servers. Likewise, a running Server's data can be patched for corrections AFTER certain unbalanced things get into the Game_World data ( So much detail being 'auto built' means that it can be rebuilt with far less effort for these corrections ).
Important is Replayability - diverse variations and combinations which make encounters and situations different. It is a 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 see something else different 
(( No more 'canned' Disneyland animatronics situations for 'Cheatbook' authors to give you some exact 'walkthru' instructions )).
--- --- ---
Events :'- One Thing a System like the one I've Described Makes Easier to have is : GameMaster Coordinated 'Events' :
It is much easier to control/facilitate enemy NPCs spawns ( They are no longer locked into a static World Map ) and Props/Objects 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. ) 'Game Master' 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 $$$ BIGTIME and greatly improve the MMORPG Players experience. ( Of course none of them are interested in that ?? )
--- --- ---
An Auto-Generation system uses the basic template patterns 'building blocks' ( and all more specific detail templates ) and builds what players first see on entering a new area ( ie- building players have never reached before ) - Now instanced on the Server World and is subject to Player actions from thereon. Most of the new areas are ruins, but the damage/content will vary.
Locations will build differently, matching their layer areas of the city -- With appropriate variances/variations/combinations of details, both for internal (air filled) and external changes (sea water) areas. Because tall buildings are seen from a long distance, their basic external shape will have to be built up ahead of time by the Developers. Further specific detail wont be needed until the Players get near them ( a number of buildings in the startup areas will be fully pre-detailed ).
NOTE - the 'auto-generator can be used as a tool to fill in world detail for the Devs before the game is released. They can override to add in unique locations and to adjust the content as needed.
I would actually expect the 'building block' definition of all of Rapture to be laid out before the game starts so that all the 'streets' and building shapes and other gross details can be coordinated -- matching fairly closely the views (position and shape) we've seen in the Solo games. 'Rooms' within the interchangeable slots of those 'building blocks' do not have to be pre-defined (they are easily swapped).
Some (many ?) shops even in the largely developed 'downtown' area had been boarded up (never seen) and could have their inner contents built on-the-fly as the Player was forcing the door open. The detail for a 'room' (or grouping of rooms) is added to the previously defined configuration of 'building blocks' which already makes up (specifies) that entire building.
Layered areas : Several layers of detail - of increasing specifics
Destroyed areas :
* Flooded Areas that the Player wont be able to rebuild because too much of the pressure structure is gone
* External structure with large sections blown out ( different from intact 'external' state of other flavors ) - likely entire mesh replacements because of significant difference ( walls pissing/partial lack of internal walls/ceilings/floors )
* Sea Life growing everywhere ( wide variety of detail sections ) - extent dependent on how large the holes are
* Salvage still possible ( via Diving Suits ), with remaining contents subjected to soaking in salt water
* Tangled Girders and structural debris thick and everywhere, with Risk of collapse.
* Mobile Sea Life - fishies swimming about, currents waving the seaweed
* General discontinuity/disruption of utilities ( new mains might be built new to bridge gap between adjacent areas )
Drowned areas :
* Filled with water - bulkheads sealed from adjacent non-flooded areas
* Pressure integrity lost and the area was sealed when the bulkheads closed
* Exterior struct can have varying levels of damage - including windows
* Limited Sea Life incursions - often the holes are too small to admit much of it
* I noticed in Dionysus Park windows that were encrusted (inside of outside?), so window substitution(dirty/clean) will also be needed.
Ruined areas :
* Lots of wreckage/debris from deterioration and 'civil war' damage
* Utilities largely dysfunctional
* Minor leaks that the still operating pumps can handle ( otherwise would be completely filled )
* Air systems partially working - still connected and open to the main distribution hubs
* Inhabitable at least by splicers
* Vermin that live anywhere there is something to live on
* Movement may be impaired with many blocked doors and rooms full of debris
Reclamation areas :
* Expansion work taking the city back from 'the wild'
* Much activity clearing, rebuilding and repairing
* Alot of damage still evident
* Still subject to incursions by splicers
Repaired areas :
* The Downtown - Where the New Rapture has been started to be rebuilt
* Most of the ex-splicer population lives here in a reasonably normal state.
* Regular maintenance keeps it stable, debris has been cleared
* Initial areas setup by the server ( Players may have made subsequent changes )
* Machines of convenience have been restored
* Shops and NPCs selling things again, still many locations vacant
* Utilities in working state though often in need of improvement and increased capacity
* Much Minor damage still not repaired (much cosmetic)
Rapture's 'Showcase' area :
* Clean and Safe
* Most everything works
* NPCs are everywhere busy acting out the old Rapture, many passing thru the transportation hub.
* Cosmetically looks much as it once did long ago
* Is only a fairly small area of Rapture ( and took alot of work to beat it back into shape )
* Where the 'better' establishments want to be and are starting to be restored
* Residence in high demand, upscale locations are available and occupied.
* City Hall and other centers of organized activities
* Many 'unique' locations here are from the walkthru of BS1/BS2, so are verbatim structurally, but may have been repaired and cleaned up (more than a little).
Outside (water) area :
* Seen thru windows - so the big details will be pre-built.
* Large pipes, bathysphere paths and train tracks, etc... will follow very specific paths linking buildings and corresponding to maps seen in BS1/BS2.
* Sea Life/Seabed defined by where the rest of Rapture isn't - only stuff right next to windows is visible.
* Lots of wreckage stewn about, some is visible from a distance, much isn't so doesn't need predefinition.
* Specific details ( like fish and junk lying on seabed ) can be filled in when players get near.
---
The Auto-Generator builds up layers of details appropriate for the location and state of the areas being created ( and eventually is sent to the player's client program ) :
* Appropriate content for type of area - Commercial, industrial, residential, transportation, etc... Flavors have appropriate contents that need to be added
* Appropriate content for current 'state' of area (wrecked, rebuilt, etc..)
* Objects that were fixed in place (bolted down, etc) may be shown as torn lose and thrown around and crushed or be buried (inner wall panels shattered to show pipes/etc behind them, often leaking).
* Individual objects are working/damaged/destroyed/missing state as appropriate ( things like machines running or not depending on state of power )
* 'Effect' objects caused by the state of other objects which are placed -- Leaks, puddles, garbage/debris litter areas, ice.
* Submerged Water effects- the auto-mutator adds this state to the flooded zone and to the contained building blocks - A water surface (fully or partially flooded) that a Player/NPC will splash or swim thru and objects float at the surface or sank or suspended. The objects there now will be built with water damage and Sea Life accretions.
* Many alternate details are for appearance sake - decorations (to avoid repetition). Combinatorics of several random selections each with many available options increases variations. Some options are 'themes' that then apply to further specific details ( ie- all the line of pipes have the same paint 'theme' ). Some details come in sets - cohesive groupings of objects which look best when group 'coordinated'. Sections are built up using Themes inherited from the larger area. ( ie- red base color theme and carpeted pattern in Kashmir's causes all the rooms and other decor to be consistent thru the whole building - with exceptions in kitchen and other 'backroom' sections ).
---
Previously (or currently) inhabited areas containing the detritus (sometimes of years) :
* Has been well picked over ( but much that couldn't be used by Splicers remains or is shoved aside )
* Garbage piles in corners or strewn about ( one man's garbage is another man's treasure - recyclables )
* Old and new Graffiti, trashed posters, burn marks ...
* Shrines to Lamb's insanity ( most now defaced and mocked )
* Piles of supplies and crude amenities, furniture
* Sometimes have working security machines controlled by inhabitants
* Some areas were only recently flooded leaving much of the contents with limited exposure to sea water
* Sleeping Splicers
* Some locations are kept tidy and clean by the inhabitants
* Many have seen repairs over the years buy Splicers who fixed things to allow survival or comfort
* Some areas that had seen splicers well-organized are in pretty good shape.
Building shapes and exteriors vary quite alot ( seen looking out the windows in BS1/BS2) :
* Floors plans are frequently repeated ( different floor sized as you go up )
* Decorations of many flavors on exteriors ( style mostly consistent for each building )
* Signs and neon and lights (some still working)
* Interior lights show out thru windows ( many sections and even whole buildings now dark )
* Some destroyed multi-floor sections are little more than girders and rubble.
* Exteriors are visible to adjacent buildings ( often from some distance ) and to players out in diving suits and vehicles.
* Connecting structures (between buildings) likewise have visible exteriors
Some areas were sealed off from the rest of the city during the destruction caused by the %27civil_war%27 and can contain large amounts of untouched materials and items. Some such areas were later broken into, but others were too hard to reach and were left intact.
---
The Auto-Generator will place the disordered contents (objects) such that player-useful things are harder to obtain :
* Few in the open in areas that have been picked over before
* Covered in other debris and obscured
* Many broken/ruined items ( and expended items, ie- empty bottles )
* In locked/stuck/blocked containers
* Mixed with damaged objects
* In 'hard to reach' positions
* Once the content items are taken, they DO NOT respawn
* Some are submerged/behind hazards
* Splicers booby trap their goodies
---
Occupant populations ( NPCs placed and acting appropriately in their setting ) :
* There are Hierarchies amongst the 'wild' splicers and they behave very differently from the ex-Splicer NPCs
* Small cutoff enclaves of non-spliced people ?? May not trust you ( They survived this long ) when you try to convince them to return to the new city. May want connections back to Rapture (trade or more)
* Splicer Bosses with 'territories' and organized bands of splicers. Often with substantial infrastructure working ( they have to breath/eat/drink something )
* Individual splicers eking out a living and only indirectly interacting with larger splicer populations
* Remnants of 'the family' still exist in places if they managed to stay organized enough to survive.
* City ex-splicers (NPCs) trying to live normal lives again and active working to rebuild
* Upscale City posers can be seen in their fancy bought/looted clothing
----
----
How script and template 'data' controls the auto-generation:
There is data in the form of 'scripts' which contain calculation logic and control directives. The calculation logic makes decisions based on other data and the control directives make things happen.
Scripts can invoke other scripts which then determine what calculations are made and when/what directives are to be executed. Those common scripts help simplify the programming process instead of requiring the programmer to specify every little detail specifically everywhere, everytime.
Objects in the game can be generated by executing groupings of scripts called 'templates' which likewise can contain invocations of other templates which would contain commonly used logic and directives (scripts).
The scripts and templates are 'data' so that the programs that run them (Server and Client) do not have to be recompiled and the 'data' can be easily changed when needed. At some later time the data can be modified with improvements and new scripts and templates added to allow building additional/variations of Objects for the game.
When an object in the game is actually built, it is called an 'instance' and is a result of executing the proper templates and scripts specified to build an object of a particular type with all its appropriate details.
Some templates generate a group of associated objects - an assembly which are built together and so can share details and be made to fit together logically and cohesively. Each of those 'objects can be itself an 'assembly' if needed. Thus one call to a template can cause a whole lot of objects to be generated in the game and all the involved scripts used to make sure the object are coordinated together. Part of the logic in such templates include positioning the objects correctly ( ie- a row of streetlamps spaced properly down the edge of a street ).
Objects have a set of attributes which control what they do and are in the game via the game mechanics. These attributes are what are built by the auto-generation system into the object 'instances' which are added into the running server (the world data).
Among an object's attributes can be data that is 'scripts' which can be run to calculate decisions and direct actions for that object. Those scripts can call other scripts and invoke templates if required -- An example being a machine that makes other objects as part of the game would call for the Server to create an object defined by a Template (ie- "Bag_of_Potatochips").
The power of the scripting system is that when a 'Template' is executed its scripts can access game world data on the server to decide what exactly needs to be done ( ex- the streetlamps calculations need to find the road and its edge to know where to put each streetlamp and to fit that length of road with the correct number and spacing between the group of streetlamp objects ). That is called 'fitting' which causes things to be built correctly and 'fit in' to the situation the are being built.
Another powerful ability of the template logic is to calculate from the existing game world situation whether the goal of building the Object (or group of Objects) can be done successfully and properly carried out, or does something make the intended goal invalid/incorrect. Often a template will contain a directive like "Attempt to build Standard_Streetlamps on street X, and if that Fails then Attempt to build Special_Lighting on street X". Thus, the scripted logic can be made to make smart decisions which can adapt to many endcases that exist in the game world.
And another ability essential to the 'auto-generation system' is that the templates can include many variable options which can be picked automatically (randomly). These are usually details that do not effect the function of what is being built, so can be freely substituted. With many individual details being selected randomly for the object 'instance', the things being created can have MANY variations and many detail differences so they rarely will look the same.
An important part of this Template mechanism is what is called 'inheritance' of standard attributes. If a Generic_Street is being built, there will usually be a 'Default_Streetlamps' set as part of the 'Street' template. If no further details are specified, then the Template will 'inherit' the logic needed to define generic streetlamps details for the generic street. If the street is to be located in a bad part of Rapture (like the 'wild'/ruins) then the Template's logic/directives will decide ( via getting the situation context info from the Server ) to use grungy/ruined attributes for everything placed there in that assembly of Objects. This is 'Fitting' - with Objects being built to correctly match the setting context they are being placed into.
---
Objects in the game have 'behaviors' - They act certain ways depending on their situation. These behaviors are defined by 'scripts' that get executed to carry out decisions and actions. Behaviors can be as simple as reactions like an object 'on_fire' where it plays out the simulation of being on fire ( burn animations, setting things near them on fire, disappearing after they burn up ... ). Some attributes of an object 'instance' might control these simple behaviors ( ie- fire_fuel_factor attribute determines : burns a long time or burns quickly ).
More complicated 'active' behaviors make objects affect others in 'intelligent' ways ( like a NPC who acts like a human ). The Object instance running in the server game world might act out a daily schedule ( ie- going to its 'home' after work ), and look for things that it is meant to interact with ( ie- a Splicer looking for a target to attack ).
NPCs can have alot of behaviors in this game ( where they simulate having 'lives' much more than in other games ) Fortunately many of these behaviors are shared in common -- 'going_home' can be used as a good default for most NPCs and that behavior will actually be quite complex ( home where, what path, use transport, etc ...) but need only be programmed once and all object types using it just need to call the script. 
These behavior scripts also can call other scripts and templates to be able to execute common aspects of behavior. Organizing scripts and Templates for this kind of reuse saves on alot of customized programming. Templates can group whole sets of behaviors to assign to an Object ( ie - 'basic_combat' for an NPC ). They can represent different roles the NPC can play or modes of behavior appropriate to certain situation.
'Instance' specific attributes can vary behavior, so a particular Object can behave in slightly different ways from others. NPCs can be defined with different tendencies of how they react to different situations. The auto-generation system would set these attributes appropriately from the context, so that when the Objects run in the Server they would act out with varied but appropriate behavior.
The entire system is designed to be modular to better organize and save work in the development process and to have improvements easier to make.
---
All these Templates and scripts are designed and written by people with programming skill ( and with 'Player Asset Creation' by skilled Players also to expand the game later ). But at a 'high level' some 'user' Templates are made completely of simple invocations of other predefined Templates. These can be created/used by people with 'little or no' programming ability ( They don't need to know all the complex details involved - just what the 'Templates' will do ).
Thus a Template : "Create Shop_Room with Blue_Theme and Fancy_Lighting and Simple_Carpet and Row_of_Display_Case on left and Cash_Register and Smarmy_NPC_Salesman" would do alot of complicated work to create what was generally desired. In this case many details are left upto the Templates to randomly vary ( ex- haircolor of the smarmy NPC running the shop ). Specific details COULD have been specified to force specific detail features if desired.
---
Efficient Data Transfer :
Part of this template system is its ability to simplify the data that the client program is sent from the server (less bandwidth) by sending template identities and only specific attributes to define objects the client will display. The Client has the required 'Client Templates' and will use them to build up the whatever data the client needs to render the object. Thus every fiddly little detail does NOT have to be transmitted ( and since there are so many objects in this game, that will be useful to make it work ).
A powerful feature that can be included in this system is the ability to revise Game World objects when the Templates are improved. The Objects the player sees in the game are defined by data in the Server, and that data can be changed, and the Player will then see those changes subsequently. An example would be a NEW streetlamp option for street corners. The new Client templates for these 'Corner_Streetlamps' will be distributed to all clients ahead of time ( patch or in-game 'on-the-fly' ) and at some point the data in the server will be corrected. A server-side script will find all the normal streetlamps located at street corners and one by one will substitute the data specify them as being 'Corner_Streetlamps' while preserving any situation specific details ( the two Templates are very much the same and so use the detail data the same way ). Any new attributes would be set as needed ( ie- corner streetlamps might have street signs with the intersecting street names on them ).
---
With a 'Player created assets' system many new game world details ( and improvements of old ones ) can be incrementally added to the world ( actually all the Server worlds ) over time. This includes more varied, advanced and realistic AI Behaviors for NPCs, which is the area of major advancement over other games.
--- --- --- --- ---
.
.