Once again, I’m back to development. I’ve had some re-examinations of the data structures with some other experience and thoughts.

Here’s my plans for changes.

Translations

Currently, translations are separated out into their own set of files. This works great for translators, but for the core engine it kind of dangles outside the core structure.

Instead, I’ll look at making the “string” type be either a “user string”, meaning that the player enters text, or is a “static string”, which means it’s a translatable string. The different translations are stored as sub-paths by the language/region.

The logic for translation lookups will remain the same, but will work off of the static string path location.

There will need to be optimizations made for quicker lookups, but that will come later. The design will need to allow lookup optimizations.

Data Types

I’m investigating the basic data stored in the tree. I still like the idea of the tree to store everything, with different paths having their own control mechanisms.

However, some aspects of the tree need to be simplified. It’s currently far too difficult to construct a story in a meaningful way.

My notes based this reexamination has these data types:

  • Typed Constant Floats, fuzz, ints, static strings, datetime, single value from an enum, menu ID, player option chain ID, player choice list ID, trigger ID, and event ID.
  • Typed Calculation (result of the calculation) static string, int, float, enum map, datetime, datetime delta.
  • Typed Variable reference to an ID of a specific type, datetime, datetime delta, int, float, fuzz, user string, deck.
  • Condition numeric comparisons, “not”, “contains”, “and” and “or” of sub-conditions. These always have a parent, from which the condition uses as a base for the relative variable paths. Conditions generate a signal that is passed to the parent. The condition can be active or inactive; only active conditions send signals.
  • Trigger Triggers are one kind of parent for conditions. Triggers have an optional cool-down condition, for after a fired trigger to indicate it can fire again. a “can fire” condition, and a list of triggered event IDs. The conditions can have an optional parent path value, to allow the same trigger to be applied to multiple things. Triggers are always active, meaning that the conditions are monitoring every change to the affected values in the tree. The trigger type is generally “value changed”. Could be based on a signal system, instead.
  • Event Implies a user-input series of happenings. When it starts, it has immediate value effects (changes variables in the tree immediately). It runs an ordered list of UI and media stuff (animation, character speech, charts & graphs, etc). Then it has a player choice list, which could be empty or just a simple “ok” option for player feedback.
  • Player Choice List A static, ordered list of player choices.
  • Player Choice It has conditions that allow it to be visible and enabled. It has a label, icon, description, etc. It also has an event for when the player chooses it.
  • Card these take the place of “objects”, and are the things stored in a deck. These are containers for typed calculations, typed variables, and triggers.
  • Card Generator defines how to create a card. It defines the variables and valid conditions for the variable values, and the list of triggers to associate with the card.
  • Deck A container for cards. Each “slot” in the deck holds a card and potentially a card count (for stackable cards). It can also have triggers on changes in the deck contents (to allow refilling the deck), which can be used to keep a deck with a “final” card.
  • Deck Generator Fills a deck with cards. This uses one or more card generators, but the details for how this will work still needs clarification. Probably, it will be a deck generator that knows to create a single card or a collection of cards. Could also be that a deck generator is independent of the deck except for initial creation; other uses for the deck generator will be done by events.
  • Menu Defines the location & other display properties for a player choice list ID. This list ID can be swapped out. Multiple menus can be on screen at a time.
  • Menu Set Stack Multiple menus may be on the screen at a time (a “menu set”). These are pushed and popped to allow for sub-menus and sub-actions, in the form of a stack. Each story has a menu set stack.

The concepts of story, side-stories, and obstacles are very important and need to be retained.

However, the concepts of the “deck” and “deck generator” are antithetical to the general premise behind the generate-as-needed matching conditions, so that won’t work. However, some of the concepts of signals and player choices and menus are very usable.