Game engine rules

This is a draft of very general, high level functions of the game engine. Operations is hereby defined as the part of the game engine that provides a framework for the rest of the role-playing game mechanics (combat system, NPC system, dialog system, character creation and advancement). These could also serve as a generic framework for any 2D isomorphic using the PARPG engine. It will also serve to delineate choices necessary to help pick a low level engine (i.e. FIFE vs. GemRB). Much of this is inspired by Fallout 2.

Time
The game has a time scale. Time passes as the character takes action, including but not limited to: moving, fighting, talking, using items, using skills (or talent or perks), resting or standing on a local map. In general, time is frozen while the game is awaiting player input. Mechanisms will exist in many modes where time is accelerated in chunks. Example: pressing the "rest for 8 hours" button.

Modes
A list of user interfaces/modes between the player and the game and how it affects time. Some of these interfaces may be combined in a single screen, for example: HUD and local map or character status and inventory


 * Character editor : PC design screen before the game begins. If changes can be made to the PC in-game, they will be made here too. Time is paused.


 * World map : Zoomed out map on which the PC moves around the game world. It is composed of tiles which represent either generic locations (empty or random encounters) or story locations. Story locations and PC are represented by geometric shapes. The map scale might be on the order of several km per pixel. Possible actions besides moving and entering locations could be eating, hunting and resting. The game clock is frozen, unless the PC is active.


 * Local map : Isometric view of a location where the PC moves around a local map. This is the scale where player interacts with objects and NPCs by fighting, talking, looting, examining, using skills or items and probably more. It should be possible to support more than a single time/distance scale with ~identical interface. Local maps will have a combat mode where the action becomes turn-based: game time freezes while player chooses his actions. When PC and NPCs take actions, time is run off the clock, but stopped again when awaiting input from player. Outside of combat mode, time progresses slowly enough for the player to do interrupt with anything "important".  This "Real time" is necessary to prevent player from having to interact with the interface to wait for a NPC or other "timed" action to occur.


 * Local mini-map : Overview of the current local map with a larger scale. It is used to help the player navigate local maps after they have been visited. The mini-map could highlight objects, NPCs and eventually level transition areas. Time freezing depends on


 * Dialog / Complex item interaction interface : this is where a player talks to NPCs or other wise uses a dialog-tree based interaction with a game object. It is exclusively reached via a local map - by some player action on an object (e.g, a "talk" action on a person). Time is frozen while waiting for input, but various "dialog choices" by the player may advance the game clock.


 * Barter interface : this is where the player swaps goods and/or money between himself and another character or object. Typically, game time is frozen during use of this interface.  However, a fixed (or variable!) amount of time may be "run off" the clock when exiting.


 * Character status interface : this is where the player interacts with his own character during the game. It should be visually related to the character generation interface.  It is typically "read only" but may have "writable" aspects (possibly to select character improvements).  Time is frozen when using this interface.


 * Quest status interface : this is where the player tracks his progress on "game assigned tasks". Tine is frozen when using this interface.


 * Character inventory : this is where player organizes his stuff. Items can be "used" or "dropped" from this interface.  Some "combining", "repairing", or "use skill on X" actions may be implemented from this interface as well.  Time is typically frozen when using this interface, however, a fixed or variable amount of time may be run off the clock when this interface is closed (depending on the actions taken by the player).


 * HUD : This is an "dashboard" type interface where some subset of character, inventory, (inter)action, and "metagame" (i.e., save/load/quit) functions are available to the player. It would presumably be attached to a Local map and/or World map "viewport".  Some actions taken via this interface may cause time to pass, the clock to stop, or the clock to restart.  It should include a text console where messages are relayed to the player based on various game events (including but not limited to player actions)

Named Locations
These are locations where the meat of the game occurs. They will typically be either indoor (including underground) or outdoor locations. Most of the scripted behavior of the game (see "objects") occurs here. The characters should be as deep and detailed as possible. Locations may be connected locally (some areas may need to be unlocked by interaction or skill use) or via the Worldmap. It should be obvious when you about to leaving a local map to another one or the world map (as long as there is a finite loading time associated with the transition). If the loading time can be done unnoticeably on "average" hardware (whatever that is), then it could be hidden from the player.

Generic Locations
These are locations "between" named locations on the world map. They might be generated randomly (from templates) if something 'happens' in them. This random generation should only occur once per tile. Unnamed tiles on the world map should be assigned "categories" (terrain types) representing algorithms to generate the details of the generic location. They could conceivably have connected "sub" locations. As an alternative to random generation from templates, real geological information could be used - possibly modified by designers (if the game is on earth, the data is available, the storage space doesn't overwhelm the game). Whatever the method - there should be little or no design/scripting effort spent on making these locations unique. If there was, they would become "Named" Locations. Random or semi-random generated encounters typically occur on generic locations. If so, tiles should be assigned an "encounter" class which determines type and frequency of encounters. They are otherwise just like Named locations

Scenery
This is specifically stuff on a local map (either type) that the player cannot interact with. Example include but are not limited to scroll blockers, "cover" (i.e, stuff that can be hidden behind), trees and other flora, floors, ceilings, some walls, pits, or holes. Basically, everything that does not have a script attached to it, but can still be seen in a local map viewport is scenery. Scenery _can_ have descriptions attached to it, either terse or verbose. If a skill is required to get more than the "verbose" description, that "thing" is actually an object. Scenery is never grabable. Scenery can sometimes be destroyed by player actions or game events.

Objects
These are scripted "things" in the game world, typically accessed via mouse from the Local map interface (some objects can be accessed via other interfaces, the obvious example being the inventory interface). All functions may not always be available from all interfaces. Objects may be Grabable (placed into a critters inventory, or another container object). All objects may have various unscripted parts and characteristics of scenery (i.e, they can be scroll blockers, provide cover, etc. as well). Grabable objects can have a non-zero weight and/or bulk (i.e, they effect encumbrance of critters, containers, or vehicles). A simple mouseover action by the player will USUALLY distinguish scenery from objects. Hidden objects may require an player action (i.e, search/examine) and/or skill role to become accessible. Objects can often be destroyed or modified by player actions or game events

Containers
These are objects that contain other objects. Some of them may be grabbable (i.e., a small box, bag, or back pack). Some of them may move (Vehicles) with a critter (including, obviously) the PC. The have a capacity in terms of weight and/or bulk of contained items. They posses an "empty" and a "full" encumbrance (weight/bulk) and may be contained in/contain other containers. They can be searched, opened, locked, unlocked and destroyed - but not all containers have these states.

Areas
These are intermediate between scenery and objects. They can be searched and may "produce" grabable or usable objects in a scripted or random fashion. A searchable is very similar to a container, but represents a large generic area, like a ruin, or a forest. Searching them might be accessible from the worldmap interface.

Player character
The player character (PC) Generally, the viewport(s) will be drawn with respect to the PCs locations. Distinct from the player, who the the one pulling the strings. Player characters are critters, but they have many other special functions and menus that are not shown/available for other critters. The PC has the full range of possible metrics (stats, skills, attributes, talents, perks, goals, motivations, reputations, etc., etc.)

Critters
These are animals or other entities that "appear" living. They typically have movement capabilities. Many of them can be talked to. Many of them can be bartered with. All of them can be attacked, and (in principle) destroyed. "Killing" a critter transforms it into a Dead Critter - which may be either another Object (like a container) or simply scenery. They will typically have a subset of the PC metrics - although they may have special powers and/or items that a PC cannot obtain. They can have complicated behavior scripts - including combat AI, programmed response to stimulus, random response, friends, enemies, etc. They act as containers (although they may be empty - and may not be freely accessible). They may resist action taken upon them (or other Objects they are scripted to "watch"). They may have schedules based on the game clock. They may be in a quiescent state (sleeping, unconscious, crippled) and have limited or no actions available to them (or upon them). Skills and Objects can be used on them, but they may not (in fact probably will not) have scripting support for all possible player actions involving them.

Non-player characters
Non-player characters (NPCs) These are heavily scripted characters, with special features to distinguish them from critters. In some cases, they may join forces with the PC (permanently or temporarily). They are usually the granters of quests or missions. They almost always can be talked to with dialog trees. They are otherwise a sub-class of critters.