\documentclass[letterpaper,10pt]{article}

\usepackage{titlesec}
\usepackage[margin=0.5in]{geometry}
\usepackage{graphicx}

\titleformat{\section}{\large\bfseries}{\thesection}{1em}{}

\begin{document}
\pagestyle{empty}

\title{Adaptive Mario : CS8803 Game AI Project 3}
\author{Woody Folsom and Marshall Gillson}
\date{March 18, 2012}

\maketitle

\section*{Introduction}
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}
\includegraphics[width=0.4 \textwidth]{mario_underground.png}
\caption{Adaptive Mario in action}
\label{img:mario-ex}
\end{figure}

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}
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 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.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:

\begin{description}
\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}

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}
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 & Copes with multiple challenges, Uses sound strategy \\ \hline
80\% & Proficient & Makes rapid decisions, Prioritzes goals \\ \hline
100\% & Expert & Intuitively solves challenges, Pushes limits \\ \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}
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.

First, by providing ever more difficulty scenarios, challenge is mainted.  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.

Second, specific can could be chosen to allow Adaptive Mario to discriminate between playstyles 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.

\begin{table}[ht]
\centering
\begin{tabular}{ | l | l | l | }
\hline
Difficulty & Challenge Component & Description \\ \hline
1 & Coin Dive & Some empty blocks, coins line the path to the ground.\\ \hline
2 & Free power-up & Sets the player up to get a power-up with little or no challenge.\\ \hline
3 & Straight & A straight stretch of land with maybe one enemy and maybe some coins or blocks\\ \hline
4 & Single Pit & A pit that the user must jump over; rocks on either side.\\ \hline
5 & Bowling Alley & A red koopa right before a long line of enemies. Kill them all!\\ \hline
6 & Cannon Line & A stack of 2 or 3 cannons.\\ \hline
7 & Maze & A maze of indestructible blocks, with enemies.\\ \hline
8 & Lemming Trap & A little pit with a few enemies that jump down into it.\\ \hline
9 & Platform Jump & A bunch of platforms to jump between.\\ \hline
10 & Pipe Jump & A bunch of thin pipes to jump between.\\ \hline
\end{tabular}
\end{table}

\section*{Evaluation}
Several challenges were overcome during the implementation of Adaptive Mario.

From a technical standpoint, finding a Java-compatible 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.

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 capability to plan ahead and avoid akward juxtapositions of LevelComponents.

While the arbitrary scoring and single-iteration feedback loop of the PlayerProfile module functions as designed, the core PlayerProfile model reperesents the most likely area of improvement in the next 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 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 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.

To build the game, execute \texttt{ant clean} followed by \texttt{ant} from the main project directory.  

\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}.

\begin{description}
\item[seed] random number generator seed value (\texttt{long})
\end{description}

\bibliographystyle{unsrt}
\bibliography{p3refs}

\end{document}