« S.T.O.B. Matches | Home | Radial Plots – Size, Complexity and Stock Characters »
Radial Plots and Dialog Concerns
By Corvus | May 2, 2006
This is Part the Second of as many posts as I can think to write on the topic of radial plots for our Honeycomb Engine™.
Chris asked for clarification as to which direction the plots were intended to run – from the hub outward or the rim inward. I suppose I could have been clearer about that, hm? Well, rim inward is the image I’m going with. And speaking of images…
This is an example of a relatively simple plot graph with fewer than 50 plot points. Keep in mind that each plot point may be a sub-plot and contain its own plot point graph. This is why some Push points in this graph have Exploratory exits. The color gradation you notice in these plot points is keyed to the player’s Renown. The explanation of that may warrant another post, if you’re curious about it.
In fact, why don’t I shut up and let the graph speak for itself. If you read yesterday’s big post (link), it should be relatively self explanatory. But don’t let that stop you from asking any questions you may have!
Duncan wrote in response to yesterday’s post:
The biggest question I have is: how do you write compelling dialog without knowing what character will fill a particular role. Keeping in mind that one of the biggest tools to use to make casual dialog seem compelling and intersting is the use of foreknowledge. That is, the character remembers past interactions and can reference them.
I can see it being done, but it would require writing a lot of dialog options that will never be used in a single pass through the story.
The Honeycomb Engine™ handles information and events like objects. So, every time an action is performed, it generates an ‘item’ in the character history. Exactly how granular that stored data is will depend upon our system resources, but major character events and interactions will certainly be stored permanently. Storytellers will be provided with tools to access events from the player character’s past, if the NPC they are interacting with has a history with the player character. Various types of characters will have some stock phrasing that can be used to integrate those events into dialog. It will also be possible to generate some stock phrasing of your own that will be specific to the plot you’re crafting.
The storyteller will be able to set criteria for the type of character they need in a role. If the player’s character doesn’t have anyone in their past that fits the bill, the engine will provide a character for them, either pulling a NPC from the area, or generating a new character if needed. This does not rule out accessing elements from the player character’s past, as Renown functions exactly like you might expect, and knowledge about your activities may precede you.
The important thing to remember here is that it ought to be quite possible to build a narrative that utilizes no storyteller-created dialog at all. Since I consider the narrative to be every element of the game that the audience experiences, you could theoretically utilize this narrative structure to generate everything from action sequences to murder mysteries (although if you’re using it to script action sequences, you’re probably being way too granular in your design).
Time is not on my side today, so I’ll leave it there. Again, feel free to bombard me with questions and/or criticisms.
Tagged:Design, Honeycomb Engine, Writing. | 3 Comments »
May 2nd, 2006 at 9:15 pm
I find it interesting (not bad, mind – just intriguing) that your character is set upon a fairly limited plot path unless you engage in a serious amount of side-plot exploration. For example, if you start on the Heroic Renown side of the chart, you can only access the three endings on the heroic side of the chart if you only complete plot advancing quests. Although, the more I think about it, and your comment on sub-diagrams, the more this makes a good deal of sense.
Okay… I’ll wait for more on this, it has sufficiently sparked my interest.
I think I still have a conceptual problem with procedurally generated characters. Especially when it comes to dialog and casual conversation. This stuff is hard enough to write when you have a good sense of it. Forcing an algorithm to generate it solely based on history, some character data, and stock phrasing raises my eyebrow. Meaningful characters have personality, and personality can’t be easily generated from raw data. It needs authorial control and design. Again, perhaps it is simply that I have too little data about the internal workings of the engine.
May 3rd, 2006 at 2:24 am
I’m greatly relieved that this is rim-to-hub. The alternative is largely insane. However, I still think the outer rim is too large to be justified. Remind me: is this a single player or a multiplayer environment? If the former, consider reducing complexity in the outer rim and increasing complexity in the inner rings. If the latter, there probably isn’t a problem – apart from the work involved in rendering it.
This encourages me to do a FreeSpeak retrospective…
May 5th, 2006 at 9:45 am
I just revamped this diagram to correct a few unclear terminology issues. Click the pingback link below to be taken directly to the post.