Engine Specifications

= General Game Design Specifics = (Oxymoron?) Here is just a list of specifics that need to be supported by the game engine. For description of relevent GUI see: Propsals:Basic_Game_GUI

Global Time
The game has a time scale. Time passes as the character takes action, including but not limited to: Moving, Fighting, Talking, "Using" an item, "Using" an active skill, talent or perk, Eating, or Resting. In general, time is frozen while the game is awaiting player input. Mechanisms will exist in many modes where time is "run off the clock" in chunks. Example: "Rest for 8 hrs" button.

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 "ActionObjects") 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 ActionObject. Scenery is never grabable. Scenery can sometimes be destroyed by player actions or game events.


 * Local map exit grids might could be categorized as scenery as well? --MvBarracuda
 * Yes, although they are almost ActionObjects since they write to the game state --Zenbitz

ActionObjects
These are active "things" in the game world, typically accessed via mouse from the Local map interface (some ActionObjects can be accessed via other interfaces, the obvious example being the inventory interface). All functions may not always be available from all interfaces. ActionObjects may be Grabable (placed into a critters inventory, or another container ActionObject). All ActionObjects may some "game modifying actions" and characteristics of scenery (i.e, they can be scroll blockers, provide cover, etc. as well). Grabable ActionObjects 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 ActionObjects. Hidden ActionObjects may require an player action (i.e, search/examine) and/or skill role to become accessible. ActionObjects can often be destroyed or modified by player actions or game events. The game modifying activities may be coded at various levels. Core types of ActionObjects like weapons, ammunition will have their set of properties. Other items might have special "scripts" attach to them to allow them to get/set game properties depending on game state.

Searchables
These are intermediate between scenery and ActionObjects. They can be searched and may "produce" grabable or usable ActionObjects 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
AKA PC or "Avatar". This is the center of the universe. 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 ActionObject (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 ActionObjects 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 ActionObjects 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
AKA 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.

Containers
These are ActionObjects that contain other ActionObjects. 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.

= Dialog/NPC Interaction System Specs = This is a set of specifications for dialog options to be added to the FIFE engine.

Minimum feature set
This is a list of features that represent the minimal requirements for some kind of RPG game. It is roughly based on fallout1/2. Someone with more experience with Arcanum or another cRPG might want to add / subtract ideas. Not all of these must be implemented for demo version, but all should be considered in software design phase.
 * Player should be able to click on an NPC to initiate dialog with any "person" (and possibly other things).
 * All NPCs should have at least a response to this dialog initiation - even it it's "please don't bother me".
 * Some NPCs will have more detailed "dialog" interface enabled. These are cases where the player could conceivably "get something" out of the interaction.  "Something" here could be simply information, but also "quests" (including jobs), and items/money.  A series of player dialog options interleaved with NPC responses from beginning ("talk initiated")  to "end" (a traversal of the dialog tree for that NPC/game state) is called a "conversation".
 * "Bartering" is a sub type of dialog that can be initiated with a wide range of NPCs - it should open a (distinct) interface whereby the player can offer trades of goods for other goods. An example gui of this would be where player drags items from his inventory to an "offer board" and also drags items from the NPCs inventory to the "offer board" and takes a "attempt trade" action (probably a button click).  The NPC evaluates the trade, and gives a yes or no answer.  Player can then modify the deal, and try again.  Bartering is not the only way to transfer items between characters.  More complicated models are possible (see below).
 * Dialog options available to both the PC and NPC are dependent on _current_ game state (you can't ask about X if you you don't already know about X). The "conversation" itself may modify this game state - such that certain dialog options made by the player can change future responses of the current NPC (as well as others).
 * Dialog can (in some circumstances) "end" in activating turn-based combat (including surprise attacks)
 * Dialog can loop back to previous states within the same conversations and in repeated dialog initiations.
 * Dialog may in some circumstances, activate "journal" entries - that is to say, make a note for the player to keep track of a "quest"
 * Dialog may in some circumstances write to the character (PC) state, or even NPC states (for example, healing, transfer of carried items). This can include PC "knowledge" of new locations "Can you mark the site of the weapon cache on my map?"
 * Dialog options may be attached to (instantaneous - in player time) "tasks" which will influence further dialog.  These tasks need not read/write from the game state (but will at least "read" from the character(s) state).  Example:  A dialog option might be associated with an "intimidation" task based on various PC and NPC statistics and skills and possibly coupled with a randomly generated result (see Zenbitz:Thoughts on task resolution as well as Proposals:Mechanics ).  These tasks may take a finite amount of "game time" (fade out?)

"Nice to haves"
These are additional features that could be very useful, but at the moment are not required. As time progresses, these items may move "up" to Minimal requirements, or "down" to "Pie-in-the-sky"
 * Ability for game engine to initiate dialog with the player (via NPC or other event)
 * "Shotcuts" via floating text (no Player dialog choices) to indicate to player that there is nothing he can influence (at this time...)
 * Random chit-chat via floating text
 * Gossiping system where by news spreads from place to place and NPC to NPC.

"Pie-in-the-Sky" features
This is low priority stuff that someone, somewhere thinks might be cool. I would not implement anything past "hooks" for anything here.
 * "Conference calls" - where PC converses with multiple NPCs.  I have no "use case" for this, but it would be cool
 * Dynamic conversation AI - NPCs (in addition to hard coded dialogs) have needs, wants, goals, friends, enemies - these can be cranked upon to generate some "generic" dialog "plots".
 * See also: Zenbitz:Really_deep_thoughts_about_NPCs_and_their_disturbing_personalities