Work in progress.

writeup/CS8803_P3.tex

@@ -9,58 +9,92 @@
 \begin{document}
 \pagestyle{empty}
 
-\title{CS8803 Game AI Project 3}
+\title{Adaptive Mario : CS8803 Game AI Project 3}
 \author{Woody Folsom and Marshall Gillson}
 \date{March 18, 2012}
 
 \maketitle
 
 \section*{Introduction}
-Here is an example of citing \emph{AI for Games} \cite{millington} and another for citing \emph{Russel \& Norvig} \cite{russelnorvig}.  An example graphic image follows.  Note that the [h!] causes it to be displayed at this exact location rather than moving it to allow for best text layout.
+The authors of Adaptive Mario use several PCG techniques to develop a simple platform-game engine which adjusts to player preferences and skills to guide the player toward the ideal flow-state.  This architecture should ensure that he maximum amount of replayability is delivered, considering the limited multimedia assets and gameplay mechanics of the Infinite Mario engine on which it is based.
 
 \begin{figure}[h!]
 \centering
 \includegraphics[width=0.4 \textwidth]{mario_example.png}
-\caption{This is an example screenshot}
+\includegraphics[width=0.4 \textwidth]{mario_example.png}
+\caption{Adaptive Mario in action}
 \label{img:mario-ex}
 \end{figure}
 
-Here [Fig. \ref{img:mario-ex}] is a link to the image above.
+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 gameplay experience from the moment the level begins.  Of course, the very first time Adaptive Mario is run in a new environment, a specific level is presented based on an a priori model of an 'average' player.
 
 \section*{Related Works}
-Below is an example of an unordered list of terms:
+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, ``flow'' is the state of total immersion and cocentration 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.
+
+\begin{figure}[h!]
+\centering
+\includegraphics[width=0.4 \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:
+
 \begin{description}
-\item[Richard Bartle Model]
-\item[Nick Yee Model]
-\item[John Radoff Model]
+\item[Richard Bartle's Player Types] Killer, Socializer, Achiever, Explorer
+\item[Nick Yee's Player Motivations] Relationships, Immersion, Grief, Achievement, Leadership	
+\item[John Radoff's Player Motivations] Immersion, Cooperation, Achievement, Competition
 \end{description}
 
-Here is a short table copied from my Project \#2:
-
-\begin{center}
-    \begin{tabular}{ | l | l | l | l | l |}
-    \hline
-    Seed & Heuristic & Time Remaining & Surived & Coins \\ 
-    \hline
-    1582108229 & AStarAgent & 175 & Yes & 24 \\
-    1582108229 & CoinSeeker & 134 & No & 8 \\ \hline
-    1200022400 & AStarAgent & 170 & Yes & 7 \\
-    1200022400 & CoinSeeker & 127 & Yes & 9 \\ \hline
-    \end{tabular}
-\end{center}
+The Adaptive Mario PlayerProfile assigns the player one of five roles, based on past performance: BUMPER, COLLECTOR, JUMPER, RUNNER and SHOOTER.  This model is loosely based on Bartle's extended model, with BUMPER corresponding to manipulator, in the sense that the player is observed to manipulate 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.
 
 \section*{Level Generator Design}
-\subsection*{Profile Matcher}
+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 gameplay 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 precalculated '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.
+
+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 reperesnting 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
+\begin{tabular}{ | l | l | l | }
+\hline
+Score & Skill Level & Attributes\\ \hline
+20\% & Novice & low situational awareness, reflexive responses\\ \hline
+40\% & Beginner & uses judgement to react to challenges, limited awareness \\ \hline
+60\% & Competent & copies with multiple challenges, uses sound strategy \\ \hline
+80\% & Proficient & makes rapid decisions, prioritzes goals \\ \hline
+100\% & Expert & intuitively solves challenges, pushes boundaries \\ \hline
+\end{tabular}
+\end{table}
 \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.
+
+Next, the Level Archetype is further customized for the player by disabling challenges and enabling rewards according to a predined set of rules.  In order to allow the rule set to be easily customized and extended, Adaptive Mario uses Drools, an implementation of Charles Forgy's 1982 Rete algorithm.  Once the appropriate rules have fired, level generation proceeds to the third stage: macro-structure generation.
 
 \subsection*{Level Generation: Macro-structure}
+The task of the macro-structure generator is to deliver a list of seqeuential Mario level design elements (LevelComponents) based on a high level description similar to ``Overland level with gaps but no pipes, difficulty 5/10''.  Several algorithms were considered during the planning phase of this module.  A Genetic Algorithm approach could potentially produce novel levels, but judging the relative fitness of candidate levels could be problematic.  Hierarchical task networks (HTNs) and rhythm-based approaches have also been used, but tend to generate levels with a very uniform structure in a single pass.  For ease of modification and to leverage the authors' design intuition, a context-free grammar (CFG) was implemented instead.
+
+Given a suitable array of predefined LevelComponent types, each of which corresponds to one or more Infinite Mario game sprites, the structure of a level archetype can be completely specified in the form of a file-based CFG.  As shown in the following example, the OR clauses are assigned probability values, giving a stochastic property to the generated level structure.
+
+\begin{figure}[h!]
+\centering
+\includegraphics[width=0.75 \textwidth]{StochasticGrammar.png}
+\caption{A Simple Overland Level Grammar}
+\label{img:stochastic-grammar}
+\end{figure}
+
+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, rejecting proposed levels with too many or too few LevelComponents.
 
 \subsection*{Challenge Components: Micro-structure}
 
 \section*{Evaluation}
 
 \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 pregenerated 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.
@@ -69,7 +103,7 @@ To build the game, execute \texttt{ant clean} followed by \texttt{ant} from the
 
 \section*{Appendix B: Running the Game}
 
-To run the game, change to the `dist' subdirectory following a successful build and execute \texttt{java -jar CS8803\_P3.jar generator=[AgentName]}.  Valid level generator names include: SGrammarGenerator, LSystemGenerator:
+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})