BioShock MMORPG Programming

* See also Game_of_this_type_-_Difficulties
* See also Server and Client Programs
* See also MMORPG_AI_Improvements
* See also %27Make_A_Better_Game%27_-_Andrew_Ryan
--- --- --- --- ---
Technical/Hardware issues for game  - Game Engine features required/expected :
Can the expected hardware ( especially for the likely Console's ) support many of the following :
* Non-clumsy Input Interfaces ( ex- tedious Menu-itus of Console controllers ... )
* More versatile NPC figures holding/manipulating Objects ( a little more than the standard gun pose with a limited list of weapons ), many more NPC animations...  Vehicles...
* Client-side building of render Assets via parameterized Templates - substitution textures, combination  sub-Objects (conglomerations)   will cut down/compresses the network data sent to Clients ( bandwidth issues will ALWAYS be with us ).
* Client Preloading/caching of Assets before they are need for rendering/output (position/activity data from Server and most definition data from local disk ).
* Physics support ( at least rudimentary .. platforms ?? ) but now will a magnitude more interacting objects work out?  Ragdoll/projectile physics seen in BS1/BS2 was adequate.
* Native Language coding for faster logic execution (and for secondary AI Servers) Possibly JITJust In Time compilation from 'bytecode' ( multiple platform issues will always be with us - to make this hard to do systematically ).
* Compiled scripts ( byte code versus interpreted scripting )  with fragment loading for behavior scripting.
Bytecode with a VM (Virtual Machine) allows easier multi-platform ( note- Tablet/Smartphone variations adds yet more platforms ) - Denser script 'data' as there will be alot of load-on-the-fly between Server and Clients, which will run alot of the simulation's visual effects (and hopefully NPC AI stuff)
* Tablet/Handheld systems do not have to be '3D' ( for most part or many of them (smartphones) wont be powerful enough ) - 'Client' tablet computer operations may use partial/simplified (lower processing) Game Engine features ( might make difference for '3D' map interface used for 'offline' 'Team' task assignments ).   Tablets/handhelds will always be less capable than desktop systems - yet will be important aspect of this  MMORPG.
* Console platform capacity/capabilities may be overwhelmed ( especially with infrequent new generation of more powerful models in widespread use/possession by Players ).  Dumbing-down some features - will require more work to achieve game 'working adequately' for various older flavors of consoles.   Many advanced  features/Player experiences which count on greater computer machine abilities would be thwarted.  Simple lack of sufficient local 'disk' storage could be a killer (Gigs and Gigs of cached data).
* Object-based architecture/terrain, much more than previous games ( non-static persistent 'deformable' terrain, instancing bubbles, 'on-the-fly' generation/integrations ).  A generalized mechanisms rather than the usual limited hand-built/local-scripting/choreographed/canned/static content.
* A much more alive/interactive world than the existing crop of fossilized/ante-bellum MMORPGs.  Versatile placement and locking down of 'owned' Objects.   Periodic script 'behavior' execution for 'active' Objects ( now large numbers of them everywhere -- no objects are just 'part of the scenery' inert ). 
* MMORPG Server Component ( Solo and MP games don't have this problem ).  Communication bandwidth alone is a major challenge.  Interactions between multiple Players and the multitudes of NPCs, greatly increases the 'bookkeeping' processing and updating required.  Use Cluster processing servers with load leveling to make best use of processing resources ( which are significantly more than in existing MMORPGs ).
-
Advanced :
* Asset Atlas/Dictionary used on the Client end.  Disk storage of Assets allowing regular patching and on-the-fly  'as needed' new data loading ( newly published objects being added all the time and auto-expanding world  system ).   SSD (Solid State Disk) drives definitely will help with loading data once it gets into the Client machines 'Dictionary' ...   Once pulled from Server it becomes local data on disk for faster 'next-time' use.    Various streaming data schemes can be used for this real-time, and will be helped by the future expanding data bandwidths.
* Client-side AI for Player's "Team" subset of NPCs ( including optional/customized scripting modules ) to offload from Servers and have hundred-fold increase of AI capacity .   Assisting the Simulation by farming out AI processing might also be possible -- all the mundane 'filler' activity stuff that NPCs do when you are around (and it being much better mundane behavior as well).
* Voice Input - would improve control especially of NPC 'Team' Activities ( really more activation of pre-arranged tactics/activity modes that otherwise requires slow menu options interface. )  No fancy human talking more along the lines of single-word short-phrase activations  ( trying to avoid 'too many keys' syndrome many games are getting ).
-
Fortunately Computer Capacities Advance :
* More CPU, more multiprocessing
* More/faster Memory
* Better GPUs commonly in use by Players
* Faster/larger 'Disk' storage (and SSD speeds)
* Higher network bandwidths (though probably not better latency)
--- --- ---
Scripting Complexity - Programmed Adaptability/Versatility :
A big issue is that if you can, as a Player, (have the freedom to) do 'whatever you like' ( or even alot of what you might like/want to do ) the games logic/scripting has to be that much more complex, to have the game (Terrain/Props/NPCs) React appropriately to the possible Player's actions.
That goes for simple reflexes/effects on 'Dumb Objects' upto major Story Flow logic. I would estimate 2 magnitudes (100 X) more programming ( and probably a magnitude more processing resources ) be required to start to achieve that. At least a magnitude more maintained object data is required to get close to such 'freedom', to bring sufficient adaptability in the gameplay.
There is a good reason WHY current games are mostly choreographed/linear, with severe limitations upon the Player to prevent disrupting the predesigned story and events. Older games couldn't have sufficient computer resources ( even the much-touted Half-Life only had 'a bit' more reactive logic scripted than other games ). And even with our (now) greatly expanded CPU/Memory, the cost of programming and testing further partial improvements is prohibitive ( ie- the Square Law - just doubling the complexity of the program quadruples the amount of testing it requires - Making that expand faster than the programming cost ).
To have (realistic) appropriate reactions out of 'intelligent' NPCs - it is getting into heavyweight AI for them to shape their behavior to the things the player MIGHT do and the range of game situations. It is not just immediate reflexive actions, but (as someone mentioned) their motivations can be subsequently warped/changed, requiring their tactics and strategy to be adjusted in a logical way.
Similarly, things like deformable terrain and prop objects, which react to multiple effects being made upon them, make the visible presentation that much more complex to achieve. This includes secondary 'chained' effects and complex interactions when more than one affect is being applied simultaneously - even to simple non-mechanical objects.
Alot more detail, alot more logic, alot more headache for the people who are supposed to make it work (and alot more $$$ to create it).
--- --- ---
Why Do Many Original BioShock Level Maps Have Defects :
* The level designers did not bother to test/review their design - and if detected too late and major changes (too much work) were required it was too much work. 
* Interfaces between maps (elevator facings, building overlaps) are contradictory because many are made by different developers ( and it was not an issue for gameplay ).
* Because they are designed for the VISUAL interior spaces (cosmetic) and anything indirectly viewed is just incidental ( ex- the paper-thin walls in many places which are irrelevant to the Players actions ).
* Outside views are of less-than secondary importance ( they don't affect the played game ).
The MMORPGs would use Templates - Standard componentized construction ( where the template components can be thoroughly tested and then reused ). They would be designed to be correct in all details. There would be AutoTest (programmatic testing) features to verify requirements are met in their placement and other situational factors.
-
It helps to do Testing BEFORE things get far along - It takes much less work to correct errors/bugs/mistakes Early.
--- --- --- --- ---
.
.