views:

53

answers:

1

Hi,

I wonder if you can help me.

I'm writing a game (2d) which allows players to take multiple routes, some of which branch/merge - perhaps even loop. Each section of the game will decide which section is loaded next.

I'm calling each section an IStoryElement - And I'm wondering how best to link these elements up in a way that is easily changed/configured and at the same time, graphable

I'm going to have an engine/factory assembly which will load the appropriate StoryElement(s) based on various config options.

I initially planned to give each StoryElement a NextElement() As IStoryElement property and a Completed() event. When the vent fires, the engine reads the NextElement property to find the next StoryElement.

The downside to this is that if I ever wanted to graph all the routes through the game, I would be unable to - I couldn't determine all possible targets for each StoryElement.

I considered a couple of other solutions but they all feel a little clunky - eg Do I need an additional layer of abstraction? ie StoryElementPlayers or similar - Each one would be responsible for stringing together multiple StoryElement perhaps a Series and a ChoicePlayer with each responsible for graphing its own StoryElement - But this will just move the problem up a layer.

In short, I need some way of emulating a simple but dynamic workflow (but I'd rather not actually use WWF). Is there a pattern for something this simple? All the ones I've managed to find relate to more advanced control flow (parallel processing, etc.)

+4  A: 

It might help to think about the StoryElement objects as nodes in a directed graph. The edges of the graph could be represented by StoryElementTransition objects (or some similar name). A StoryElementTransition could contain references to the state you want to transition out of, the state you want to transition into, and maybe the event that triggers the transition.

By setting up your story as a graph, you open up the possibility of running a directed graph traversal algorithm to determine all the possible routes through the game. For example, you can run a Depth First Search algorithm on the Event graph, pushing each state and transition on a stack, and printing the entire stack once you reach an end state.

tedw4rd
That's a much cleaner way of looking at the problem - Thank you
Basiclife
the completed() method shuld return a status, and each transition be based on a status (ie if completed() return status 1, use transition to StoryElement B, id status equals 2, go to SoryElement C... You could even add probabilistic transition (allowing several transition from a StoryElement, based on the same status but with a % of activation...)
PATRY
That's a very elegant suggestion - Thank you
Basiclife