Final edits.

writeup/CS8803_P3.aux

@@ -1,13 +1,18 @@
 \relax 
 \citation{zimmerman}
 \citation{bartle}
+\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction}{1}}
 \@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces Adaptive Mario in action}}{1}}
 \newlabel{img:mario-ex}{{1}{1}}
-\citation{forgy}
+\@writefile{toc}{\contentsline {section}{\numberline {2}Related Works}{1}}
 \@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Flow State: Game Difficulty vs. Player Skill}}{2}}
 \newlabel{img:flow-state}{{2}{2}}
+\@writefile{toc}{\contentsline {section}{\numberline {3}Approach}{2}}
+\citation{forgy}
 \@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces A Simple Overland Level Grammar}}{3}}
 \newlabel{img:stochastic-grammar}{{3}{3}}
+\@writefile{toc}{\contentsline {section}{\numberline {4}Evaluation}{4}}
+\@writefile{toc}{\contentsline {section}{\numberline {5}Conclusion}{4}}
 \bibstyle{unsrt}
 \bibdata{p3refs}
 \bibcite{zimmerman}{1}

writeup/CS8803_P3.log

@@ -1,4 +1,4 @@
-This is pdfTeX, Version 3.1415926-2.3-1.40.12 (MiKTeX 2.9) (preloaded format=pdflatex 2012.1.11)  18 MAR 2012 20:22
+This is pdfTeX, Version 3.1415926-2.3-1.40.12 (MiKTeX 2.9) (preloaded format=pdflatex 2012.1.11)  18 MAR 2012 23:05
 entering extended mode
 **D:/workspace/cs8803p3/writeup/CS8803_P3.tex
 (D:/workspace/cs8803p3/writeup/CS8803_P3.tex
@@ -170,16 +170,23 @@ LaTeX Font Info:    External font `cmex10' loaded for size
 (Font)              <8> on input line 16.
 LaTeX Font Info:    External font `cmex10' loaded for size
 (Font)              <6> on input line 16.
- <mario_example.png, id=1, 642.4pt x 481.8pt>
+
+
+LaTeX Warning: Reference `mario-ex' on page 1 undefined on input line 23.
+
+Missing character: There is no â in font cmr10!
+Missing character: There is no € in font cmr10!
+Missing character: There is no ™ in font cmr10!
+<mario_example.png, id=1, 642.4pt x 481.8pt>
 File: mario_example.png Graphic file (type png)
  <use mario_example.png>
-Package pdftex.def Info: mario_example.png used on input line 23.
+Package pdftex.def Info: mario_example.png used on input line 27.
 (pdftex.def)             Requested size: 216.80669pt x 162.60416pt.
 
 <mario_underground.png, id=2, 642.4pt x 481.8pt>
 File: mario_underground.png Graphic file (type png)
  <use mario_underground.png>
-Package pdftex.def Info: mario_underground.png used on input line 24.
+Package pdftex.def Info: mario_underground.png used on input line 28.
 (pdftex.def)             Requested size: 216.80669pt x 162.60416pt.
 Missing character: There is no à in font cmr10!
 Missing character: There is no ¡ in font cmr10!
@@ -191,49 +198,67 @@ Missing character: There is no
 <flow-state.png, id=3, 305.34074pt x 223.43475pt>
 File: flow-state.png Graphic file (type png)
  <use flow-state.png>
-Package pdftex.def Info: flow-state.png used on input line 36.
+Package pdftex.def Info: flow-state.png used on input line 40.
 (pdftex.def)             Requested size: 271.0125pt x 198.33125pt.
-
+Missing character: There is no â in font cmr10!
-
+Missing character: There is no € in font cmr10!
-LaTeX Warning: `!h' float specifier changed to `!ht'.
+Missing character: There is no ™ in font cmr10!
-
+ [1
-LaTeX Font Info:    External font `cmex10' loaded for size
-(Font)              <7> on input line 45.
-LaTeX Font Info:    External font `cmex10' loaded for size
-(Font)              <5> on input line 45.
-[1
 
 {C:/ProgramData/MiKTeX/2.9/pdftex/config/pdftex.map} <D:/workspace/cs8803p3/wri
 teup/mario_example.png> <D:/workspace/cs8803p3/writeup/mario_underground.png (P
-NG copy)>] [2 <D:/workspace/cs8803p3/writeup/flow-state.png>]
+NG copy)>]
-<StochasticGrammar.png, id=15, 438.438pt x 222.8325pt>
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <7> on input line 49.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <5> on input line 49.
+Missing character: There is no â in font cmr10!
+Missing character: There is no € in font cmr10!
+Missing character: There is no ™ in font cmr10!
+ [2 <D:/workspace/cs8803p3/writeup/flow-state.png>]
+<StochasticGrammar.png, id=17, 438.438pt x 222.8325pt>
 File: StochasticGrammar.png Graphic file (type png)
 
 <use StochasticGrammar.png>
-Package pdftex.def Info: StochasticGrammar.png used on input line 89.
+Package pdftex.def Info: StochasticGrammar.png used on input line 93.
 (pdftex.def)             Requested size: 406.51875pt x 206.62346pt.
- [3 <D:/workspace/cs8803p3/writeup/StochasticGrammar.png>] (D:\workspace\cs8803
+Missing character: There is no â in font cmr10!
-p3\writeup\CS8803_P3.bbl) [4]
+Missing character: There is no € in font cmr10!
-(D:\workspace\cs8803p3\writeup\CS8803_P3.aux) ) 
+Missing character: There is no ™ in font cmr10!
+ [3 <D:/workspace/cs8803p3/writeup/StochasticGrammar.png>]
+Missing character: There is no â in font cmr10!
+Missing character: There is no € in font cmr10!
+Missing character: There is no ™ in font cmr10!
+Missing character: There is no â in font cmr10!
+Missing character: There is no € in font cmr10!
+Missing character: There is no ™ in font cmr10!
+Missing character: There is no â in font cmr10!
+Missing character: There is no € in font cmr10!
+Missing character: There is no ™ in font cmr10!
+ [4] (D:\workspace\cs8803p3\writeup\CS8803_P3.bbl) [5]
+(D:\workspace\cs8803p3\writeup\CS8803_P3.aux)
+
+LaTeX Warning: There were undefined references.
+
+ ) 
 Here is how much of TeX's memory you used:
- 1914 strings out of 494045
+ 1919 strings out of 494045
- 26222 string characters out of 3145969
+ 26282 string characters out of 3145969
- 89718 words of memory out of 3000000
+ 90718 words of memory out of 3000000
- 5219 multiletter control sequences out of 15000+200000
+ 5224 multiletter control sequences out of 15000+200000
  7804 words of font info for 28 fonts, out of 3000000 for 9000
  715 hyphenation exceptions out of 8191
- 27i,7n,32p,877b,220s stack positions out of 5000i,500n,10000p,200000b,50000s
+ 27i,7n,32p,1715b,220s stack positions out of 5000i,500n,10000p,200000b,50000s
-<C:/Program Files (x86)/MiKTeX 2
+<C:/Program Files (x86)/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmbx10.pfb>
-.9/fonts/type1/public/amsfonts/cm/cmbx10.pfb><C:/Program Files (x86)/MiKTeX 2.9
+<C:/Program Files (x86)/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmbx12.pfb><C
-/fonts/type1/public/amsfonts/cm/cmbx12.pfb><C:/Program Files (x86)/MiKTeX 2.9/f
+:/Program Files (x86)/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmr10.pfb><C:/P
-onts/type1/public/amsfonts/cm/cmr10.pfb><C:/Program Files (x86)/MiKTeX 2.9/font
+rogram Files (x86)/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmr12.pfb><C:/Prog
-s/type1/public/amsfonts/cm/cmr12.pfb><C:/Program Files (x86)/MiKTeX 2.9/fonts/t
+ram Files (x86)/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmr17.pfb><C:/Program
-ype1/public/amsfonts/cm/cmr17.pfb><C:/Program Files (x86)/MiKTeX 2.9/fonts/type
+ Files (x86)/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmti10.pfb><C:/Program F
-1/public/amsfonts/cm/cmti10.pfb><C:/Program Files (x86)/MiKTeX 2.9/fonts/type1/
+iles (x86)/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmtt10.pfb>
-public/amsfonts/cm/cmtt10.pfb>
+Output written on CS8803_P3.pdf (5 pages, 155888 bytes).
-Output written on CS8803_P3.pdf (4 pages, 151195 bytes).
 PDF statistics:
- 47 PDF objects out of 1000 (max. 8388607)
+ 50 PDF objects out of 1000 (max. 8388607)
  0 named destinations out of 1000 (max. 500000)
  21 words of extra memory for PDF output out of 10000 (max. 10000000)
 

writeup/CS8803_P3.tex

@@ -15,8 +15,12 @@
 
 \maketitle
 
-\section*{Introduction}
+\section{Introduction}
-The authors of Adaptive Mario use several procedural content generation (PCG) techniques to develop a simple platform-jumper engine which adjusts to player preferences and skills to guide the player toward the ideal game-play experience.  The Adaptive Mario design is intended to ensure that he maximum amount of replayability is delivered, considering the limited multimedia assets and game-play mechanics of the Infinite Mario engine on which it is based.
+The game mechanics of the Super Mario world are celebrated and well-understood. Indeed, even in this age of super-computer graphics and Hollywood-level production values, few games can match the pure enjoyment delivered by this simple 8-bit Nintendo platform jumper.  Here, we endeavor not to change that formula, but to imbue it with a modern, artificial-intelligence driven approach to enhance the game-play experience.
+ 
+In creating Adaptive Mario, we use several procedural content generation (PCG) techniques built upon this simple platform-jumper engine. Our algorithms adjust to player preferences and skills, and guide players toward an ideal game-play experience. Our design is intended to ensure that the maximum amount of replay value is delivered, considering the limited multimedia assets and game-play mechanics of the Infinite Mario engine on which it is based.
+ 
+Every Mario level has the implicit goal of progressing from left to right until the completion gate appears, all the while keeping Mario safe.  A number of more esoteric subgoals also arise, such as destroying enemies, collecting coins, and minimizing time of completion. Our conceptual design goal, however, was a bit different.  As shown in Figure \ref{mario-ex} we aim to provide players with different styles of play and skill levels with distinct and customized game-play experience from the moment the level begins. The process of generating a level consists of a number of steps. First, a player profile is drawn based on the player’s performance in an average, non-customized level. That data is fed into our generation engine to guide the creation of subsequent levels.  The level generation pipe-line is explained in full detail in \emph{Section 3 Approach}.
 
 \begin{figure}[h!]
 \centering
@@ -28,17 +32,17 @@ The authors of Adaptive Mario use several procedural content generation (PCG) te
 
 As shown in Figure \ref{img:mario-ex}, the conceptual goal is that players with different play styles and skill levels should have a very different game-play experience from the moment the level begins.  The very first time Adaptive Mario is run in a new environment, a random level is presented based on an a priori model of an 'average' player.  A high degree of randomness at this point allows the player to freely choose a game-play style rather than being constrained by a prefabricated environment.
 
-\section*{Related Works}
+\section{Related Works}
-The essential goal of Adaptive Mario is to facilitate flow state by giving the player sufficient challenge and variety without rapidly becoming too difficult.  As defined by Mihály Csíkszentmihályi, according to Salen and Zimmerman \cite{zimmerman}, ``flow'' is the state of total immersion and concentration in which the player believes he or she is overcoming obstacles by the narrowest of margins.  As shown in Figure \ref{img:flow-state}, achieving this state involves a delicate balance between the difficulty of the game and the player's degree of skill.  If the game is too hard, the player will become frustrated.  On the other hand, most players will become bored if the game is too easy.
+A fundamental concept in the design of Adaptive Mario is \emph{flow}. As defined by Mihály Csíkszentmihályi, according to Salen and Zimmerman \cite{zimmerman}, flow is a state of total immersion and concentration in which the player believes he or she is overcoming obstacles by the narrowest margins. As shown in Figure \ref{img:flow-state}, achieving this state involves a delicate balance between the difficulty of the game and the degree of the player's skill. If the game is too hard, the player will become frustrated. On the other hand, most players will become bored if the game is too easy. Our overarching goal was to facilitate a flow state by giving the player sufficient challenge and variety without rapidly becoming too difficult.
 
-\begin{figure}[h!]
+\begin{figure}%[h!]
 \centering
 \includegraphics[width=0.5 \textwidth]{flow-state.png}
 \caption{Flow State: Game Difficulty vs. Player Skill}
 \label{img:flow-state}
 \end{figure}
-
+ 
-In order to gauge the requisite level is difficulty, it is first necessary to develop a model of the player's ability.  Numerous models of player psychology have been proposted since Richard Bartle's 1996 study of MUD (Multi-User Dungeon) players \cite{bartle}.  Some examples are:
+This theory presents two variables: challenge and skill. Adapting the difficulty of a level is well within our purview as game designers, but the level of difficulty required to generate flow state depends on the player’s skill level. We therefore first developed a model of player psychology and ability. Numerous such models have been proposed since Richard Bartle's 1996 study of MUD (Multi-User Dungeon) players \cite{bartle}, all of which attempt to classify a player into a category or type. In developing our model, we considered some notable examples:
 
 \begin{table}[ht]
 \centering
@@ -51,15 +55,13 @@ John Radoff & Immersion, Cooperation, Achievement, Competition \\ \hline
 \end{tabular}
 \end{table}
 
-The Adaptive Mario PlayerProfileMatcher class assigns the player one of five roles based on past performance: BUMPER, COLLECTOR, JUMPER, RUNNER or SHOOTER.  This model is loosely based on Bartle's extended model, with BUMPER corresponding to Planner, in the sense that the player is observed to interact with the environment by bumping bricks and throwing shells.  This model differs from the examples above primary in that social elements are not evaluated, since Mario is a single-player game.
+The Adaptive Mario PlayerProfileMatcher class assigns the player one of five roles based on past performance: BUMPER, COLLECTOR, JUMPER, RUNNER or SHOOTER.  This model is loosely based on Bartle's extended model, with BUMPER corresponding to Planner, in the sense that the player is observed to interact with the environment by bumping bricks and throwing shells.  However, our model necessarily differs somewhat from the above examples, as Adaptive Mario is a single-player game with no social element.
 
-\section*{Level Generator Design}
+\section{Approach}
 The Adaptive Mario level generator functions as a 4-stage pipeline composed of a Profile Matcher, Level Archetype Selector, Level Generator and Challenge Component Creator.
 
 \subsection*{Profile Matcher}
-The first step of the level generation process is to evaluate the player's style and skill level.  Adaptive Mario uses the output file ``player.txt'' generated by the GamePlay class during the most recent game, if available.  In addition, more detailed statistics from the DataRecorder class are preserved as XML and are used by some components of the level generator.  The ProfileMatcher scores aspects of game-play such as number of kills, jumps and coins collected in order to evaluate the player's skill in the areas of running, jumping, collecting, shooting.  This vector of skills, rated on a range of 1 - 100, is then compared against a pre-calculated 'typical' vector for each of the five player types using a simple mean-squared error metric.  The player is then given the profile matching the most similar set of skills.
+The first step of the level generation process is to evaluate the player's style and skill level. Adaptive Mario uses the output file ``player.txt'' generated by the GamePlay class during the most recent game, if available. If no player data is available, as in a first run of the game, a simple, un-weighted level is generated, to assist in collecting baseline player data for future runs. More detailed statistics from the DataRecorder class are preserved as XML and are used by some components of the level generator. The ProfileMatcher scores aspects of game-play such as number of kills, jumps, and coins collected in order to evaluate the player's skill in the five identified areas of competency and generate a vector of skill values, within a range of 1 -- 100. The relative weight of each different skill is maintained by the player profile for reference by later segments of the level creation process. Here, the player is also assigned a type based on his or her most dominant trait, and an overall skill level: expert, proficient, competent, beginner, or novice. A player’s skill level is based on a number of different factors. First of all, his or her average skill level across the skill vector  is included. The speed with which the previous level was completed is integrated, as a player who finds a level too easy can complete it quickly and without error. Finally, the number of times their power-up state changed; if a player is not being threatened or hurt will tend to remain in one power-up state through much of a level, with few changes.  A weighted overall skill score is produced and mapped to one of the five skill levels  as shown below.
-
-In addition to assigning a player profile, the ProfileMatcher assesses the player's skill level by comparing specific metric against an ideal score assigning the player one of five skill levels: Novice, Beginner, Competent, Proficient or Expert.  These categories are based on the Dreyfus model of skill acquisition with each successive level representing an achievement of 20% of the Profile's key skill maximum score, before penalties.  Actions such as dying or making unnecessary jumps negatively impact the skill assessment.
 
 \begin{table}[ht]
 \centering
@@ -74,6 +76,8 @@ Score & Skill Level & Attributes\\ \hline
 \end{tabular}
 \end{table}
 
+These categories are based on the Dreyfus model of skill acquisition with each successive level representing an achievement of 20\% of the Profile's key skill maximum score, before penalties.  Actions such as dying or making unnecessary jumps negatively impact the skill assessment.
+
 \subsection*{Level Archetype Selection}
 The Level Archetype selector picks an overall macro-form for the level based on the player's profile and skill level.  As there are five categories and only three distinct environments in the Inifinite Mario engine (Overland, Underground and Castle), different profiles cause similar Level Archetypes to be generated.  However, this does provide the opportunity to indicate to the player what types of challenges lie ahead and may serve to enhance immersion.
 
@@ -94,11 +98,11 @@ Given a suitable array of predefined LevelComponent types, each of which corresp
 One potential pitfall of using a CFG for this purpose is that the generated level may be over-specified (containing too many elements) and hence too crowded, or under-specified and nearly empty.  To mitigate this problem, a fitness evaluation function iteratively invokes the LevelGrammar class's generateRandomTree() method, rejecting proposed levels with too many or too few LevelComponents.
 
 \subsection*{Challenge Components: Micro-structure}
-Challenge components are small puzzles that lend variety to the randomized levels and serve a dual purpose in allowing Adaptive Mario to fit the player's preferred style.
+Challenge components are the building blocks of an Adaptive Mario level. Each challenge component represents a small puzzle or level element. Each level consists of a sequence of challenge components. Through only a small number of these components, we have achieved a wide variety of possible levels. In fact, the challenge components induce variety and adapt to the player’s style in the following ways.
-
+ 
-First, by providing ever more difficulty scenarios, challenge is maintained.  This trend also prevents a feedback loop wherein a player jumps frequently because a level contains many platforms, which causes the next level to contain many jumping puzzles and so on.
+First, the selection of components plays a large role in defining the character of a level. Many challenges are better suited for different play styles, based on the skills they require to traverse or the rewards they cause a player to incur. This allows a level to shift toward a more engaging landscape for a player of a particular style. Second, each challenge component dynamically adjusts its difficulty based on the player’s skill level.  The player’s skill competencies affect the number of enemies they encounter, the number of power-ups they are offered, the number of coins placed on a level, the difficulty of the enemies they face, the size and number of pits in a level, and the types of terrain encountered. Because challenge components are so dynamic, even a single challenge element encountered repeatedly can present and engaging challenge.
-
+ 
-Second, specific Challenges can be chosen to allow Adaptive Mario to discriminate between play styles when a player's metrics are borderline between two typical profiles.  Thus a player who is both a Runner and a Jumper could be given a very difficult jumping challenge to cause the metrics to trend one way or the other.  However, this advanced adaptation was not implemented during this iteration of the project.
+An additional benefit of challenge components is their modularity. Though we have implemented a strong suite of challenges, innumerable more are possible. With the implementation of a function and slight modification of the level generation grammar, new challenges can be added to Adaptive Mario to make it even more variable and extend its replay value further.
 
 \begin{table}[ht]
 \centering
@@ -118,17 +122,15 @@ Difficulty & Challenge Component & Description \\ \hline
 \end{tabular}
 \end{table}
 
-\section*{Evaluation}
+\section{Evaluation}
-Several challenges were overcome during the implementation of Adaptive Mario.  From a technical standpoint, finding a Java-compatible Rete rule engine (Drools) was a time-consuming effort, mainly due to the large number of third-party JAR dependencies.  Sufficient time was invested in this endeavor before integration was ultimately successful that the role of the rules engine was minimized during the design process.  Consequently, only basic alterations are made to the random level structure based on the player profile.
+Developing Adaptive Mario presented several challenges. From a technical standpoint, finding a Java-compatible Rete rule engine became a time-consuming effort, due mostly to the large number of third-party JAR dependencies. Ultimately, we were able to incorporate the Drools engine into our code base. The amount of time, however, that was invested in doing so forced the minimization of role of the rules engine. It therefore makes only basic alterations to random levels based on the player profile.
+ 
+Randomized level generation using a stochastic CFG was largely successful, however. Not only can our very simple grammar generate a huge variety of levels, the implementation of a parser for the rule set allows future designers to make meaningful content changes without needing to recompile source code. Such grammars are, of course, limited to some degree. The grammar by definition lacks any contextual awareness. It therefore does nothing to avoid awkward juxtaposition of challenge components. Though challenge components are self-contained such that transition between any two should not present a problem, we nonetheless recognize this stratification as a limitation of our architecture.
+ 
+Perhaps the most challenging aspect of our development process was the creation of the PlayerProfile. Each level is generated based on player data from only the single previous level traversal. Thus, the terrain of a previous level may have an inordinate effect on the evaluation of a player’s current tastes. We built our ProfileMatcher to minimize this possibility, but it nonetheless exists. A more complex version of Adaptive Mario would benefit greatly from a more iterative and flexible approach to player modeling, perhaps by employing an artificial neural network or Bayesian inference. These techniques would allow for more accurate and therefore useful scoring values, but would require more involved modification of the game engine.
 
-Randomized level generation using a stochastic CFG was largely successful, however.  Not only can this very simple grammar generate a variety of levels, implementation of a parser for the rule set allows a designer to make meaningful content changes without the need to recompile source code.  Such grammars are limited of course - integration between the top-down macro generation code and bottom-up Challenge Component code was a challenge, as the LevelGrammar module lacks the capacity to plan ahead and avoid awkward juxtapositions of LevelComponents.
+\section{Conclusion}
-
+It seems clear from these results that the framework of Adaptive Mario has the potential to guide the player toward his or her own idealized version of a platform game, while still presenting a reasonable level of challenge.  Not only does difficulty scale in proportion to the player's performance (preventing frustration), but care is taken in the design of the level grammar to avoid repeatedly giving the player 'more of the same' (leading to boredom).  We certainly recognize many areas ripe for improvement (such as the limited level grammar), yet Adaptive Mario as currently implemented represents a robust engine. It provides tools for the adaptive content designer and new experiences for the consumer.  It certainly adds a novel twist on the genre for any platform gaming enthusiast.
-While the arbitrary scoring and single-iteration feedback loop of the PlayerProfile module functions as designed, the core PlayerProfile model represents the most promising area of improvement for a future version of Adaptive Mario.  Because small changes to the scoring weights can make a great difference in determining which level-building rules are ultimately invoked, better tuning of these parameters is vital.  Consequently, this package would benefit greatly from use of more advanced techniques (perhaps Artificial Neural Networks or Bayesian inference) to discover more accurate scoring values.
-
-\section*{Conclusion}
-It seems clear from the results that the framework of Adaptive Mario has the potential to guide the player toward his or her own idealized version of a platform game, while still presenting a reasonable level of challenge.  Not only does difficulty scale in proportion to the player's performance (preventing frustration), but care is taken in the design of the level grammar to avoid repeatedly giving the player 'more of the same' (leading to boredom).  One potential issue exists, however - it is possible that some players simply are not fans of the platform jumper genre!
-
-Fortunately, the architecture of Adaptive Mario (and the externalization of the rule engine and level grammar in particular) means that the designer is not limited to the side-scrolling platform jumper palette.  It is easy to imagine that Adaptive Mario could be transformed into a Roguelike or adventure game without substantially altering the core Mario mechanics.  Just as the player is freed from the constraints of pre-generated content, the designer (or hobbyist) is given the necessary tools to alter the game world as desired.
 
 \section*{Appendix A: Building the Game}
 Building the Project 3 executable requires a Java SDK version 1.6+ and Apache Ant.
@@ -139,10 +141,6 @@ To build the game, execute \texttt{ant clean} followed by \texttt{ant} from the
 
 To run the game, change to the `dist' subdirectory following a successful build and execute \texttt{java -jar CS8803\_P3.jar}.
 
-\begin{description}
-\item[seed] random number generator seed value (\texttt{long})
-\end{description}
-
 \bibliographystyle{unsrt}
 \bibliography{p3refs}