Very rough draft of write-up (not proof-read).
This commit is contained in:
@@ -21,7 +21,7 @@ The authors of Adaptive Mario use several PCG techniques to develop a simple pla
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
\includegraphics[width=0.4 \textwidth]{mario_example.png}
|
||||
\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}
|
||||
@@ -29,11 +29,11 @@ The authors of Adaptive Mario use several PCG techniques to develop a simple pla
|
||||
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, ``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.
|
||||
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.4 \textwidth]{flow-state.png}
|
||||
\includegraphics[width=0.5 \textwidth]{flow-state.png}
|
||||
\caption{Flow State: Game Difficulty vs. Player Skill}
|
||||
\label{img:flow-state}
|
||||
\end{figure}
|
||||
@@ -61,13 +61,14 @@ In addition to assigning a player profile, the ProfileMatcher assesses the playe
|
||||
\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
|
||||
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.
|
||||
|
||||
@@ -88,8 +89,38 @@ 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, 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!
|
||||
|
||||
Reference in New Issue
Block a user