Thesis Technical Component Detail

pityknockInternet και Εφαρμογές Web

2 Φεβ 2013 (πριν από 4 χρόνια και 4 μήνες)

104 εμφανίσεις







Technical Component Detail for
Computer Assisted Storytelling in Video
Games


Nader Akoury


Southern Methodist University

6425 Boaz Lane

Dallas TX 75205

nakoury@smu.edu














Project Description


Project Idea




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 Game




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.


Final Produceable



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.



Desired Outcome



The desired results from this project are two
-
fold. The first is to test out if such a
story system
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
video
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.



Components


GOAP
Story
System


This goal
-
oriented action planning
(GOA
P)
system is the brain of the entire
storytelling module.
The

traditional

GOAP
algorithm
will be modified such that the next
developer created
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
algorithm
.
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

operators as
subordinates.

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.



Story Operators



The story operators are essentially a collection of
acti
ons that the GOAP
story
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.

These s
tory operators are going to depend on
the entities they perform actions on, the events they can trigger, and the
prerequisites

for
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.



Entity Manager



All the entities in the game will be

managed through a central entity manager.
This 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
manager.

The entity manager also allows an entity’s normal goal pic
king to
be
superseded

by the GOAP story system so that the story system can assign the goal for the
entity if needed by the story.


Event Handler



There will be an event passing system for passing events
among

arbitrary entit
i
es.

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.


Graphics Renderer



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
renderable ite
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
sin
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

world.



Story State Re
presentation


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.


Story State
:

path_blo
cked(member_of(imperial_guard)) == false


Keys
:




kill:

o

Prerequisites:



has_weapon



can_attack

o

Perform On:



member_of(imperial_guard)

o

Outcome:



unblock_path

o

Outcome Likelihood:



based on player skill vs. guard skill



bribe:

o

Prerequisites:



eno
ugh_money

o

Perform On:



entity(magistrate)



member_of(imperial_guard)

o

Outcome:



Bribe

o

Outcome Likelihood:



based on current player money vs. expected amount



note_of_passage:

o

Prerequisites:



booze



in_world



kill & has_note



bribe & has_note



friend & has_note

o

Perfor
m On:



member_of(imperial_guard)

o

Outcome:



unblock_path

o

Outcome Likelihood:



Based on particular prerequisite



cloak_of_invisibility:

o

Prerequisites:



in_world



monster_drop



enough_money & at_shop

o

Perform On:



self

o

Outcome:



unblock_path

o

Outcome Likelihood:



Based o
n current player money & skill



friend:

o

Prerequisites:



bribe



assisted

o

Perform On:



entity(magistrate)



member_of(imperial_guard)

o

Outcome:



unblock_path



note_of_passage

o

Outcome Likelihood:



Based on prerequisite



booze


o

Prerequisites:



in_world



enough_money

o

Perfor
m On:



entity(magistrate)



member_of(imperial_guard)

o

Outcome:



note_of_passage



friend

o

Outcome Likelihood:



high







Memory
Budget



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:



Component

Memory Usage

GOAP
Story
System

~
10 MB

Story Operators

~
5 MB

Entity Manager

~
20 MB

Game Art

~
50 MB

Code

~
5 MB



CPU Budget



As with the memory budget the CPU budget is very dependent on the choice of
Ruby as the
proj
ect
language.

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
byte code
or
machine code
compilation to speed the language up.

As such Ruby code will run much
more
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
complexity
,

t
hough the story space for
this proof of concept project is once again
intentionally created to be relatively small.


Component

Frame time (base on 16ms frame)

GOAP
Story
System

~7ms

Story Operators

~2
ms

Game Skeleton

~1ms

2D Graphics Rendering

~5ms

Event Handling

~1ms



Integ
ration Plan



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

systems.

Due
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
this project.


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
systems.

After this is complete, these systems will be expanded upon to create the game’s
skeleton.

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

not
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.

With the
minimalistic
scope

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.



Risks



With a new and ambitious project such as this, there are numerous risks.

With a
new concept such as using a goal
-
oriented act
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.


Risk #1


Having never implemented A* myself, there are probably going to be certain
challenges tha
t people usually overcome only through experience. These are likely to be
design decisions which will affect the usage of these systems.


Probability

There is a very high probability that something like this will occur.

Visibility

There is
very low
visibi
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.

Impact

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.

Mitigating the
Risk

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
have done
so and they should be an excellent resource to refer to
.




Risk #2


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
and
the feasib
ility of such an approach has yet to be tested.

This will be breaking entirely
new ground.


Probability

There is a
medium

probability that something like this will occur.

Visibility

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.

Impact

Unfortunately the impact of this is that the project will not succeed in
developing a
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
ained
by creating this project.

Mitigating the
Risk

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.



Risk #3


I have a tendency to get bored
with projects that I do not find particularly
interesting.

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
procrastinating.


Probability

There is a low probability that something like this will occur.

Visibility

There is a very high visibility for a problem such as this. I can easily
tell if this is starting to happen.

Impact

The final project will be less appealing than it should be. In
fact it could
turn not to be incomplete.

Mitigating the
Risk

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.




Milestones



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
player’s actions.



Milestone #1: October 6
th


The first milestone is meant to make sure that a familiarization of Ruby and the
SDL is gained. For that reason a simple tic
-
tac
-
toe game using the mous
e for input and
the SDL for graphics display is required.



Milestone #2: October 20
th


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)
associate
d
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
continue to
be
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
rd


The GOAP planning system has now been implemented using the A* algorithm.
A series
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
frame.


Milestone #4: November 17
th


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
th


A
story
and game design doc
ument
has been fully written up for the game.

Each
of the
entity
actions required by the game design document have been fully implemented.
They have been tested out using a test map with entities in place.

A sample

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
server watches.


Remaining Milestones


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
forth.