If you’re interested in the idea of profiling and modeling player behaviors for better gameplay, then you may want to help out with Ben Cowley’s current Ph.D. research. He’s looking for volunteers to download and play a few games of Pacman. The data will be used to find correlations between playing styles and player types, in order to adapt the gameplay accordingly.
Screenshot 1: Eating dots white avoiding ghosts.
Alex Champandard: Hi Ben. Thanks for taking the time to answer these questions. Could you introduce yourself and tell us more about your current research project?
Ben Cowley: Hi Alex, thanks for inviting me onto your blog!
I am an Irish PhD student in the University of Ulster Coleraine, just entering my final year. Although it’s a solo project, I work with the Creative Computing Coleraine group, so there’s opportunity for collaboration. Before this, I graduated from Trinity College Dublin and worked for a couple of years in low-level jobs in Dublin’s high-tech software industry – a very good reason to go back to school!
My passion in terms of research is to discover more about human cognition, especially where the brain is operating at close to optimal, or is highly engaged, or (the magic word) is having ‘fun’. Game research is really perfect for this as it’s a self-contained experience for people, that brings them toward a cognitive state that people in the optimal experience psychology research field call ‘Flow’. It is our belief that real-time in-game adaptation can adjust the game play mechanics to different players, to help put them closer to a state of Flow. While adaptation is obviously a ‘pure’ A.I. topic, a game A.I. also needs to know what it is adapting to. So some form of player modelling is needed.
Now, Flow happens in different ways for different people, and that brings us to the investigation of player type. I see types of players as a very fundamental area of player modelling that really isn’t getting enough attention, and I hope this project addresses that in some way.
AC: What are “player types” and how do they affect game design currently? Is there potential for improvement?
BC: ‘Player types’ are simply labels that we can put on common behaviors and ways of approaching game play. Different people have always had different approaches to the games they play, and there have been a couple of different models to describe that over the years. Richard Bartle (of MUDs fame) had one, and Chris Bateman had just come out with one (in his book 21st Century Game Design [Amazon US, UK]) when I started my research. I decided to go with the latter one to investigate automation of player type detection, because the research behind it was more extensively documented, and it conveniently covered the topic of Flow.
Now if you ask me, certain mainstream game designers are aware of player typologies, and maybe some of the bigger outfits might even be using them, behind the scenes, to inform design decisions. They certainly collect vast quantities of data, for instance on Steam and Xbox Live. However, I think (and I’m in no way informed about this) that overall there’s no major drive to differentiate games for player types in an automated way. We’ve all seen the Dynamic Difficulty Adjustment in Max Payne and Prey, but this is not the same as the game saying – “based on your play so far, you’re a type of player who’d like more character interaction”, or some such. I must add a caveat - I’m a long way from that too! The way I see it, there’s no drive to adapt gameplay like this, because it isn’t very saleable right now. Perhaps, as we climb out of the pit of ‘better, faster, more GPU’, that will change.
AC: To what extent is it possible to detect player type automatically? How do you go about that?
BC: Obviously, the first thing you need to do is define player type in some way that can be correlated to game play. Our approach is to give players a Likert-scale-style survey which determines their type, adapted from an original survey designed by Chris Bateman. Having their type as a classification target, we then mine their game play log for features to classify on.
Game play features come in two ‘flavours’ or levels. The lower level reflects the capabilities of the player in the game, is directly related to numerical data in the game engine, and a good example might be ‘Armour Value’ or ‘Accuracy’. These features are game specific, but easy enough to extract due to their simplicity. The higher level has to do with player attitude, is built out of lower level features or custom propositional code, and would be things like ‘Aggression’ or ‘Caution’. In fact we contend these higher level features are rather generic, and a superset can be conceived out of which any game you can think of would be covered.
So, since the low-level features are easy enough to extract due to simplicity, after the data has been gathered the hard work in this method is all about tuning. Well-chosen and –tuned features will definitely classify players in real-time with sufficient accuracy.
Once the classification rule set for each type is built, you then need to build a type classifier into your game engine. There we have one of the big stumbling blocks – I don’t see how one could detect player type in a generic fashion. It has to be done game by game. There is good news though – in my opinion, all that needs to change in the method, for each game, is the game play log that you derive your game play features from. And after all, games developed commercially are played, and logged, a lot during testing.
The last question then is whether the original evaluation of a player’s type, taken from the survey they complete, was an accurate reflection of a true class of players. This, however, is the perennial problem of classification tasks!
Screenshot 2: The original splash screen by Namco.
AC: Once you have established a correlation between gameplay and player type, what can you do with that?
BC: The $64,000 question! Of course it’s the same question as you have to ask about every player modelling method. They may seem like intrinsically great things, but you still have to translate from a model to a working adaptivity module in your games A.I.
I would envision establishing a correlation between player type and enjoyment of challenge, for starters. Challenge and skill, and the ratio between, are key components of the state of Flow, so knowing where a player lies in relation to them can help us move her closer to that state.
One can identify preferred modes of game play based on the qualitative part of the research that goes into producing a player typology. Also, the identification of features of play with player types during classification means we have a quantitative preference profile for the player, and the initial requirements for a predictive model. Preference-based predictive player models can be quite powerful, if the confidence level is high enough. And with a consistent predictive model, reclassification due to player-class drift should be considerably easier – I suppose you could say you’ve got a longer vector of comparison between model predictions and actual player behavior.
So really, the uses of a player type classification method are as broad as the player typology that forms it basis. Still, I have to admit I’m personally inclined to stop at producing a great player model!
AC: What kind of technology are you using for this process? Are you satisfied with the tools so far?
BC: Apart from hand-written code, mostly I’ve just used Clementine. It is the leading data mining package on the market, it gives you almost hassle-free data modelling algorithms like C&R Tree, Neural Nets, Kohonen maps, etc. This really cuts down on coding time!
What I would have really liked to have had access to is a good game metrics tool. I haven’t had the opportunity to use any of the ones that are out there, but I like the way they are taking this area of auto-feedback technology. In light of the process I’ve gone through in data mining raw game logs, I might have saved weeks or months if the features I derived from the game logs had been readily available.
I might have also saved a lot of time if I hadn’t had to retrofit into legacy C++ code, solutions to problems like distribution, client-server modules etc. A more modular, distributable platform like XNA might have done the trick, but I started the PhD just a hair too early for that. And as you suggested in a previous email, I could also have used Flash to really go viral online. But with my experience of Flash, I didn’t know if it would be possible to re-engineer the game engine – after gathering game play data – to do real-time type classification and predictive player modelling.
I do like the way the toolset for game design and research is going though. XNA, game metrics, integrated affective devices, are all just beginning to mature, and I look forward to working with them in future.
AC: If you had a minute to share the most valuable lesson you learned so far with game developers, what would you tell them?
BC: Democratise the means of production!
No, they already seem to be doing that. Yet this sheds light on what I would have to say – the player forms a large and responsive part of the experience you’re trying to design, and they are not 100% a black box. You should pay more attention to them, try to find out more about them, always use models. Even the simplest player model is better than a discrete difficulty setting paradigm!
Thanks for sharing your insights Ben, and best of luck with the project!