I knew straight away that I was going to do dialogue slightly differently in Project2 than in Morning's Wrath.
Morning's Wrath used a system of natural dialogue progression, with no user branching, this made it pretty impossible to do dialogue puzzles, or even to make really good 'learn somthing ask somone about it' type gameplay.
So in MW, you would click a person, and if they had anything to say they would say it, not bad, but we can do better this time around.
Topics Lists
So Project2 is set to use a system of topic lists.
each game character gets a total list of things you can talk to them about in the game.
these lists are created in the entities load function (in script) which means they can be subject to randomness and or procedurally generated processes, though not as a rule.
each topic has a few properties:
name - the topic id "askAboutFather"
text - the topic text "Did you know my father?"
visible - if the topic is able to be chosen from a topic list
currentState - the second dimension of topic depth (initialy 0)
visitedState - used to record the state the topic was in when you last chose it (initialy -1), differing current and visited state means the topic still has more to be said about it, and should be displayed as fresh (instead of 'visited' think hyperlinks)
action - this is the string name of the lua function to call when this topic is chosen
so, when the game starts topics are created and set in an initial state of either visible or not, as the game progresses script functions can be used to change the visibility and the state of topics, causing topics to appear, dissapear, and progress in the conversation state.
when a topic is chosen the system acts a lot like the MW system did, in that a controlled sequence takes over and the two entities converse in accordance to the code written in the action function.
overall it is a really good system, very flexible and really easy to use.
I chose this system over an actual 'tree' system because of the complications that come with having an actuall deep tree of dialogue, but it wasn't so much the complexity but more so I couldn't imagine writing enough scenarios to make a full-blown tree system interesting, instead it would likely end up using only two levels, as i'm using now and getting the benefit of an easier system to manage.
as a final note, I am toying with the idea of a choreographing markup language. in the past actions and dialogue were interleaved one on each line to make characters act, move and speak, however the thought occured that it might be nice to interlace the action data with the dialogue in some form of markup, for instance
express(person1,"{look:person2}{act:suprised}What do you mean?{act:angry}There is NO way I'm going in there!");
this may or maynot be viable, for one it makes dialogue checking a lot harder, plus it may not be worth the extra inlining. the only real benefit it provides is intra-dialogue action changes.
*shrug* who knows, maybe I'll use it =D
