You are here

Design Curriculum: Alpha and Beta

I've shifted our focus more fully into the concrete experience of designing a game. I'm also finding it useful to consider the practitioner's general outlook of "this is how I did it," vs. the observer's or analyst's outlook of "but how does a person do it," without falling into the trap of tossing it back into the observer's lap by saying, "well, you just do it and then you'll see."

It's up to you to judge how well I'm succeeding in avoiding this ... all the while with the stealthy goal of having Justin himself say, soon, "oh look, this is how I'm doing it, so yes, I see." I'm mentioning it only now because I think we just went there.

Part 1 (embedded below): Justin raises the issue of setting as a dynamic component that can be acted upon and altered

Part 2: we arrive at a concrete mechanic for how he wants players to change the thing I call Backdrop, for his project called Origin

Part 3: I discuss (what I at least call) the alpha phase of design, specifically its best practices for playtesting

Part 4: I stress the rough-and-tumble playfulness necessary at this phase

Part 5: I contrast the beta phase and its particular dangers

 

Comments

robowist's picture

As a follow-up to the Design Curriculum session, I’m interested in how you zero in on what aspects of the game are and are not working, and how you get the type of feedback from players which will be most useful to you as a designer. Players are usually not designers, and they can vary in their abilities to self-reflect and to look at a game from the design point of view. Plus it can be hard to find people who will be enthusiastic about your game but who will also give you the hard advice that will propel you forward: I love to hear kind words about a game, but when I’m designing, I’m more interested in what needs fixing or tightening, so a certain level of candidness is crucial.
 
In the early alpha phases, evaluation seems to be easy: You sit down and play with some friends, you can try things out and tinker on the fly, and you can talk at the close of the session about the experience. But as things move along and routines are becoming stabilized (i.e. as you begin moving into the beta phase), you need to get more specific feedback, and it seems like it becomes more challenging to elicit the type of responses you need at this stage. Players, for example, are probably going to be more attuned to the global features of your game and will respond to those, but you might be at a stage where you are wanting more targeted responses to things occurring at the micro level. 
 
Compounding this problem is the fact that I have my own ideas about what I want to get out of a game, and this might blind me to experiences and responses occurring inside others. Of course, this is part of why I am doing playtesting in the first place—to see how different players react to the routines, mechanics, and processes of the game. But I worry about whether a playtester will be sufficiently aware of their responses to be able to articulate what is occurring with them. 
 
Some of these problems canbe addressed at the start of a session: You might tell the players that you are interested in specific issues ahead of time so that they will be sure to attend to key mechanics or responses. The downside of that approach is that you are stacking the deck ahead of time, perhaps encouraging the play down certain tracks in an artificial or forced way. So you also need those sessions where you watch how the play happens organically without prior directives. 
 
To make this more concrete: I might have some specific conflict mechanic that I’m trying to work out, so I tell my players this ahead of time and they play in such a way as to require that combat mechanic. So that will be useful to me. But I also need to know whether, in actual play, these mechanics are ones that players will reach for. There are games where I encounter entire sections of rules for actions which don’t really arise in the course of play. Maybe that’s just a matter of the play groups that I’m with, but sometimes I feel like the game designer didn’t do enough to differentiate what is vital to the game vs. what is unnecessary.
 
Your comment that many games receive limited beta testing before release is apropos. To do beta testing right, it seems like you need to start thinking about a wide array of different types of tests ranging from those where you give the rules to a group and simply see what happens to those where you zero in on specific mechanics and procedures which you need to study under live conditions. 
 
I’m also wondering about other beta tests where you set out to “stress test” parts of the game (or even stress test the game as a whole). An example: my group followed up on your suggestion of looking at Once Upon a Time, and the stress testing was somewhat ugly. I’m intrigued by the idea of that game, but for it to work, it seems like you need to have a group which will play it in a very specific way, and if you have one or more players who decide to play to win, it breaks down. To be fair, the designers of Once Upon a Time are aware of some of those issues that happen when you get “story gamers” together with “gamers who want to win,” but they didn’t seem to have any way out of that problem other than to advise the players to play nice. If you get all the players on board to play nice with Once Upon a Time, then the whole idea of “winning” seems to be a curious appendage with little actual motive to it.
Ron Edwards's picture

Hi Robbie, a lot of this material will do better as dialogue when we meet again, and I definitely know it will work better than a written response for third parties who watch. So I've clipped and saved your text for us to go over in person.

Briefly for here though, I want to distinguish between what people actually do when playing vs. what they want to say about it afterwards. A certain amount of your text shifts into the latter when I don't think it has to.

And one more thing: to get away from the concept of stress testing entirely. It's very tempting to focus on it as if the game were a device, a sausage-grinder which will indeed do X no matter what sort of primate does whatever sort of behavior with it. Think about why stress-testing a musical instrument doesn't make sense, because the point is whether it does do X, when you do X with it. It also doesn't disallow the possibility of someone playing it differently, in some way you never conceived.

Add new comment