Scattered D&D Notes from Old Website

May 27th, 2019 dnd 591 games 7 lisp 4

These are from early 2018, or earlier.

Inventory Implementation

Consider writing functions which generate an inventory characteristic of a given NPC which can be run to produce their inventory when they are first created. Such functions could then be re-used to describe the possible kit for allied NPC types, such as when a player is searching for hirelings.

Some inventory contents, as well as slots on the body, could be integrated into dynamic descriptions of a character.

Dynamic Description

We could use this toy function to provide a basic textual description of a character.


(defn describe
[char]
(concat "This is a " (:sex char) " " (:race char) ". In its hands are " (right-hand-contents char) " and " (left-hand-contents char) "."))

If we call this function on the data representation of a male bugbear carrying a crossbow and a torch, it would return "This is a male bugbear. In its hands are a crossbow and a torch (lit)." Underlined items are those which were chosen based on the bugbear's data.

Observations Depend on the Observer

Description functions such as this one would need more complexity to serve a real game, but that can be handled in the future. What interests me most is the possibility of specializing a describe function so that the description of the observed entity depends on the observer's powers of observation!

Here's an example. Suppose there is an in-game sword which is curved in a distinctive style only used by Spaniards. Suppose further that this model of sword is recognizable as such by certain people: those with a Swordsmithing skill; those who are from the Spanish region where the technique originates; and those who have Diplomacy skills related to Spain. Then the description of the sword could be simply "sword" to those who do not have the knowledge, and "Spanish curved sword" to those who do have the knowledge.

2019-04-05: Since writing this note, I've learned Inform 7, a tool for creating interactive fiction in which it is simple and natural to vary text descriptions with the stats or characteristics of the observing entity. Agent-based simulations are also a natural fit for Inform, as long as one keeps the number of actors small, so I'm using it for some other things now too.

Interaction with Economy

If the above sword was looted, and the looter sold it at the market, should the economy program recognize it as a "sword" or as a "Spanish curved sword?"

Nowhere near implementation on this, so I can simply say for now that if the character knows the sword's true nature, it can be sold for the specialty price. Otherwise it is sold as the generic equivalent (such as undifferentiated "earthenware" for a fine clay pot.)

The rule of shared information

To the WHOLE group of characters who are present and whose players are present, the BEST knowledge of the scenario is communicated, as perceived by the character with the most aptitude for perceiving the scenario details in question. E.g. if a group is traveling with a character who has strong hearing, unless there is curently a cost to communication, such as in combat when talking costs AP or as in any tense scenario where noise or wrong moves could mean discovery, then the player is informed of the effects of their special hearing such that the whole group is aware of the information and can act as if the strong-hearing character has communicated it to them.

Creating Player Characters

(defun mk-human [name] (assoc (six-scores 'basic) :name name) [name social-type] (assoc (six-scores social-type) :name name))

Actions

On every turn, a list of game actions is available to each character. The exact contents of the list change over time, and depend on character-specific factors such as:

skills
ability scores
special abilities
class
whether or not character is in combat
whether or not in melee

Everything that a player chooses to do must ultimately be expressed in terms of game actions, and chosen in the game's interface. The desire to "move over those rocks and attack the bandit" would be input as "_move_ to hex 1010, 1011, 1012, and then attack the human male bandit in hex 1013." In that example, move and attack are the game actions which are then resolved.

Equipment Slots

When an item is equipped, that item takes up a particular one of the character's equipment slot. Unequipping frees that slot up again. Some items have slots of their own, which the character (or others!) can access. For example, a belt can be equipped at one or both of the waist and shoulder slots. Each belt gives the character three belt-mount slots, allowing the belt to be used for its main purpose of stowing things for quick retrieval. In turn, a scabbard can be equipped to one of the new belt-mount slots, which, in return for taking up the belt-mount, gives the character a equipment slot specialized for stowing swords (perhaps of some particular type.)

Maximal Usage of Data Structures to Represent In-Game Concepts

not just in-game objects, but also things like spells (which represent in-world effects) e.g.

(defspell [caster-lvl]
    {:name "Fire Ray" :targets (min 10 (+ 1  caster-lvl))}) ; i.e. a MAX of 10, which would be how the "English interpreter" would describe it

English Interpreter

For generation of human-facing documentation from regular data structures such as spells or items, it would be useful to have functions for converting basic lisp expressions into English.

I would call such a thing "Englisp." That's my idea, folks: don't even think about stealing it, or I will put you in jail. Warning: not-quite-real code ahead.

(defun describe (form)
    (case
        (cdr form)
            ('min)
                (concat "the smallest of:" "\n- " (describe x for each x in the body)
            ('caster-level)
                ("the caster's level"))))

(describe (min 1 caster-level))

In this case, caster-level is just a symbol that needs to be made user-readable in an Englishy way. Down the line, it could be evaluated in terms of the logged-in user's player character, so that you could see immediately how many targets are reachable if you yourself were to cast the spell. This ties into some of my earlier thinking about a webpage for the Sneaking rules where the values used in the calculations would be dependent on what levle you chose in the sidebar "variable adjuster" for the page. Unlike a paper rulebook, examples in a live-updating digital game can add a section on how the rules apply to your character AS OF RIGHT NOW.

by Maxwell Joslyn