Technical Component Detail for
Computer Assisted Storytelling in Video
Southern Methodist University
6425 Boaz Lane
Dallas TX 75205
This project is intended to tes
t out the feasibility of this storytelling system in
terms of content creation and overall believability of the resulting story while
incorporating player actions. As such, the ideal method of testing this storytelling
paradigm for video games is to create
a video game which utilizes the techniques
discussed so far. Due to the time constraints on completion of such a project and the
limiting factor of not having artists or level designers available for content creation, the
game must be fairly simplistic wh
en it comes to graphics. For this reason, a 2D game is
proposed which minimizes the amount of art needed.
The game needs to be heavily story
based with story affecting choices available to
the player. Many game genres rely heavily on storytelling, though
they also rely on other
underlying gameplay mechanics. Since the gameplay mechanics are not a focus of this
project, there is very little reason to clutter up the storytelling design system with
extraneous details. Thus game genres such as RPGs that requir
e complex game
mechanics are not well suited for testing out an initial version of this storytelling system.
Instead it is proposed that an adventure game that focuses on storytelling over other
gameplay mechanics be used as a testbed for this computer ass
isted story telling system.
Adventure games are one of the oldest forms of video games around today. In the
early days of video games, adventure games came in text form where the players read the
description of the environment and typed
commands for actions to be performed on
objects and characters in the environment. This leads to an easily large range of actions
that can be performed by the player. To bring the adventure game to life a 2D graphical
implementation is proposed. Once again
, due to the lack of artists, simple programmer art
will be utilized to convey the characters and objects in the world. Combine this with a
text interface for conveying story actions to the player and a selection box with the
possible actions available to
the player, the adventure game has all the elements needed
to test out the storytelling system in a video game like environment.
The final produceable from this project proposal will be an adventure game
utilizing the storytelling syst
em described in this document. The game will utilize a Ruby
virtual machine to execute the story elements as well as for all of the gameplay
programming. The adventure game will feature a linear story that the player can influence
through his/her actions.
There will be a multitude of possible player actions as well as
various plot points/story objects on which the actions can be executed.
The desired results from this project are two
fold. The first is to test out if such a
which utilizes story
generics and story
specifics can cut down on the
content creation time normally required for game stories that react to player actions. The
second is to see if this storytelling system is flexible enough to be used in commercial
game stories. For this reason, the adventure game which is produced needs to
feature a story and interactions which are complex enough to demonstrate the
effectiveness of this system.
oriented action planning
system is the brain of the entire
will be modified such that the next
story plot point will be the goal of the system.
The planner will be run
on the inputs of the current story goal
and story operators
using the A* planning
The system will then use the story generic and story specific operators in order
to create a sequence of actions required to bring about the new plot state.
This will be a
top level system
with the story
At the moment the idea is to
have the GOAP chooses the shortest path to the goal with the prospect of choosing more
interesting paths at a later stage of development if time permits.
Additionally, the heuristic for the actions
will include the likelihood that the
player will perform the action, i.e. use the key.
This requires building some internal
representation of the expected behavior of the player.
The story operators are essentially a collection of
ons that the GOAP
system can use to move the story from one plot point to another. There needs to be a rich
enough set of story operators in order to ensure a suitable plan can be determined to move
the story between each pair of plot points.
tory operators are going to depend on
the entities they perform actions on, the events they can trigger, and the
using the story operators.
The story generic operators will be generic in the sense that
they have no prerequisites for which
plot point that must be used for while the story
specific operators will be bound to specific plot point actions.
Adventure Game Skeleton
The game skeleton will be the
structure that ties the entire project into a coherent
whole. This skeleton will hav
e a main game loop which processes the events through the
event handler which in turn make calls into the entity manager in order to perform the
story actions of the
current plot point
The GOAP story system will sit as a manager
within the game skeleton a
s well. If at any point an entity performs an action that changes
the current story state, a new story plan will be formulated using the planner.
All the entities in the game will be
managed through a central entity manager.
is responsible for coordinating with the event handler to process events for
each entity. The manager will use a multimap with the entities as keys and the events as
the associated values. At each game frame the map will be iterated through and all events
for an entity will be executed.
In the case that a single event modifies multiple entities at
once that event will be removed from the other entities’ lists through a call into the entity
The entity manager also allows an entity’s normal goal pic
by the GOAP story system so that the story system can assign the goal for the
entity if needed by the story.
There will be an event passing system for passing events
This event handler coordi
nates with the entity manager and the GOAP story system to
issue events to the entities. If the GOAP story system invalidates any previously queued
events for an entity it is the responsibility of the event handler to be aware of this and to
tell the entit
y manager to remove those events from the entity’s queue.
The graphics in this game will be entirely 2D. Ruby has bindings for the SDL
(Simple DirectMedia Library) which can be used for
easily rendering 2D graphics. Each
m will be bound to an entity. The entities will be passed to a lightweight
render manager which will iterate through all of the renderable entities and render them
in order. The simplistic nature of the programmer art expected in this game allows for a
gle background texture to be rendered for the world and all other entities to be
rendered in any given order. There is no need for depth sorting of any kind because
entities will not be allowed to overlap within this simplistic game
Story State Re
As was stated earlier, a
story can be represented as a series of locks and keys. This
will be the basis of the story actions that the storyteller can take. Encode a story state for
each plot point as a lock and a key. Have a repertoire of loc
ks and keys that the storyteller
can make available. Make it so that multiple locks have the same outcome and multiple
keys have the same outcome. This allows many locks to be opened with the same key and
many keys to open the same lock. This gives freedom
to the storyteller to plan the plot
points as lock and key combos.
The story generics will be the generic locks and keys used to encode the plot.
While the story specifics will be the specialized duplicate locks and keys that are used to
fill the void of
the story generics with the specific lock and key combos.
What follows is a pen a paper representation of an example plot point with lock
and keys. Additionally, a number of resulting story arcs are shown depending on the
player action that takes place.
cked(member_of(imperial_guard)) == false
based on player skill vs. guard skill
based on current player money vs. expected amount
kill & has_note
bribe & has_note
friend & has_note
Based on particular prerequisite
enough_money & at_shop
n current player money & skill
Based on prerequisite
An important consideration for this memory budget is the fact that this project is
being written in its entirety with Ruby.
Ruby is a scripting language with automatic
garbage collection. The affect this has on the memory of each component is drastic. For
example the GOAP plann
er’s A* algorithm can in the worst case remember an
exponential number of nodes. With a rich story dom
ain, i.e. a large number of story
actions that can occur, this search can take quite a bit of memory. An important
consideration of this project is the relatively small scope of the actual game and story.
This is more of a proof of concept type of project
so the search domain for items such as
the planner should be relatively small. Also remembering the fact that this will be a PC
based project the fact that memory might not be garbage collected at optimal times will
not be factored into the memory budget.
Without further ado:
As with the memory budget the CPU budget is very dependent on the choice of
Ruby as the
The biggest issue is that as of the latest version of Ruby,
the one used for this project, the language is entirely interpreted.
There is no
compilation to speed the language up.
As such Ruby code will run much
slowly than equivalent C/C++ code.
Another important consideration is the speed of A*. The time complexity of A*
can be polynomial in order if the heuris
tic function it uses is optimal such that the growth
difference between the chosen heuristic and the p
erfect heuristic is less than the logarithm
of the perfect heuristic.
For a new domain such as a story space an optimal heuristic
might be hard to achieve. Thus A* might turn out to actually be exponential order time
hough the story space for
this proof of concept project is once again
intentionally created to be relatively small.
Frame time (base on 16ms frame)
2D Graphics Rendering
There are several components within this project that can initially be developed
within a sandbox environment. In fact this seems to be the ideal way of developing the
individual components of this project due to the complexity of some of the
to this fact, it is imperative to have a plan for integrating these individual components
back into a cohesive whole for the project to be considered polished at the conclusion of
The components that
will require integration st
eps are the game skeleton, the
event handler, and most importantly the GOAP story system.
The most complex
component integration will undoubtedly be the GOAP story system with the rest of the
project. For this reason the GOAP story system must be one of th
e first components to be
developed as well as having the other components being designed around the interfaces
that the GOAP story system will lay a foundation for.
The integration of the story system with the event handler is of utmost
importance. This pr
ocess will be started by creating a unit testing framework for both the
story system and the event handler. Then a small test bed of story operators and events
with a few hard coded entities will work as a unit testing framework of the integrated
After this is complete, these systems will be expanded upon to create the game’s
Once the major systems have been developed the content of the actual game will
need to be created.
Unfortunately the time constraints of such an ambitious project do
allow for tools to be created which can easily facilitate this task.
For this reason all
entities will be hard coded into the actual game code along with the story plot points.
of the actual game portion of this project, su
ch an approach
should not hurt the content creation process due to the need to only modify a small
number of components.
With a new and ambitious project such as this, there are numerous risks.
new concept such as using a goal
ion planning system for controlling a story
there are likely to be many unanticipated challenges.
Here are a few of the more insidious
risks of the project.
Having never implemented A* myself, there are probably going to be certain
t people usually overcome only through experience. These are likely to be
design decisions which will affect the usage of these systems.
There is a very high probability that something like this will occur.
lity for a problem such as this. It is hard to tell
what types of challenges will be specific to this particular
implementation of A* for the required usage.
This can either potentially delay the project because the design needs to
be refactored or
can seriously impair the speed of further development
if the design is not refactored.
Hopefully this risk can be mitigated by speaking to other people who
have implemented A* before. I know of a few people in the class who
so and they should be an excellent resource to refer to
To my knowledge no one has attempted to use goal
oriented action planning on a
story telling framework before.
This means there is no resource I can turn to if I get stuck
ility of such an approach has yet to be tested.
This will be breaking entirely
There is a
probability that something like this will occur.
There is very low visibility for a problem such as this. Determining the
feasibility of this approach cannot occur until after the project has been
implemented. So there must be some faith that a new approach such as
this is feasible.
Unfortunately the impact of this is that the project will not succeed in
new story telling mechanism for video games. Despite
this fact, the purpose of this endeavor is to determine if such an
approach can work for story telling. Not succeeding in this goal is just
as important as succeeding in terms of the academic knowledge g
by creating this project.
There is very little that can be done to mitigate this risk. It is the
purpose of all new approaches to a problem to determine the feasibility
of the approach.
I have a tendency to get bored
with projects that I do not find particularly
When this happens I start procrastinating on the tasks required. If for some
reason this project turns into a boring task in my mind it is possible that I could start
There is a low probability that something like this will occur.
There is a very high visibility for a problem such as this. I can easily
tell if this is starting to happen.
The final project will be less appealing than it should be. In
fact it could
turn not to be incomplete.
There are many ways to mitigate this risk. As soon as I see this
occurring I can set a specific schedule for working on this project with
no other distractions. I can essentially lock myself int
o a room with
nothing but this project to work on and it
is guaranteed to
be less boring
than staring off into space.
These project milestones are arranged in such a way as to be two weeks apart.
They are also only planned up until the end
of this term.
By the end of this term the
completion criteria for this project is simply that the story telling system works given a
number of hard coded entities and player actions.
The next term will focus on actually
using the project so far to create
a compelling short story that dynamically incorporates a
Milestone #1: October 6
The first milestone is meant to make sure that a familiarization of Ruby and the
SDL is gained. For that reason a simple tic
toe game using the mous
e for input and
the SDL for graphics display is required.
Milestone #2: October 20
An A* algorithm has been implemented. A series of test cases using a simple grid
world with each cell having a different cost
(and visually a different color)
with it is used to test the algorithm. A user can click on two different cells and see the
resulting path between the two cells.
Initial design phase of the GOAP planning system has been implemented. This is
simply a code framework with all the required
interfaces for the system for interfacing
with the A* algorithm.
In addition to the test cases a unit testing framework has been devised which will
built upon for the duration of the project.
Anytime a test case is required
for a milestone
, it must be added to the testing framework and regression tested before
that milestone is considered complete.
Milestone #3: November 3
The GOAP planning system has now been implemented using the A* algorithm.
of test cases have been devised
with varying goals and resulting action plans
printed out to a file.
A preliminary event handler has been implemented. Each of the actions must
trigger at least three events that operate on at least two entities each. The entities must
have some sort of v
isual representation in the grid world and the events that operate on
the entities must in turn modify the visual appearance of the entities on the screen. This
can be by moving an entity, changing its color, or even destroying the entity.
There must also
be a log file of the events that have taken place during each
Milestone #4: November 17
An adventure game skeleton has been created.
A player can be spawned and
controlled by the mouse using a point and click interface.
Left clicking on a portio
n of the
world moves the player to that location using the A* algorithm.
There are other entities
scattered throughout the test world. Right clicking on an area of the screen pulls up a
context sensitive menu depending on what type of entity is clicked or
if a patch of the
world is clicked.
An initial AI has been created for NPCs. They randomly pick goals and use the
GOAP system to perform actions. They can use the A* algorithm to navigate the world.
Milestone #5: December 8
and game design doc
has been fully written up for the game.
actions required by the game design document have been fully implemented.
They have been tested out using a test map with entities in place.
story has been
codified using the GOAP st
ory system. One of the entities has been given the role of the
player and a list of goals. The entity goes through the world performing the actions using
the GOAP system. At this point the game should look like a non
interactive story that
unfolds as an ob
The milestones for next term will be to create non
temporary assets for the game.
The full game story should be codified using the GOAP system. The player should be
able to play the game. Everything should be polished
with a nice menu system and so