Templates

* See also Auto-Generator
* See also Quest_Generation_system
* See also Types_of_assets
* See also Object
* See also Assets
* See also Player Created Assets
* See also Player_Created_Asset_Collaboration_System
* See also Procedural_Generation
add a diagram to illustrate concept
Templating is a Programming Methodology where Data and Script-Coding is Reused. 
A "Template" is a specific set of constant data and scripting defining some kind of thing in a general way. In the Rapture Reborn MMORPG, a system of "Templates" would exist to generally Define game Objects ( specifying a majority of that type of object's defining attributes ), which then are re-used in creating specific Objects/Assets. This avoids excessive/tedious work redefining/respecifying EVERY object attribute EVERY TIME a particular new object is created/mod-edited.
Templates are usually organized Hierarchically, with Templates (and the final object) inheriting much data from a more general "Template". Templates can formulate and synthesize bulk details and attributes from a few control parameters the user specifies. A great deal of control and object building work savings can be implemented through clever Template script programming logic/procedures capabilities. 
Hierarchical Template Example : Furniture >> Chair >> Swivel-Chair 
Additional NEW more-specific Templates can be created to better fit a desired common object type - Creating additional specialized sub-flavor Templates to minimize data the user otherwise would have needed to take effort to supply when creating a game Object. Less and less work is then required to use the more specific Templates to define a game Object.
When PLACED (instantiated) while editing a Game Scene, an Object of a particular Template type is created with inherited details/variables/attributes which can further be manually customized if needed. Templates through scripted can be made to adapt the specific object automatically to the in-game area ( programmatically using local effects/influences and associations with nearby objects/terrain/area-themes ) .
Some Templates can Place multiple (Group) objects - Adjusting all of them together to fit the game scene.
--- --- ---
Templating is NOT Cloning, which in other editable MMORPGs just allow selecting from a static set of various different 'pre-canned' object types, and then placing into the game Terrain ( or the Inventories of NPCs OR the NPCs themselves ).
--- --- ---
Creation Templates ( For Objects, Effects, Missions, etc ... ) :
These are Patterns of data with scripting (simplified programming) which allow the rebuilding and customization of game Assets.
Parameterized ( customizing options which maximizes reuse, and thus not having to hand-craft every detail )
The Template often has a Scripting component used to control the auto-generation of data for both random data expansion and desired customization ( using the parameters which are controlled by the scripting ). Usually there is embedded logic which makes sure that valid combinations and values of options are selected.
This also helps with minimizing the download of data to the Player's Client machine, when the Client need only get Template IDs and parameter info to convert ( getting the majority from the local Client's Disk Drive ) into possibly huge-sized data of the Asset used by the game. Most online games already do this, but they load mostly static data and their environment is mostly static.
Hierarchical - templates within templates ( Templates can 'call' other templates as options for groups of their subcomponents, to fill in additional detail or to override generic Attributes ). This maximized the utility of the existing Templates ( You don't have to redo the basic elements, you inherit them from another pre-made template containing those basic elements ).
The Template has a data component which defines components (and Attributes) of the object to be created ( the data can be in the form of tables which the Scripting can select from ). Things like textures can be freely/flexibly applied to vary the objects.
Simple example : A basic 'Chair' with ALOT of obvious Attributes, which when predefined in a Template would eliminate alot of work creating the customized 'chair' object. There would likely be further specialized Templates for other obvious 'chair' variations ( spinning desk chair/recliner/dining-table-chair/barstool/etc ... ) The attributes include links to animations and reactions to player actions ( which can add up to LOTS of work/effort saved by Templatizing such things ).
--- --- ---
One of those Typing Mistakes that Lead to Gold :
"MMORPH" (mistype on G) - But that's actually a very good moniker for this game system I propose. It needn't only be used for MMORPGs, but also for Solo/Multiplayer game development and Internet commercials, or just a general media composing tool ( like what Computer Publishing and Web Development has become in the last 20 years ).
Key Design Idea - the Templates facilitate 'morphing' things for the game in a VERY fundamental way.
--- --- ---
Yet Another Set of Auto-Generation Asset Templates : Machinery Discombubalators :
This is effectively a system of scripting which can make substitutions/modifications upon the pristine 'perfect' object mechanism, singly and in combination ( with logic to handle conflicts ).
* Destroyed/damaged components/assemblies (intentional or ambient)
* Missing pieces (filched parts would be common)
* Rust/dirt/oil/crud/jams/peeling paint (interior/exterior)
* Incorrect repairs (different subsystems)
Local environmental factors could be applied ( ie- in a wet area then corrosion and water damage is possible, or if a fire had occurred sometime in the past ... )
A history scenario for the object ( relevant to its location/the game situation ) might be composed to have applied multiple repairs/mods/salvages, varying the extent of damage following logical patterns/progressions.
Various probability metrics (for the different flavors) would be applied to decide what degradation, and how far the damage goes -- based on situational parameters
Partial functioning may be present with logical damage preventing full operation.
--- --- ---
ANOTHER TEMPLATE - Placement Attributes for variable/random Sub-Objects in an Environment ( like detail things/decorations that hang on walls in a room or hallway ). Placement Slots are predesignated in the interior building block designs ( those Templates ) - Where one object from a designated Subset of Objects might be placed.
Auto-placement/Fitting of Objects can work, but is not always completely simple slot-programmable. There often are 'endcases' the basic scripted logic cannot handle. ***BUT*** well-designed included Template logic can still put up a 'Flag' to Alert the higher level Editor (human) that there is a problem detected, and that manual fitting ( by the user ) needs to be done. This would be used on larger assemblages of components where the fitting objects interact with the terrain/other objects present. Trigger points/markers would be designated in the Template where certain other Objects/Templates interface and get adjusted.
Auto-placement markers would be put onto Terrain Component Objects ( ie- a Hallway section - straight/corner/Tand X intersections ) to mark out pre-vetted attachment/placement points for various kinds of decorative/detail objects ( IE- a picture spot on a wall space which open enough for size X/Y with centering mark. )
An AUTO Test Rig could be easily done to run through the current available 'Substitution Set' of options, and test for 'Fit' and catch problems ( including the Substitution Objects which mistakenly were Put Into the 'Set' which were supposed to be useable for the particular Option Slot. Manual viewing to see if the 'Placement Slots' are Aesthetic, or are too cluttered/clumsy ( It is often a Subjective Judgment which is VERY HARD to program ).
--- --- --- --- ---
.
.