Title: Future Improvements

The following are ideas that are shelved for now, but might be revived later.

Section: Minor Improvements

Topic: Indexing

A lot of Marlinspike processing is pretty intensive.  Indexing could help here...

* The EventHistory could be indexed (hashed) by scene type or other attributes.


Topic: Conversations

I'd rather that Talking to everyone produce a single Talk and/or Tell deed, with mutiple SUPPORT/OPPOSE recasts for each person present; instead of the current practice of turning each group Tell into a Tell to each individual at the verb level.  (But the current way works and is already in place, so I'm going to leave it there.)

Topic: Import tied to Affinity Change

In the current implemenation, this is not possible since import is global for all actions or predicates of that type.  (In retrospect, I could have moved import into the event, as _detail_ has been.  But it's too far into the implemenation to bother making that change at this point.)   

But in future, I'd like to easily vary import of an action according to context.  The most important piece of context is usually what sort of affinity change it produces on the target (which usually indirectly determines the affinity changes on any bystanders too).  In MS2.0, I should consider making these two things dependant on each other (or even the same thing for actions).



Section: Marlinspike 2.0

This version of Marlinspike was always meant to be a simple prototype.  Here are some ideas for the next incarnation.

Topic: Different Language

MS2.0 will be more modular, able to work with different front-ends (see below) and with options for other technologies for things such as NPC modelling.  I think Java would be the best choice for this.  I know Java very well, and there seems to be a lot of AI sub-systems that work with it.  

Also, there are a number of different scripting languages that can be used to directly work with Java objects.  The main two contenders for me were JavaScript/Rhino and Python/Jython.  JavaScript's object literals would probably be handy, and it has other intriguing language features (such as prototype-based heirarchies, etc.) that I'd like to explore some day.   However, after some thought, I think I'd (currently) go with Jython.  Python seems to be generally better documented (with a clearly defined language, rather than an assortment of dialects--JavaScript, JScript, ECMAScript, etc.) and more general library features.  Also, I know Python already and I suppose I would rather become an expert in a few different languages rather than just dabble in a number.  (Of course, others could plug in different scripting languages if their preference differs.)

So the idea is that the core Marlinspike classes (and possibly a library of useful other classes, such as the current DReaction, DRecastTrigger, DAffinity, some actions, etc.) would be in Java.  Then I could explore using other plug-ins to script or interact with these.


Topic: GUI-based World

Find some sort of 3rd party graphical world engine, such as Unreal, Neverwinter Nights, etc.  Preferably something open to hacking and that other IN projects are using, but that is well-established, documented, and stable.  

Many of these are combat-focused, so this may limit the possible verb set, but some sort of context-specific verbs (sort of a USE) and conversation options could expand these sufficiently.

Will be real-time, rather than turn-based.


Topic: Verbs as objects

* Clarity of input affordances

With Inform, it is not clear which verbs can be performed on any given object.  In alpha testing, users often mistake a parser problem as the object not supporting that verb.  This is the basic problem: you can't see what an object can do until after you type a command ("correctly") and see if it works.  Now, in some genres, discovering just what you can do to an object is part of the puzzle/fun; this has largely been true in traditional IF.  However, in IN/ID, we're trying to focus on NPC interaction and story, not puzzle-solving.

Chris Crawford has as already proposed a solution to this: a reverse/just-in-time parser approach [I forget the exact term he used].  In short, the parser lists only the possible choices at any point in "sentence" construction, so 1) the user can see all possible actions and 2) the user can never create a syntactically-invalid command.  

This would work much better in a GUI environment anyway.  I could see either a NWN-like radial approach or else just simply a right-click linear menu list.  You could click on any object ("the direct object") and get a list of all the verbs you could do that object.  Then, if necessary, any relevant "second objects" to use to do that.

Alternately, you could click in some spot (upper-left corner; or just have a drop-down bar like the old Space Quest games) to get a list of all possible verbs right now.  Then, for a verb, choose a direct object in range, and then second.

This simple, linear menu option could also be very easily translated to the input capabilities of hand-held devices.  (ID, like a good book, should be playable on the move!)

* Clarify of authoring potentials

Each world object should have "slots" for the verb objects it supports.  That is, if an object has a slot, then the object can have that verb done to it at some point during its lifetime.  The slot would be responsible for customizing the details of the verb when happening to it.  

However, not every slot may be filled by a verb at any given time.  For example, a door might have an "Open" slot, but will not have an "Open" verb object in the slot until it is unlocked.  Thus, the system can easily query an object for all its filled slots to see what can be done to that object right now.

If there is a limited verb set--basically, only those verbs usable in a particular game, rather than the broad general categories of Inform's default library [though admittedly only the small Group 2 subset of those verbs actually happen unless prevented]--then the author will have a better idea of potential reactions from any object.

Obviously, it'd be nice to have some sort of boiler-plate behavior and classes to rely on.  But this should be seen as a prototype/template/starting-point with the built-in assumption that there will be exceptions to some of its rules.  But, for examples, Items would all have slots for Examine, Take, and Drop and the rules to manage those.  But then something like a ToffeeApple [an Inform DM4 example] could easily modify/override the Drop rules so it can't be dropped.

Also, certain state changes should have default ramifications.  An object moved into the inventory can't be Taken from there.  Something that stops being scenery can suddenly be moved around.  [But perhaps these changes should be handled by the default Verbs and perhaps some special back-end system state-change Verbs.]

[This topic reminds me of my old GiRDLe ideas; maybe look into that a bit too: modular/expandable world actions.  Could have verb synonyms: punch, slap, etc for Attack, which some minor detail difference but that map to the same parent Verb for processing.]


* Mechanism details

There are some different possible paths here.

*First Idea:* Basically, an object has a list/hash of verbs it supports ("slots").  If currently null, then that slot is empty/inactive.  Otherwise, it can contain a (reference to) a verb object.  Most of the time, this will be the default Verb object.  (The default verb would have the standard behavior.  For example, Drop basically means move the direct object from inventory to ground.)  However, the object can customize what it wants to do by providing its own Verb object instead.  (Of course, this custom Verb could leverage the default Verb to do what it wants done.)

*Second Idea:* Alternately, I could go with something more traditional.  [Like Inform; need to look at Platypus perhaps.]  In this idea, a simple boolean represents whether a particular Verb slot is active or not.  If it is, then the Verb can be performed.  The object can provide a _before_ and an _after_ rule.  The _before_ could even abort the verb, such as for unexpected things like trying to open a trapped door or one with a loose/trick knob.  But most of the time, _before_ and _after_ rules can just adjust an special state as necessary.

*Regardless* of which design, there are a few other considerations.  Other objects will need to _react_before_ and _react_after_.  This is for things like a World in darkness preventing certain things [probably affecting actors instead of objects], or an alarm that goes off after a door is opened.  This would be best using some sort of EventListener model, where objects could register themselves for certain verbs done on/using other objects.

Also, actors (either PC or NPC) should have slot-like structures for the verbs they can currently perform.  (For example, this can change when bound, incapacitated, etc.)

On the UI, inactive verbs/empty slots could be showed as grayed out.  When selected, it gives a reason for why that verb can't be done right now: "It's too heavy.", "It's nailed to the wall right now.", etc.  Users should be able to change this to listing such verbs grouped at the bottom of the menu, in a separate menu, or not at all.

There will need to be a simple, quick way to define objects.  (Inform does this pretty well.)  Perhaps some sort of Jython or JavaScript or similar?


Topic: Separate, cross-platform DM

The drama manager (that is, essentially all of Marlinspike) will be written in a more robust language (probably Java).  Might be able to leverage some other embedded languages for scripting, logic, etc. (python, prolog/etc.)  Also, there are lots of other Java-based AI/agent-wrangling opions.  This means Marlinspike could be used with different front-end/world engines.


Topic: DM-to-World bridge

Will need a translation/connection from separate DM and the world.  Some ramifications...

* DM can no longer prohibit verbs.  

This irritation is not as bad as it once was (see <Working Notes>), but still consider it. 


* World-to-DM: Reporting verbs.

Dropping verb denial would really simplifies things: the world just has to recognize verbs when they occur and alert the DM for casting and response.

Certain verbs will change in a GUI situation, of course: not reporting all player movment, but simply entering/leaving certain broad locations/rooms or proximity to certain objects.

* DM-to-World: Manipulating the world

DM may need to introduce NPCs, props, or locations--or at least open access to them or move them from their starting positions.  Similarily, it will need the ability to change object states during the course of scenes.  (If NPCs are sufficiently capable in the world, could limit all DM interaction to working through NPCs--possibly with an invisible "Fate" NPC for any weird hacky things that arise?  DM then becomes only a Director)

The DM should invoke _behaviors_ in NPCs, etc: animation sequences, conversation snippets, etc.  This is so the DM can compose reactions and scenes, but then leave movement/animation details to the engine.  (Don't know how fully de-coupled the world and DM will be though, since the world will determine what behaviors are available, thereby dictating scene construction.  So can't simply plug same DM/story into a different front end.   Oh well...)

* DM-to-World: Querying the world

Along with manipulating, need to be able to check on current state.  Like manipulating, these needs to be a limited set of operations possible through the bridge.


Topic: NPC Control

This is where MS2.0 might differ the most from MS1.0.  It would be interesting to try to decentralize NPCs from the DM, making them agents rather than data-store puppets.  Of course, this opens the coordination can of worms.  Still, some thoughts on this...

* NPCs and PC(s) use the same verbs

As I'm currently working on reactions (and the internal recasts that scenes use to represent them), I'm realizing that all characters--whether PC or NPC--should use the same verb and action definitions.  (MS1.0's original intention was to be PC-centric, though I'm gradually drifting towards this goal now.)  This would also be more useful in any 3rd or 2nd person graphical system where all characters need to be animated using the same system.

* NPCs exist between world and story.  

They are world objects, and often seem like they should be able to provide their own immediate reactions, just how objects know how to respond to being Opened, Taken, Pushed, etc.  

But, unlike world objects, NPCs respond to story-level Actions, not to world-level Verbs.  (The old Kiss example: the NPC could determine a reaction based on affinity to the Verb, but there are still other kisses: Judas betrayals, frog disenchantments, etc.)  This isn't really a problem: the NPC can just wait until after casting to respond.  Of course, responding becomes tricky trying to integrate all this context (and explicitly reincorporate it in the response), but the NPC could still be responsible for doing it.

The problem comes from NPC responses also being story-level events, as well as potentially world-affecting.  This means they need to be coordinated.

* NPCs reactions need to be coordinated.

If the PC kisses a girl in public, there's lot of things that could happen: she could respond with a slap or a smile, her boyfriend could pound the PC, her guardian could give the PC a stern talking-to, others could frown disapprovingly at the PDA.  But these can't  all happen at the same time.  And, arguably, they shouldn't all occur.   For example, if the boyfriend jumps in, the others will have something new to react to before they had a chance to reply to the kiss.  And, should the boyfriend change the world state by knocking the PC unconscious, the other reactions become senseless.  But how do I (or rather, the DM) coordinate all this?

* Picking the best NPC for the job

Related to coordination the question of which NPC gets to take the lead.  For example, suppose the PC is beating up an NPC victim in front of other NPCs.  There are lots of things to consider about why one of those NPCs might step forward to stop it: inherent morality (protect the underdog); because the NPC is in a relationship of some sort with the victim; the NPC just likes the victim more than he likes the PC; the NPC has seen the PC do this before and wants to prevent repeat experience.  And then there are various other factors that may shift/mitigate this: is the NPC already injured?  Is the NPC strong enough to stop the PC?  Are others around that might also help?  

So there are many character-based reasons for why a certain NPC might step forward.  But there might also be story-level reasons.  Perhaps we haven't seen an NPC do anything significant yet.  Maybe one NPC is already filling the role of peace-keeper or control-freak.  Maybe it'd be good for the story to have that NPC then get hurt in the resulting scuffle.  But these story-level motivations must always be balanced with the NPC internal motivations so that characters stay "believable".

And things are this complicated even when we've limited ourselves to a single possible respone: stepping in to stop the PC's violence.  Other options include just watching, calling for it to stop, encouraging the PC, walking away, or jumping in to help the PC beat up the victim.


Topic: NPC Autonomy

Besides simply decentralizing, it'd be nice to give NPCs a chance to behave "believably".  Ideas:

* NPCs could track their own view of past events (probably links into the EventHistory).

* Before reacting, they could propose a list of potential reactions to the DM, rated by preference ("believability") and indicating reincorporations.  The DM could then construct a scene from these proposals, managing the different conflicts, such as (likely) world changes from each reaction that might negate later reactions in the scene. (This would mean that a lot of scene content would not be pre-authored, even at a template level.  Instead, scenes would be generated/planned at runtime from believable reactions and story goals).  Basically, the NPCs are like actors checking in with a director: "Here's the different things my character would do at this point; what do you want me to do?"


Topic: Scenes and Story Goals

Story goals?  What are they?


Topic: Stories and Incarnations

It would then be interesting to play with each of these new/modified components as they come online, and evaluate what difference they would make.

* World-Emergent Narrative

With autonomous agents, the DM could provide only very basic coordination.  In a fantasy/combat-oriented setting, each faction could have an alignment, and the PC is responsible for affecting that balance.  Each (major) NPC has goals and carries on towards their ends, with the DM simply responsible for maintaining a rough balance of G/N/E in the world.  When too many Evil characters are taking over, the DM could nudge some Neutral to Good with a goal of opposing them.  But this could be a slow/tenuous balance, allowing the PC to eventually topple it one way or the other. 

This is basically an interactive world that would have it's own emergent narratives based on NPC goals.  Now, see what happens to the player experience when we turn on reincorporation at the NPC level, so that the PC sees their action affecting those around them.

Then add story goals to this...


Section: Bells and Whistles

These elements are not central to Marlinspike, but might still make for a better game.  These could be later implemented even under Marlinspike 1.0.


Topic: Customizable PC Modeling

The player should be able to customize their character more with regards to name, gender, and character attributes.  Demeter NPCs have attributes like morality, physical, and will attributes; the PC also has these, but are currently given an average initial score, rather than being customizable at game start (as in an RPG).  To properly roleplay, you need a well-defined persona to assume, which is currently lacking.


Topic: Conscience

A feature the user can toggle on or off with a _conscience_ command.  For certains actions, asks whether "Are you sure you want to do that?"  Repeats question until user answers yes or no.

The idea here is to try to break players out of a gaming mentality of just checking the game boundaries.  Instead, it prompts them to give a bit of thought to normally destructive or antisocial actions, which should have harmful consequences for their character.  

Also, this would pair nicely with modeling PC morality, thus giving a warning before they stray drastically.

