wfolsom/cs8803p4
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'master' of woodyfolsom.net:/opt/git/cs8803p3

Browse Source
This commit is contained in:
Marshall
2012-03-18 19:57:52 -04:00
parent aa5d9099f1 fdedf70546
commit f03577a822
5 changed files with 30 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
writeup/CS8803_P3.aux
View File

@@ -3,8 +3,8 @@
\citation{bartle}
\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces Adaptive Mario in action}}{1}}
\newlabel{img:mario-ex}{{1}{1}}
\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Flow State: Game Difficulty vs. Player Skill}}{2}}
\newlabel{img:flow-state}{{2}{2}}
\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Flow State: Game Difficulty vs. Player Skill}}{1}}
\newlabel{img:flow-state}{{2}{1}}
\@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces A Simple Overland Level Grammar}}{3}}
\newlabel{img:stochastic-grammar}{{3}{3}}
\bibstyle{unsrt}

26
writeup/CS8803_P3.log
View File

@@ -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 18:45
This is pdfTeX, Version 3.1415926-2.3-1.40.12 (MiKTeX 2.9) (preloaded format=pdflatex 2012.1.11) 18 MAR 2012 19:06
entering extended mode
**D:/workspace/cs8803p3/writeup/CS8803_P3.tex
(D:/workspace/cs8803p3/writeup/CS8803_P3.tex
@@ -192,26 +192,22 @@ Missing character: There is no
File: flow-state.png Graphic file (type png)
<use flow-state.png>
Package pdftex.def Info: flow-state.png used on input line 36.
(pdftex.def) Requested size: 271.0125pt x 198.33125pt.
LaTeX Warning: `!h' float specifier changed to `!ht'.
[1
(pdftex.def) Requested size: 162.60915pt x 118.99261pt.
[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)>]
NG copy)> <D:/workspace/cs8803p3/writeup/flow-state.png>]
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <7> on input line 61.
(Font) <7> on input line 45.
LaTeX Font Info: External font `cmex10' loaded for size
(Font) <5> on input line 61.
[2 <D:/workspace/cs8803p3/writeup/flow-state.png>]
<StochasticGrammar.png, id=16, 438.438pt x 222.8325pt>
(Font) <5> on input line 45.
[2]
<StochasticGrammar.png, id=15, 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 84.
Package pdftex.def Info: StochasticGrammar.png used on input line 89.
(pdftex.def) Requested size: 406.51875pt x 206.62346pt.
[3 <D:/workspace/cs8803p3/writeup/StochasticGrammar.png>] (D:\workspace\cs8803
p3\writeup\CS8803_P3.bbl) [4]
@@ -219,7 +215,7 @@ p3\writeup\CS8803_P3.bbl) [4]
Here is how much of TeX's memory you used:
1913 strings out of 494045
26215 string characters out of 3145969
87715 words of memory out of 3000000
89715 words of memory out of 3000000
5218 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
@@ -232,7 +228,7 @@ s/type1/public/amsfonts/cm/cmr12.pfb><C:/Program Files (x86)/MiKTeX 2.9/fonts/t
ype1/public/amsfonts/cm/cmr17.pfb><C:/Program Files (x86)/MiKTeX 2.9/fonts/type
1/public/amsfonts/cm/cmti10.pfb><C:/Program Files (x86)/MiKTeX 2.9/fonts/type1/
public/amsfonts/cm/cmtt10.pfb>
Output written on CS8803_P3.pdf (4 pages, 153381 bytes).
Output written on CS8803_P3.pdf (4 pages, 148402 bytes).
PDF statistics:
47 PDF objects out of 1000 (max. 8388607)
0 named destinations out of 1000 (max. 500000)

BIN
writeup/CS8803_P3.pdf
View File

Binary file not shown.

BIN
writeup/CS8803_P3.synctex.gz
View File

Binary file not shown.

31
writeup/CS8803_P3.tex
View File

@@ -16,7 +16,7 @@
\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.
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 gameplay experience. The Adapative Mario design is intended to 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
@@ -33,20 +33,25 @@ The essential goal of Adaptive Mario is to facilitate flow state by giving the p
\begin{figure}[h!]
\centering
\includegraphics[width=0.5 \textwidth]{flow-state.png}
\includegraphics[width=0.3 \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}
\begin{table}[ht]
\centering
\begin{tabular}{ | l | l | }
\hline
Author & Player Model\\ \hline
Richard Bartle & Killer, Socializer, Achiever, Explorer\\ \hline
Nick Yee & Relationships, Immersion, Grief, Achievement, Leadership \\ \hline
John Radoff & Immersion, Cooperation, Achievement, Competition \\ \hline
\end{tabular}
\end{table}
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.
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.
\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.
@@ -93,7 +98,7 @@ Challenge components are small puzzles that lend variety to the randomized level
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.
Second, specific Challenges can 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
@@ -114,13 +119,11 @@ Difficulty & Challenge Component & Description \\ \hline
\end{table}
\section*{Evaluation}
Several challenges were overcome during the implementation of Adaptive Mario.
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.
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 capacity to plan ahead and avoid akward juxtapositions of LevelComponents.
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.
While the arbitrary scoring and single-iteration feedback loop of the PlayerProfile module functions as designed, the core PlayerProfile model reperesents 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!