WorldForge Community

Sounds like a very interesting idea, I would be happy to hear more about it and how you you envision this working as a whole. I can think of a number of approaches that could be taken for some of the things you mention, but I'd like to hear your thoughts first and then add my own input afterwards.

-Demarii

I've been thinking one might try to use a machine learning setup to learn to identify tropes (http://www.tvtropes.org) and form coherent trope sequences into a story in a somewhat automagical manner. With a bit of crowdsource ("click here to +fav this story" :) data to tune the training one could have a secondary server analyzing game-play and write suitable stories matching the chosen trope sequences by filling in the best (or top N) examples of tropes as identified by an SVR trained to predict confidence of trope detection.

The way it works is you train the SVR on a function of confidence evaluation based on its input. To do this one represents a trope sequence (tropes strung together to form a complete story) using a digraph and train the SVR/SVM based on known characters or actions best fitting the nodes (or not fitting) from real examples. The SVM/SVR can then be used to identify the trope nodes from actions in the game (your game does write out a log of all transactions for security, doesn't it? WoW certainly does as evident from how completely Blizz goes after exploiters right down to revoking skillups where the skill invoked to obtain the skillup required mats that were the result of disenchanting items obtained thru an exploit such as the arena glitches that have occurred now and then that allowed anyone to obtain certain rare items until they were patched -- anyways this transaction log also provides a way to interpret actions made in the game by players as tropes by using SVR/SVM) giving a confidence to each node of the trope sequence. You compose the confidence into a single confidence, starting first at the leaves (no nodes out) and working back to the roots (no nodes in). The result will be confidence levels for all possible story arcs of the trope sequence.

You could then determine the highest confidence path through the digraph from a root and turn that into a story. You can get the story engine to completely outline the path in terms of characters and actions at each node complete with confidence (to which it basically boils down that higher confidence tropes require more attention in the story than lower confidence nodes). The result is basically a complete outline (complete with plot devices involved ie: the respective tropes the characters and actions tie to). It should be fairly easy at this point for a human to write out a story to publish on the game's website. With many such stories published and suitable ranking mechanisms (click here to +fav this story) you now have crowdsourced input to fine tune the training data for the SVR/SVM. If Google can use such crowdsourcing to form a highly successful global company I'm sure a few WorldForgers could at least make a living. The best stories could go on to become fully published works (perhaps in GN format, hiring one or more illustrators to draw it).

Thus anyone playing the game has a chance to be part of the story. You could give the story engine queries like "write best action-adventure trope sequence that happened in the game thus far" or "write a story centered around player X using action-adventure trope sequence" you can come up with more than one trope sequence to write different kinds of stories.

If players are aware that there is an ongoing story driven by their own gameplay in the game there will be more emphasis on roleplaying and less on grinding. Players who just want to grind will be missing out big time and will eventually attrition themselves so over time the game will sway more to a roleplaying player base than grinding player base.

In a game set up this way the story becomes an evolving aspect of the game directed solely by player input (as they play their characters) and not something you need to market an expansion every year or two to update.

In the interests of sustainable business model you don't really want a single story that ends but rather many parallel subplots where some may come to conclusion, and new ones also emerge out of other goings-on in the game world. The emphasis here is that it is primarily player-driven (though an NPC with a personality AI might get lucky) so there ought to be plenty of data to discover new emerging plots.

You can also use the story to drive game development. If it emerges that a new "goody" or baddy is needed you hire your asset creators to produce one and put it into the game. You ought to be able to write queries to the story engine like "what would be needed to produce an action-adventure trope-sequence among this list of characters [x,y,z,...] /* NPC or otherwise */" (it will easily tell you which tropes in the reference sequence are weakly represented by your input list) You would drive such queries again from crowdsourced data such as which characters are being accessed (by website visitors accessing stories involving those characters).

I love this thread - not sure I grokked your concept Gau, had a question:

is your system leading the players on, or is it 'following' them and then assembling a story retroactively?

those are two alternatives I see this thread getting at:

assembling past actions into coherent narratives - or - quest generation.

i'm new here, so apologies if i'm retreading past ground, but quest generation seems like the logical next step, the step where WoW should have gone

for a given trope you define it as a set of precondition that must be met (and any contra indications that may negate the trope from being fulfilled if they are met)

you then train a set of SVRs to predict the possible conditions using as its input sequences of actions from the game and as its output how confidently the actions fulfill any of the possible conditions

you then come up with a consistent formulation for total confidence of a path formed through the story graph. an average of each node's confidence (and each node itself averaging the confidence of all its conditions minus the average of the contra-conditions) is probably sufficient. The higher the confidence the better the story ought to be (if you designed your graph with suitable pathing and trope nodes).

actions are simply the transactions issued to change the state in the game world coupled with the pre-transactional sub-state (so if a transaction changes, say, HP you would have an actions like "time T: playerX.HP changed from A to B")

Input to the SVR needs to have a consistent structure so we need to create a language to express all the possible state transitions as a uniform sentence pattern. We also need to normalize things so we do some pre-processing to view events in a time window, normalizing the start time always to zero (we want differentiated game time, not integrated game time). I should point out any accumulating (integral) game world state is best expressed differentially. Game time, a player's EXP/Level are examples of accumulating state, a player's position and other transient stats (MP, TP, HP, etc) are not (NB: EXP presented as SVR input is probably better expressed as "% change of level" than as an EXP number since 5 exp is lots at low level but peanuts at very high level -- same goes for other levelled stats if the required accumulation increases by level if a stat always levels at a constant net accumulation then this normalization is not necessary). We want to detect as many patterns as possible so we normalize as much as possible for input to the SVR.

nuSVR input components take a value in the range [0:1] (or -1:1 in other SVR implementations). Here's where normalize is important...
You cannot express an infinitely increasing value on a discrete [0:1] range (doubles are discrete to their minimum possible change of 1/2^52) so it must be normalized. Times in a sequence of actions are normalized to be a fraction of the total duration of the sequence. It might make sense to normalize certain actions to eliminate time variation where the exact durations are not needed for the trope being detected. But if the trope has something like (a decade later) testing for those tropes should be done with variation left on the input (you probably then want a separate SVR for such tropes with a different input profile).

There must be a representation for a NULL sentence (no sentence) since the number of sequence slots must be fixed in the input vector.

It will simplify training immensely if you code a heuristic system to generate suitable windowed sequences where the sequences are normalized (eg: if you have a pattern ['t0.0: B's HP drops to 1%','t1.0: A heals B for 90% HP'] so you do not need to include examples with the events at all possible alignments within the fixed sequence list. SVR also do not remember previous events so some state must be included in the input (in this example it might be important for the SVR to know A and B are in combat).

Domain analysis (of the tropes you want to use and identify) is necessary to determine the number of SVR and what inputs each will use. SVR is useful but it is not a magic bullet. There might also be use cases where you need the preprocessing to perform clustering (perhaps if your game has larger parties or raids you want to aggregate their actions overall by using K means clustering on the actions taken by all raid members). Another example would be players organizing some sort of coordinated activity (a protest or strike example comes to mind) in the game but that does not clearly identify as a party but you ought to be able to identify the actions of the "group" as a sort-of collective whole. Clustering may achieve detection of tropes requiring such activities. I'm sure I've only touched the tip of the iceberg for what kinds of domain analysis could be useful here.

an SVR will predict a single decimal from [0:1]
If you have bags of memory and CPU you might use one SVR for every condition but there is a way to optimize and combine mutliple conditions into a single SVR

Q: Do we really need the entire precision space of a single double valued number to
have sufficient levels of confidence?
A: Unless you are writing a story about quantum mechanics for Dr. Stephen Hawking, probably not.

So we discretize the confidence desired into steps and make the steps a power of two, say 16 (2^4)=16 this gives us 16 levels of confidence for a particular condition at 4 bits per condition. To be safe we'll consider the double to only have 52 bits of precision. It just so happens 4 divides 52 evenly thus allowing us to have 13 conditions per SVR. If it turns out you need more resolution of confidence increase the number of bits and adjust accordingly (if you needed 32 leves 2^5=32 at 5 bits per condition then you'd be able to pack 10 conditions [10*5=50, 50<=52] into one SVR.<br />
There is a nifty piece of python code that can be used to convert a number to and from an N-vector using a Hilbert curve: http://www.tiac.net/~sw/2008/10/Hilbert/
Hilbert curves only planeshift about corners so noisy bit errors (we expect input to be noisy so we expect the SVR output to oscillate a bit) avoid changing components by large steps, unlike naive Z packing (with Z packing a max value in one component might switch for a min value of a neighbouring component, or vice versa, which means a small bit error results in a complete swing of the confidence of two potentially very different components. I call this planeshifting and it is VERY BAD).

We can compose the vector of 13 4-bit components [0:15] and then use the python code above to exchange the vector for a number from 0 to maxSignificand where maxSignificand=(2^52)-1 **** Don't forget the -1 ! ****

We can also unpack the number back into a vector using the corresponding unpack function.

To make this number into a fraction divide by maxSignifcand to get a double in the range [0:1].

To turn the SVR output back to a vector:

1. multiply the output prediction by maxSignificand
2. call the Hilbert curve unpacker with the number obtained in step 1
3. enjoy your N-vector

So now we have a way to train an SVR to evaluate confidence that certain conditions hold by example.

Basically the SVR is determining a N-dimensional point that best fits your input where N is the number of conditions that were packed