This is an idea I''m tinkering with for producing dynamic plots for a typical rpg/fps. It''s not quite finished yet, so feedback is welcome. List of templates: Define a list of plot templates. The 36 plots aren''t quite detailed enough, but tailoring them to the particular setting might be ok. Consider them to be mini-plots, something that covers a few chapters of a book rather than the entire work. These plots are the types of things the player will be do to play the game. I''m not interested in sim-adventure, so they should require the player''s participation in order for the plot to unfold. Each plot will have to have at least 3 possible resolutions - player succeeds, player fails, player ignores - though more are possible. There are some other requirements for the plots available in the list, but since these derive from the other items I''ll leave them out for the moment. Plot node: Define a structure that I call a plot node. The plot node is a class that is embedded in objects that act to provide plots. They serve as both subject and object of plots, and make up the real strucutre of the story that gets spawned. A plot node contains at least one value, but probably more than one, which can be used to select a plot from the list of templates. These might be personality attributes, moods, or metaphors that can be evaluated to select a single plot. It is useful to have some randomness here, but not too much. As a (corny) example, an attribute of ''virtuous'' might filter the list of templates and remove requests for assassination. One of the effects of resolving a plot will be to alter these values. The player''s success, failure, or indifference should alter the mood used to select plots. This means the same source will provide different requests or directions depending on the player behavior. A plot node also has a relationship to several other plot nodes. Not all of them, 3-4 might be enough. The relationship should be both a connection and a value for the type of connection between them. They may be one-way connections. These relationships are used to determine a second plot node involved in the plot. Typical relations might be personal relationships (family, teacher/student, lusts/hates/fears) or situational (has info about, at war with, etc). This means it''s not enough for plot node A to request a bauble (generic fetchit quest). It must directly involve another plot node - request a bauble currently associated with (or contained in, or owned by) plot node B. An additional requirement for the plots templates: each plot template must link two plot nodes. The only exception might be one that wins the game - and even then I''m not positive it should be an exception. Why two plot nodes? It is required in order to give the player a personal interest in how the plot unfolds. The resolution of the plot now can affeect the mood values of both plot nodes. It may also affect or alter the relationship between them. The player is confronted by a choice that will not only affect their immediate goals (whether or not to satisfy A) but also affect any future involvement with B. An example: Plot node A is embedded in an NPC, an aristocrat that is Greedy, InaGoodMood, and LikesThePlayer ( all are values ). The aristocrat asks the player to fetch an object from the altar of a shrine. Plot node B is embedded in the shrine, split between the altar (which usually acts as the subject and object) and the high priest (who gives it voice when needed). The values for Greedy and LikesThePlayer are used to spawn the generic fetchit template from the list of templates. A connection between the two plot nodes is necessary to select the shrine as the target. In this case, the aristocrat has written accounts mythical shrine and of the object that is there (it''s a one-way relationship). Because the shrine is also a plot node, the player will likely encounter it again. He may even end up doing work for the shrine. How the player resolves the aristocrat''s quest not only changes his relationship with the aristocrat, but influences all future relations with the shrine as well. The idea is to be able to re-use the same nodes again and again. As the moods of the nodes and relations between the nodes themselves change, the game-space stays dynamic. This keeps the player involved, and allows the game to react to how the player proceeds. Think Prisonner''s Dilemma. The two plot nodes don''t have to be in opposition, but the plot does need to have the player''s involvement. Another example would be person A who is infatuated with person B. They ask the player to help with the romance. The player can help get them together, break them apart, seduce person A, seduce person B, or ignore the whole thing. The different resolutions affect the player''s relation with both A and B. The final attribute of the plot node is a simple ''available / not available'' flag. Sometimes the node in question simply won''t provide a request to the player. Either the player is beneath notice, or has declared himself an enemy of the node. In this case, though the player may interact with the node normally, it simply won''t provide a plot for the character to pursue. One of the effects of plot resolution would be to turn this flag on or off. This effect should probably be limited to nodes connected to either the subject or object of the quest, but do not need to be limited to the subject and object themselves. Resolution/motivation: So why would the player get involved? One aspect of the plot resolution should be something the player immediately wants or needs. Does the player want a shiny new weapon? Well, I''ve got a little job for him. Once the player takes the first step, the web of plot lines will (hopefully) keep him ensnared. Note that there can be many of the traditional adventure/rpg/fps difficulties involved in solving a plot. Plenty of monster mashing, jumping puzzles, or whatever else you want to place as obstacles. Once a node is declared ''active'' however, it should be fairly simple for the player to get direct access. To use the previous example, the shrine in question could be on a mountain top with plenty of difficulties to get there. Even once the quest is done, the shrine may not be flagged ''available''. But later in the game, the player helps out someone who is a former member of the shrine (another plot node with a connection to the shrine). This flags the shrine as ''available'' and the player is given a whistle which calls a roc from the shrine to pick him up and take him there whenever he needs. Or a password to the main gates so the player avoids the dungeons underneath. Whatever is appropriate for the setting. If the shrine ever becomes ''unavailable'' then they change the password, or take back the whistle, or whatever is appropriate. How many nodes? How many quests?: Since each plot node only supplies a single opportunity at any given time, the player should not be required to complete every plot that is offered. Completing one plot may cause another to become impossible. The player should only be presented with about 7 requests at any given time and should have the option of choosing which to perform. The total number of nodes should be large enough to provide variety, but small enough to manage. I figure 30 or so would be suffficient. This give the player a sense of movement, exposing him to new nodes and personalities while getting the most from the same mechanics. Endgame: Obviously the game must have some conclusion. Either a larger storyline whose completion finishes the game, or a mini-plot that only occurs late, after the player has fulfilled a number of other plots to make it available. The design is rather vague at this point because it needs a chunk of work to adapt it to any particular setting and genre. It''s also vague because I don''t have my implementation completely worked out yet, even on paper. Comments? Suggestions?

Shouldn''t there be a supervisor program which is evaluating the right occaison to throw some floating nodes at the player?

Maybe, but my idea was that the player had several choices (plots) available at all times.

Rather than a centralized control system, each plot node gets connected to others like a web. At the beginning of the game, the player is only aware of some of these nodes. A few npcs that request help, or a treasure map, or a quest in exchange for a good or service.

The nodes themselves open and close access to other nodes. They are also self-modifiying, so they tweak the internal parameters that translate to specific quests.

The nodes are scattered across the play area (game space) rather than at a central location, so the decentralized nature is reinforced.

You would need some sort of initializer routines to set up the web of nodes and embed them in appropriate objects, but beyond initial creation I don''t think you need an active node manager.

JSwing

The plot node idea is intresting. I''m wondering what sort of criterion will you use to determine the success or failure of some of the more complex plots. Simple fetch plots are easily resolved but some of the more complex ones like helping the romanace, is much harder to determine success or method of success. If the plot is dynamically generated, then so the method by which the plot can be successfully completed. Could be a diffiuclt problem.

An intresting idea would be a game based around not character building, but story building. Where the player tries to complete the best story for a character possible. With the emphasis on the story instead of character, it should focus the player toward more inovative solution possiblities than hack and smash.

-ddn

Very cool idea

This sounds like a really good way to structure adventure games. If you could build an engine that is based on this it could easily lend itself to a wide variety of genres.

I can see that some nodes would always give players options to continue with one of several possible main quests and take any one of them in a positive or negative direction, while at the same time, other nodes might lead the player to what they may need to make certain paths easier to complete, such as a certain magical item, or a key companion character.

To supplement this, the characters power, inventory, experience or whatever might be evaluated, and events at all nodes might suggest that a certain quest may be easier if the player was stronger or faster, o rhad someone along to help. Or an event at the node may give a neutral response, not suggesting anything because it is not important enough to make a difference in that particular pathway. They might even suggest that a certain path is below the ability of the player. This way, a player would have mild hints that there are probably greener pastures elsewhere.

I think you have a fantastic idea here.

This type of branching system, if done correctly, could probably be liscensed in it''s own right to other game development houses. (if it is made generic enough)

The problems that I see being potentially difficult to get around would be preventing a player from using up all the potential of a certain node, and therefore breaking the stories that are connected to it from other nodes. Or, playing out certain stories in an order that does not make sense. Generally what I am seeing are potential problems that are similar to those you get when dealing with large databases.

Sorry, that last message message was by me

Thx for the feedback, all.

The pass fail criteria is tricky, but fortunately that can be handed off to the plot template structure. It becomes a much larger design issue since any measure of success needs to be produced in game terms.

Likewise, the criteria for player indifference would need to be defined. Again, part of the plot template structure. Since I''m thinking of embedding most plot nodes into NPCs, I plan on studying soap operas (or ''How to write soap Operas'') to create the plot templates.


If you wanted a game to include heavy character improvements (levels, and whatnot) the dynamic plot system would be parallel with whatever mechanics you use for the character advancement.

That is, the difficulties and rewards for accomplishing a task can be generated independently. The same plot can spawn strong obstacles or weak ones as necessary. Just scale up the tasks required to achieve the goal.


Getting stuck is a problem, as is getting caught in a loop. Something to work out as the implementation is more sharply defined.


As far as licensing and whatnot, well, anything is possible. It''s certainly not finished yet. I think it would make for a different type of game, though. Feel free to develop your own version from what I have posted if you like it.

JSwing