Neohack’s Data-Directed architecture easily and without touching main game logic allows complex interactions and multiple-use items which are not possible in most roguelike games and achievable only through extensive case-by-case patching of exceptions into main game logic in other games.
I would like to see a few examples of such interactions. Guess it is already implemented, not just planned?
Yes, it is implemented. When an "event" happens, it involves up to a half-dozen different "actors" in different roles. Each "actor" has a set of attributes, which may include "triggers" containing a pointer to executable code to be executed when that actor occupies that role in an event of that kind. As an example of an action with a nearly-maximal set of actors, when an arrow is fired, that's a 'fire_ranged_weapon' event. You have the archer in the "Instigator" and "Subject" roles, the bow in the "Agent" role, the arrow in the "Agency" role, and the target in the "Object" role.
The main game logic is sort of formless in its generality: it gets an event off the schedule, checks the involved actors for "before" triggers, executes them if they exist, performs the action itself, checks actors for "after" triggers, and executes them if they exist. Rinse, repeat until "end of game" action is processed and the schedule becomes empty. Any action or trigger can put more actions on the schedule, or reschedule/remove actions that haven't come up yet. "Before" actions can change parameters in the closure of the event that they're triggered by (for example modifying the damage in a damage event) before that event is actually executed. "After" triggers can do things that depend on the outcome of the action(for example setting an amount for 'vampiric regeneration' based on the amount of damage done).
As an example of how general this can be, someone puts on a pair of blink boots (a 'wear' action). The blink boots have a trigger A that gets called when they're the 'Object' of a 'wear' action. Trigger A sets a trigger B on the wearer. Trigger B gets called whenever the wearer is the 'Subject' of a 'walk' action, and subject to some conditions (still wearing the boots?) either schedules an immediate 'blink_teleport' after the 'walk' or (not wearing the boots?) removes trigger B from the wearer.
Whatever interaction or use you want to build into a given kind of 'new content' actor, you do that by defining trigger routines to be carried by the actor, and possibly new action routines as well. Then you define an actor-init event that creates an actor with those triggers, and a content-init event that registers the actor-init with one or more map creation tables so that the map creator will create actors of that kind with some probability. A 'sed' script in the makefile detects and creates a list of all the content-init events, and they get called during game initialization.
So a valid 'content' file is a file of C source code that contains a content-init definition and whatever stuff that function refers to. You drop it into the 'content' directory, run 'make', and the executable that gets built now contains your added content and understands all the ways that content is supposed to be treated specially in every event.
What did not happen was the need for any 'diff' applied against the main game logic in a way that might break any other content, or the need for any part of your content to be out there in the main game logic where a further diff from some other source might break it, or the need for some maintainer somewhere to figure out how to merge diffs or what order to apply them in. If you define content that doesn't literally and deliberately depend on other content, building the game with or without it is as simple as adding and removing files from the content directory before running 'make'.
