In my previous posts, I speak a lot about what I call the “story engine”. It must be noted that this engine is just a design metaphor and have nothing to do with runtime game engines. The story engine can be seen as what Dramatica names the “Overall Story Throughline”; or what McKee names the “Central Plot”. This is the backbone structure of the player experience. The goal is to have the player know what he has to do to push the story forward.
The best way to explain what I mean by “story engine” is to show an example diagram. In this case, the example depicts a murder investigation “dramatic game” (that will be my first implementation prototype):
It is important to notice that the story engine is an abstract model of the player experience. It doesn’t specify the name nor the number of entities (objects, characters, locations, information…) nor the order of the needed interactions. The transformation of this abstract model into a concrete experience is done at player observation & interaction time, by the “quantum uncertainty” inspired system. This system use control rules to collapse the possibilities into a unique reality. This paradigm insure, amongst other things, the player freedom (order of actions) and the optimality of the dramatic experience (player centricity).
The story engine is a real gameplay system. The most prominent feature demonstrating that, is the “proofs points” system. Indeed, the player has to accumulate “proofs points” from different sources to pass a given threshold where the Judge will decide to incriminate the given suspect and thus end the game in a winning condition. It must be noted that it doesn’t exist a losing condition. The player can continue as long as he wants to gather proofs points. The proofs points also support the non linearity of the experience because they can be gathered in any order, and this from the source that the player will want to focus on.
As this model mostly involve non physical entities (information, relationships, investigation states, …), it is extremely important to find a proper way to render those concepts to the player. To achieve this, I think that I will use an elaborated dashboard system that will display all the immaterial concepts. This dashboard will include a structured notepad that will automatically log known information. It will also feature detailed and specific reports. Finally, it will include a big board that will show all the characters and objects with their respective relationships (as in real criminal investigations).
Another important problem to handle is the difficulty level of the experience. That’s why, at the beginning of the game, the player will select his desired level of difficulty. This difficulty level will be used by the “uncertainty collapsing” mechanism to control the deepness of dependencies and the number of entities in the game.
This “crime investigation model” is quite simple but, with time, will be extended to include: victim body searching, complicities, denunciations, lies, secondary murders or kidnapping to eliminate witnesses, evasions, evidences stealing or destruction, political game, witness reversal, etc… As TV criminal dramas show, this field is quite vast. The story engine will also try to add a maximum of NPC behavior triggering, to leverage the information-relationship-behavior economy.
The specificity of this story engine approach is that it deeply simulates a domain specific model. It doesn’t rely on a story surface generative grammar. Even if we can nearly feel the experience as an episode of “Law & Order” :-) this model does not yet produce dramatically interesting experiences. To achieve that, we will have to include many other key elements, such as: interesting key characters, a “thinking villain”, some interesting conflicts, a lot of emotions and last but not least: meaning. But now, we have a nice support for all these things…
I like this schema :) It's a mix of a loose causal chain and gameplay loop. It also read as a mindmap hence the looseness, a snapshot of a designer mind at a time but much more structured and useful than mindmap!
RépondreSupprimerIn general I try to keep causal chain (behavior), gameplay loop ("engine") and flowchart (topographic progression) separate.
One thing is find strange, it look like the payer already know who is the suspect (there is no guess "who is the suspect" box), if so it's a game of control point, player and suspect try to and access control point (people,suspect to prevent release of information and shutting proof, while the player want to open them) of information through various mean (affection, persuasion, threat on relative and direct threat). So basically the interplay between te suspect and the player is basically opening and closing access with those control point by influence network.
I can see that the game don't need to be centered on direct simulation but rather npc are define by their roles and behavior, for example a witness (one of the roles) have a function of holding information, a relative might have a role of gating the witness, etc... Another interesting point is the flexibility about progression, we can have various condition like enough clues, all clues or just crucial clues, maybe a mix of all of them (access to crucial clue guarantee a win but it's more difficult than having enough less important clues). The chart is enough to give away the gameplay structure and vision and let people use it to create flavor (the dramatic nature of the function, for example threatening to kill or to slap does not have the same emotional resonance but the same gameplay function).
I would argue you have a grammar (see the legend) and a syntax (the chart) as a game design is basically the process of creating a game specific language ;)
By the way collapsing uncertainty into a unique realities (assuming it's not set by a fixed design) is basically using this as a nlg, except natural language is replace by game specific language with the chart as the parse tree (syntax), basically spawning specific entities to match a discourse (control rules) is akin to selecting a word to match a particular function in a sentence, except in place of verb and noun you may have witness and suspect, information and proof.
Because of that I see than one way to create a spawning system is to have a set of fact (proof) that can be instantiate with various difficulty with a witness/object, for example how many gating (close by geography, relative, secret, quest, etc...), how many influence affordance for the player or the suspect (mean to threaten, align, etc...) with the fact also holding affordance to choose the correct witness/object that can hold it. Expending on that model is relatively easy, it's about the complexity of influence and access in the network. All behaviour can be seen as a transformation within that influence network (for example inhibitor).
This has been done on some board game, like this one http://en.wikipedia.org/wiki/Betrayal_at_House_on_the_Hill
If you didn't had yet you may also want to play the phoenix wright series which mimic closely (but in a script way) your chart (with obvious suspect and accumulating evidence), as phoenix wright have been praise for it's dramatic intensity (i advise you to play trial and tribulation on DS, which is the one I played).
http://en.wikipedia.org/wiki/Ace_Attorney#Gameplay
The spin off is alsso interesting:
http://en.wikipedia.org/wiki/Ace_Attorney_Investigations:_Miles_Edgeworth#Gameplay
LA noir obviously is a good candidate in a seemingly equal script way except with more freedom to collect evidence from many source. But I have yet t play this game
Hi Timmy,
RépondreSupprimerThe diagram is loosely inspired by goal trees. The main difference is the fact that my diagram is a cyclic graph. This indeed shows some loops in the gameplay. Those loops must not be misunderstood as feedback loops as modeled by Machination…
The goal of my diagram is to reply to the classical questions: “what the hell the player will do in this game, and why?” So, it represents the player’s motivations and possible actions. The next questions to reply now are: what the antagonist do and how the player can react? (the RPS loops). How the “means vs challenges” balance is regulated (the feedback loops at different level of granularity) and so on… I think that each of those questions needs a different diagram grammar, to be as clear as possible. A bit like UML that implements multiple diagrams, one per perspective on a given problem (they even have a meta-grammar to link all diagrams, but that’s another story…).
About the fact that the player knows who the suspects are: it’s not the case at the beginning of the game. That why, in the graph, I have the goal : “Find new suspect”.
I agree with you that I have a grammar. But it’s a grammar for a deep simulation and not a grammar to generate the “surface” of a story. I wanted to state that to respectfully differentiate myself from approaches like this: http://www.docstoc.com/docs/46562461/A-Genetic-Algorithm-Approach-To-Interactive-Narrative-Generation (and this approach is quite spread in the academic researches on the domain of interactive storytelling).
About the fact that collapsing possibilities at observation/interaction time is a bit like NLG, I agree. But the Quantum Uncertainty paradigm can’t be reduced to transformational system, it also allow many things (backstage tracking, intention mitigation, etc…) as described in my previous post (and new to come).
About the Spawning of entities as shown in my diagram, this has nothing to do with entity state collapsing at observation/interaction time. It is something totally different. Indeed, the spawned entities are “popping” under the player eyes. For instance, a new character is popping on the dashboard when you discover his existence while talking to somebody. Then you can interact with this new spawned character. This is how the experience size grows (as if new levels were unlocked).
About the other criminal investigation games you list; as you say, they are scripted. The whole point of my approach is to avoid scripting, to be able to have a dynamic opposition, thus avoiding a puzzle gameplay.
I'm aware it has nothing to do with the machination diagram which is more fit to test dynamics of low level mechanics rather than the semantic structure (how rather than what), they are not mutually exclusive but you are not yet at this step.
RépondreSupprimerGameplay loop is usually the sequence order of actions the player must take to go through the game, it denote a gameplay "tick". Your model encapsulate that.
Causal chain is the hierarchical semantic deconstruction of interaction from abstract high level (kill the dragon) toward concrete low level (push the button A) and show how they relate to each other, basically showing something akin to a parse tree of game control toward gameplay. Since interaction imply goal generally it show the goal structure of the game, the difference with your goal tree is akin to kill the dragon (goal) and killing the dragon (interaction), but at top level in game both are practically the same (the main interaction of the game is generally a goal). If you still have my analysis on Totems you will see how it's extremely useful to transform a mess into something that are playable (that fit control). It's also more strict in notation (no loop at all).
Oh I miss find new suspect my bad, I would have it higher in the hierarchy (EDIT: oh it's the update suspect, it's hard to get), it also imply that the game give automatically a suspect than you need to replace as evidence accumulate for his innocence (EDIT: obviously I'm wrong here, sorry, I was confuse by the phrasing) I would have a goal of proving innocence too then. This is interesting because it imply that mechanically the player always have a direction (always a suspect EDIT: No I'm wrong) and would not meet a dead end, like LA noir you could send an innocent in prison if you don't provide enough evidence he is not guilty and the game move on (IRRELEVANT).
I see your fear lol! Unnecessary complication, but this as little to do with grammar approach, at least serious one. But I know what you mean, mixing big word to create bullshit!
I'm not sure what you mean in the nlg part, but you must be careful to not overreact to some bullshit that exist, you still need cold hard transformation to interface with your system...
... But you are not as interested as me as a fully dynamic system. Basically your system is scripted (the story is script, it only need to be resolve in a win/failed way) except you have an opponent agent, "the field" is not open with all possibility at the beginning but increasing ly add to the field. It's really a control point game.
What you are doing is an extension of the mechanics of those game, you should ply them! Especially phoenix wright which mimic an opposition. They have spawning mechanics essentially the same, things does not spawn unless you know about them. Tokimeki is the dynamic version of that. The really new addition you have is dynamic opposition. That said thanks to Phoenix wright and LA NOIR the market is ready and languishing for this type of game (Phoenix wright sold extremely well).
Now as the gameplay SEEMS to be about control point, it look like an RTS, the problem is about the fog of war (popping things into existence). Does they exist for the suspect as well or they pop for everyone? Or the suspect and player have each their pop of control point? However this pose the problem of the information feedback from the player, how does he assess uncertainty, victory, progression and dominance, if this gameplay has to be dynamic, readability became even more important.