Thursday, June 19, 2014

Pitfalls of "Plus Alpha" Game Design

First, let me clarify what I mean by "Plus Alpha" game design. Let's say there's a game that just came out, called "Shootman" where you run around and shoot enemies with a gun, controlling your character from a first person perspective and running through mazes. This game is popular because before it game out, no other game had done this. The publisher was successful with this game, and fans of the game want more, so the publisher releases a new game, which they design like this: "What new features can we add to Shootman to create a new experience?" This is the formation/codification/CoD-ification of genre lines in action, and similar effects can be observed in music, literature, and board games. Anyway, the developer ends up making a game that's like "Shootman" except with jumping and platforming, or like "Shootman" with a focus on puzzles, or like "Shootman" with a elemental-weakness-based combat system... and the game is okay.

This style of game design has plagued recent AAA titles in video-gaming because from a business perspective it makes a lot of sense. It's low-risk, high reward. Part of what drew me into board games to begin with was the innovation in design; there wasn't really such a thing as 'genre' beyond the theme of the game (or lack thereof). Sure, common mechanisms existed, but those mechanisms were things like "tile-laying" (putting a thing next to another thing) "bidding" (any number of different twists on bidding) "area majority" (most things in a place wins) but those common mechanisms are very, very vague. Agricola and Dominion are the "Doom" or "Wolfenstein" of Board Gaming, (Yes, I'm aware that Agricola isn't the "true" first worker-placement game by whatever completely bastardized definition of that term BGG is using today.) Two "Bidding" games can feel very very different. Two "Area Majority" games can feel very very different. But with few exceptions, Worker Placement and Deck Building games are designed like "Plus Alpha" games. If I can teach a game in two minutes by saying "You've played Dominion? Okay, this is like that but..." then there's something... well, maybe I don't want to say "wrong" but something strange.

In music, "plus alpha" often occurs when fanbases want to make their favorite band's next album for them. Some good music can come out of this, and some healthy, vibrant, interesting "scenes" can develop out of this. One good example is the recent "Midwest Emo Revival" where many bands have latched onto a certain style of music and (with relatively little variation) keep producing competent albums that sound a lot like the next album American Football or Mineral might have released. I won't say what they're making is bad music; I quite enjoy a lot of it. I'm not even concerned that it's derivative, and don't resent the creators for having influences. But when you set out to design something but you already have the blueprint in mind, you are not really doing much of the designing. As such, you're unlikely to make anything new or amazing. But you can make something that's okay.

People latch onto "Plus Alpha" because of the familiarity. With games, this is doubly true; players of Shootman already have most of the skills needed to competently play Shootman plus alpha. This cuts out the unpleasant part of a game's learning curve where the player does not get to feel competent, however, as a result games become more and more reliant on skipping that part of the learning curve, widening the gap between newbies and experienced players of the genre. This is visible in FPS and Fighting games in electronic gaming, as well as more than a few examples in board gaming...) Thus, games designed "plus alpha" can become needlessly sloppy, with decisions that an experienced player would rarely, if ever make (buying copper, for example) hanging out in future iterations of the design and acting as a familiar competence for experienced players as well as a barrier for newbies. That's probably fine, a game doesn't need to be easy for newbies to be okay.

"Plus Alpha" game design is an easy way to make okay games, and that's what makes it so dangerous.

Thursday, May 23, 2013

Problems with using player data to assess level difficulty

Recently, I've been trying to build a system into my project, BOTS, to help assess the difficulty and "type" of levels submitted by users. The end goal is to be able to integrate high-quality user submissions into the level progression, so the game experience will grow organically and be sufficiently varied to keep users interested long into the game's lifespan. Whenever working with user-generated content there are going to be some problems  my most recent work has dealt with designing mechanisms into the game to discourage trolling or sandboxing behavior in level creators, reducing the number of messy or abusive submissions. While eliminating the worst content and removing it is is quite helpful, what we'd really like to do is be able to identify more user-centric information about content, and use it to essentially sort content.

The technique that I have been exploring in order to do this works in tandem with Knowledge Tracing to attempt to identify which knowledge components a level contains, as well as assess how "difficult" it is within each of those knowledge components. I chose to explore a hill-climbing method using observations from play; when we are presented with a new level, we simply assume it is as hard as the hardest level in the game, and contains each knowledge component. At first, only "expert" users, the ones who are most confident, competent, and challenge-seeking, will be presented with this material, since we have overestimated its difficulty. Based on those users' success or failure, we will then adjust our estimate of the content, making our model conform to the established knowledge of the students' concept states and proficiency.

There is a problem with this approach that became apparent as soon as I began working with it; The very significant trade-off between information gained and user experience.

Let's say that a very good user solved the problem. What have we actually learned, and how can we reasonably adjust the estimate? We could say that, at most, this problem is as difficult as the most difficult problem that player has already solved, but if we're using specifically the best users, this isn't very much information. If the very good user gets the problem wrong, again, we don't know a lot. The problem is, in that case, either spectacularly difficult or the user made a mistake, but neither really helps us estimate the content's values.

Now suppose we give this content to an average user, with knowledge of only some of the core concepts of the game. Based on whether they get the problem right or wrong, we will learn something about which concepts that problem contains; If a user does not understand functions, but solves the problem anyway, the problem probably doesn't contain functions.

However, in contrast to the very good user, there is significant risk to the experience of the average user. In the worst-case scenario for the expert user, they are bored (problem is very easy) but in the worst case for the average user, they problem contains a concept they don't know... this is especially bad because the worst case for the user is the best case for evaluating content because it isolates a specfic unknown concept and shows us that this problem cannot contain that concept!

I'm thinking more about this trade-off and will write more on this topic in the future.

Monday, February 6, 2012

Research week 2/6 - 2/13

Tasks to Complete:
- Veronica informed me of availability of students for testing BOTS... I will complete and submit an IRB immediately (preferably on wednesday).
- Re-write tutorial level dialogue to be more clear.

For solution similarity:
- Get several examples of BLG data / solutions
- Get several examples of BOTS data / solutions

Research Week 1/30-2/5 2012

Tasks completed this week:
-Logging system for BOTS fully implemented. Testing with middle schoolers in SPARKS revealed a couple of errors that needed to be fixed to ensure complete records.
-Tutorial System cleaned up and implemented.
- Began working on an algorithm to determine similarity of solutions where solution elements can have any number of steps between. Looking into using regular expressions, but this will only work for elements we know... looking at ITS literature to find other solutions

Tasks to complete:
- Complete "similarity of solutions" algorithm and test it on both BLG data and BOTS data
- Construct better tutorial levels
- Run several studies on basic game elements