CardFRP - Component Overview
(and required functionality for each class)

CardFRP is an underlying (not player-facing) engine that simulates the attributes and interactions of characters and objects in locations. It is intended to implement mechanics similar to those of FRPGs where players take actions by playing (physical) cards from a hand of available actions.

This engine implements:

• objects (e.g. weapons and artifacts) with capabilities and attributes
• actors (PCs and NPCs) with abilities, attributes, and objects
• actions (e.g. search, bribe, attack), possibly enabled by objects (e.g. a sword or a scroll), which (when performed by actors) affect the attributes of other actors and objects
• contexts (e.g. rooms, villages, kingdoms) potentially nested, with attributes, containing objects and actors, where interactions take place

This functionality is implemented by a few (Python) classes:

• GameObject, which implements most objects, and serve as the base class for:
  • GameActor, which implements PCs and NPCs.
  • GameContext, which implements locations, containing objects and actors.
• GameAction, which implements interactions between objects and characters in locations.
• Dice, which implement rolls according to common formula (e.g. "3D6+2", "3-20", "D%", or even "47")

GameObject

A GameObject ...

• has a list of (string) verbs that describe the actions of which it is capable
• is capable of receiving, and computing consequences of an action
• can posssess or contain other GameObjects

• return a list of supported GameActions
• update, search, and return the list of contained GameObjects
• accept a (non-ATTACK) GameAction and compute and return its consequences

GameAction

A GameAction represents an interaction between players and/or objects. A played GameAction has:

• a verb (which might be sub-typed or compound)
• an object (or actor) that enables it to be performed
• an actor who initiates it
• an actor or object that is to receive it
• a context (or location) in which the interaction takes place

It is intended that the interaction functionality in the base GameAction and GameActor classes be sufficient to implement most typical gamic interactions. These classes support two basic types of action:

• combat (verbs beginning with ATTACK.)
  • Objects (e.g. swords) and initiators (e.g. PCs and NPCs) have ACCURACY and DAMAGE attributes.
  • Recipients (e.g. objects, PCs and NPCs) have EVASION and PROTECTION attributes.
  • If D100 plus the recipient's EVASION is greater than D100 plus the (combined) ACCURACY attributes, the attack fails.
  • If the (combined) DAMAGE attribute(s) exceeds the recipient's PROTECTION, the remaining DAMAGE is subtracted from the recipient's LIFE attribute.
  • If the recipient's LIFE goes to (or below) zero, his alive attribute is set to False, and his incapacitated attribute is set to True.
• all other interactions
  
  • Recipients (e.g. objects, PCs, or NPCs) can have arbitrary attributes, that can be affected by interactions and affect behavior (e.g. MENTAL.FEAR or VERBAL.FLATTERY). Attribute affecting verbs have the same name as the attribute they affect.
  • Objects (e.g. scrolls) and initiators (e.g. PCs and NPCs) have POWER and STACKS attributes that reflect their ability to initiate such interactions.
  • Recipients (e.g. objects, PCs and NPCs) have RESISTANCE attributes.
  • If D100 plus the recipient's RESISTANCE is greater than D100 plus the (combined) POWER attributes, the action fails.
  • This test is performed for each of the delivered STACKS. For each STACK that gets through, the recipient's corresponding attribute is increased by one.

Characters will have different skill levels for different actions. ACCURACY, POWER, DAMAGE, STACKS, EVASION, RESISTANCE and PROTECTION attributes can be sub-typed to reflect these differences:

Attribute	Meaning
DAMAGE	amount added to all attacks
DAMAGE.GRAPPLE	amount added to grappling attacks
ACCURACY.ARROW	accuracy bonus when using bow
EVASION	ability to evade all attacks
EVASION.STAB	ability to evade stabbing attacks
PROTECTION.POISON	ability to resist effects of poison
POWER.SEARCH	ability to find hidden things
POWER.MENTAL.FEAR	ability to cause fear
RESISTANCE.SEARCH	how well hidden something is
RESISTANCE.MENTAL	resistance to all mental attacks
RESISTANCE.VERBAL.BRIBE	specific resistance to bribery attempts

In addition to action verbs having sub-types, they can also be compounded ... so that a single action delivers multiple verbs. A poisoned dagger might, for instance, enable the action ATTACK.STAB+ATTACK.POISON. When this action is initiated:

• an ATTACK.STAB will be delivered to the recipient.
• if that is successful (not evaded and not absorbed by armour), an ATTACK.POISON will be delivered to the recpient.
• the delivery of successive actions ceases with the first failure (evasion or absorbtion).

GameActor

GameActor is a sub-class of GameObject. In addition to those inherited capabilities and attributes, a GameActior

• has a current context (in which it is located)
• has a list of supported VERBAL interaction verbs, that can be turned into GameActions and used by a requesting GameActor
• is capable of initiating any available GameAction with designated recpient.
• is capable of accepting ATTACK GameActions, to process EVASION, PROTECTION and DAMAGE. Non-ATTACK (attribute affecting) GameActions are processed by its (GameObject) super-class.

GameContext

A GameContext is another sub-class of GameObject. The interesting characteristics it adds are:

• it can keep track of PCs and NPCs who are currently in that GameContext and return lists of them to any requestor.
• it supports a list of contained objects (including hidden objects) and accepts SEARCH GameActions to discover them.
• like a GameActor it has a list of supported interactions (e.g. SEARCH) that it can return as a set of possible GameActions (to any requesting GameActor)
• it can have a parent context. A room might be within an Inn, which might be within a village, which might be within a forrest, which might be within a kingdom.
  • any attribute get() that it cannot satisfy will be passed up the chain of parents
  • the list of possible_actions() that it returns is the union of its, and those of all of its parents.

Note that all of the API documentation and class diagrams associated with the (above) class URLs were generated automatically (with Epydoc) from the python source code in the (above) sample design submissions. The availability of such tools is a strong incentive to learn the languages of Doxygen and/or Docstrings.