Python Parsing Progress
Okay it doesn't look like much but there is a LOT of back-end going into this. With some good work but tonight I should be able to parse the scene script.
Still haven't solved my combination problem for the Gaussian Probability Sets. I have the question up on Math StackExchange.
So onwards to the generators!
c:\Dev\DDD-Snake>testbed.py
~~ Defined Key {SEVERAL:[ 4 : 8 ]}
~~ Done Cleaning and Building Define List
~~ Done Parsing Location data
Status [Gender] Enum : Male(50%) Female(50%)
Status [Job] Enum : Barman(25%) Miner(25%) Gaurd(25%) Functionary(25%)
Status [Height] NumRange [1.2:2.4]
Status [Nation] Enum : Red(83%) Green(8%) Blue(8%)
Status [HairColour] Enum : Red(16%) Ginger(16%) Strawberry Blond(16%) Blond(16%) Brunette(16%) Black(16%)
Status [HairStyle] Enum : Bald(12%) Shaved(12%) Short(12%) Curly(12%) Shoulder Length(12%) Long(12%) Braided(12%)
Braids(12%)
Modifier Gender[X ]
HairStyle : 20% 20% 20% 20% 20% 0% 0% 0%
Height : 1.9 ~ 0.4
Modifier Gender[ X]
Job : 0% 0% 0% 100%
HairStyle : 0% 0% 16% 16% 16% 16% 16% 16%
Height : 1.7 ~ 0.3
Modifier Job[XXX ]
Gender : 100% 0%
Modifier Job[ X ]
HairStyle : 33% 33% 33% 0% 0% 0% 0% 0%
Modifier Job[ X ]
Nation : 100% 0% 0%
Modifier Nation[X ]
HairColour : 80% 12% 3% 3% 2% 0%
Height : 1.7 ~ 0.2
Mutator "Tall"
Height : 2.1 ~ 0.2
~~ Done Parsing People data
Status [GlassFill] NumRange [0.0:1.0]
Status [DrinkType] Enum : Beer(25%) Wine(25%) Water(25%) Milk(25%)
Status [DieFace] Enum : 1(16%) 2(16%) 3(16%) 4(16%) 5(16%) 6(16%)
TODO :: Parse Prop Template --> ['Dice', ['DieFace']]
TODO :: Parse Prop Template --> ['Drink', ['DrinkType, GlassFill']]
~~ Done Parsing Prop data
______ TODO :: PARSE VERBS _______
VERB Cleaning REQUIRES PROP
VERB Dicing REQUIRES Dice
VERB Drinking REQUIRES Drink
~~ Done Parsing Verb data
Done parsing dictionary.txt
-----------------------------
Imperfect Information
I'm loving Starcraft 2 at the moment, and it got me thinking about my love of imperfect information in games design. I strongly recommend A Game of Thrones (board game) and Frozen Synapse, which also introduce blind simultaneous action which make it even more interesting.
So in a game with Perfect Information such as Chess, you know all information about the current state. Rock-Paper-Scissors is the simplest example of blind action. It's such a stupidly simple game but with practice and knowledge of your opponent you can increase you win chances. Balancing intelligence gathering and predicting other players actions are such deep interactions.
This is also what makes Poker so exciting is the reading of the little tells, something which is only possible face to face. So the meta game becomes part of the game which is so interesting. I notice this more and more watching high level Starcraft games. What I like even more is the option to use in game resources to gather information.
That balance between a blind massive push and a much small precision strike is so invaluable. It's what makes war such an interesting study.
The thing which makes games dull is when they become solvable. Introducing randomness makes the task more difficult by introducing probabilities but chance can counter skill leading to a less interesting game, in some cases. Imperfect information is a much harder solution space to map, and once the meta game interacts we go onto a whole new plane of interactions.
Currently I'm working on my Data Driven Dialogue system which at present is a perfect information system. Though there are planned and roughly sketched modules for dissemination, deception and mutation which I'm squeeing with joy about whenever I run them through my head. It's doubtful that those modules will be done by the end of the month but I plan to make them core components of a game I'm planning.
So next time your playing an imperfect information game, especially with people you know well. Stop and think how much information gathering your doing in-game and how much is on a meta level based on your opponent's psyche.
Data Driven Dialogue Schism
So the data driven dialogue project is moving along and well a simple problem arises.
The more mechanic driven and gamey your game is, Ludology focused, the easier it is to scrape and implement a data driven dialogue system. The more narrative or plot driven the game is, the more special cases you have and thus the data driven solution becomes much more difficult.
The problem is that the narrative focused game are the ones that will most benefit from it. But of course uprooting an established standard is a tricky task to undertake.
The mistake I made is at the start of the project I chose an atypical role-playing module as a reference point. This being my ultimate goal, but its sooo difficult to use as a reference. Where as recently I started using Quake as an example as it just clicks so well.
So yes I could have a post game chat and character development added to Quake but not sure how well that would appeal. I guess prove it first then move onto more difficult examples.
Concrete Examples
So I have some paper examples composed. They serve to demonstrate, but I feel are rather lacking. I don't think the true nature and power of the system will be exposed until I plug it into a living system or game.
Examples
- Agent Knowledge Example
- Query & Response Example
- Traditional Dialogue Tree Example
- Reference Scenario
Questions? Thoughts?
Generating Data
XML Data formatted with CSS
Over 13,000 characters and this blasted XML is still not complete enough to provide a decent concrete example.
Thank you CSS for making it legible to the human eye.
I may look at doing some examples tomorrow night.
Concrete Example
Formatting data into a meaningful representation is a whole area of study.
XML is a wonderful way to format data. Using a bit of CSS to transform XML into prettiness is a wonderful way of formatting it.
Well still loads todo but progress is here
XML Data (WIP)
Reference Scenario
Paper Progress
So I was so tired of seeing a computer the last few days I switch to paper notes for a while. Still need to scan / transcribe them to digital format. Here are some highlights
Key Points
Goal: To explore and define a method for game agents to comprehend game objects and events with the ability to query and respond.
Method: By implementing a reference scenario in XNA.
The exact schema I choose for the implementation is trivial, but the graph Query & Response format is key.
Systems
These systems are listed in order of implementation. For my dissertation I shall only be doing the first three. I do plan to eventually do all of them.
Knowledge Storage: Representing knowledge in graph format.
Query & Response Format: Query an agent and formulate a response
Agent to Agent Discovery: Two agents converse and update their knowledge graph based on response. An agent also needs to resolve data conflicts.
Chinese Whispers: An agent mishears or corrupts data on receiving knowledge.
Lies:An agent intelligently mutates data on output when certain conditions exists.
Input & Output Translation: Data is transformed from graph format to friendlier format. Possible IF parser, GUI system or NL system.
Array vs Group Confusion
Array vs Group Confusion
Arrays are listed as { }
Groups are “- - -” boxes
So some graph confusion between arrays and groups. It’s very clear on the graph but the query starts looking strange. Really tired and not making progress.
So going home, grabbing some food and hopefully I can clean up the mess in my head.
Splash Damage
Splash Damage
Okay some actions can affect multiple targets, my old model ignored this and hence broke in a few places. I’ve now fixed this. This resolves a few graph query issues I was having.
Containers
Aaah yes arbitrary containers are extremely useful in a graph systems. They give information based on context. I was using them in all my drawings and notes, but not in code. This has now been fixed and cleans things up.
Multiple Children
I started with a query as a single path in the graph. Then I got lost a bit and thought, of course multiple children are needed. So the query changed from a path to a sub-graph.
The confusion arose because the response is multiple nodes.
This is messy and muddies the model. After trying to handle the sub-graph query I decided it adds nothing, as multiple paths can be submitted consecutively.
So now the query is path, response is a node list.
Query Graph
Okay so loads of code written, which has really found holes and helped smooth out the model.
Query Graph
Okay so the most basic Query format is a Graphed Query.
Pop-able Context
Any item which is pop-able can throw away it’s parents without loss of information. You may want to keep the context if you want to use a “previous topic” action. If the depth is becoming unmanageable however you can slice off the top at Pop-able joints.
Items which are not popable require their context to make sense.
Current Context
The current context is the Query which was passed in, we can then pass out the response nodes.
If you have a general query then an outline will be provided on the context item.
If you have a specific query, for instance the above query could be expressed as.
Object(Knife) -> Event(Stabbing #2) -> Actor( NULL )
Agent Data
What data does each agent hold, well coding really shone light on the dark places and showed up the cracks.
Atom
The Atom element indicates time-sensitive data. It can be attached to anything, to contain a time sensitive element. AtomCollection was a break through, it smooths out the accessing of Time Sensitive data.
Atoms cannot be a child of Event Node.
Talk Base
Person, Place, and Event all inherit from Talk Base.
Talk Base has a list of status which allow generic attachment of time-sensitive data.
Data Groups
At first I was look at expanding the data model but then I thought of data groups. So the Graph provides context.
Verb
I’m still not happy with the verb declarations, the model needs some revision.
I’m thinking of having a dictionary of possible game verbs.