Theory vs Brute Force?

I would not call my approach brute force. What I do is more intuition than analysis. Once I have my base idea I might do a little math just to make sure that there will be enough cards or money to go around for example but not much more than that. I let the testing do the real work for me. I can usually tell from watching a game if someone is enjoying it or not and the goal is to make the game enjoyable. Blind testing is ok however I get so much more data from seeing how people react to the game and asking directed questions. I only do blind testing for games that I feel are nearly completed.

A few weeks back I was speaking to an game editor about “The perfect game” and we came to the agreement that

1. There is no such thing.
2. You can’t tell if a game is any good just from reading the rules.
3. There is no formula for fun.

Regardless of your personal design style in the end you must lean the mantra.

Everybody get in the full lotus position and repeat after me.

Play Test – Play Test – Play Test

Play Test – Play Test – Play Test
Darn! I've been doing everything wrong. Are you sure it's full lotus position? That's why doing proper playtesting is so hard! ;-P

Back to the thread topic, I usually go for a brute force with a pinch of analisys aproach. I mean: first I try to figure how the game should feel when played, then I try to match the theme with that, and as I begin shaping up the game rules I constantly think about lots of what-if's to try to cover the all the big holes. Sometimes this also involves some more detailed analisys, like dice probabilities, or possible moves, etc.

But I think that too much analisys might threaten the creative flow, so it probably is better left for a latter evolutionary stage of the game, toghether with playtesting, or probably just before the real playtesting, after the early playtesting in which you are still changing a lot of detail.

Seo

So far for me, I don't think either term describes my approach at all, though I guess "brute force" is closer. My process looks like this:

1. Inspiration -- I get the idea, both theme and basic mechanics, together at the same time. This can be in a dream, it can be in the shower, it can be standing in line at the bank. Whatever the case, a basic pairing of a theme and one or two mechanics pops into existience. I write this down. I now have the core idea for a game, and we have life!

2. Brainstorming -- The very act of writing down the idea spawns a flurry of additions, subtractions, and changes to the main idea. These occur over a few days, a week at most. At this point I've filled several pages with writing and illustrations. I might even have fooled around in a graphics program to put some shapes together or figure out some visual part. I now have a variety of paths and options for the game, and the majority of the possible combinations of the DNA are laid out!

3. Gestation -- Now the game just has to sit in the back of my brain and gurgles. This could be for a week, it could be for a year. I suspect that subconsciously there's math and game theory and such being applied during this time, but the process is largely unconscious. I may take an ultrasound now and then, but mostly it's on its own. The fetus grows!

4. Birth -- At some point the idea may finally form my new game. I write down the rest of how it all fits together and make a prototype (or, more likely, several). To do so I may well have worked out a variety of math calculations -- a lot of my games have spreadsheets associated with them -- and thought through some game theory and game design principles. A child is born!

5. Development -- I sit in a lotus position and... no, wait, I don't (not limber enough), but I do playtest, playtest, playtest. Things are added and removed. Additional consideration of game design principles and issues -- including things like runaway leaders and kingmaking -- are used here, and there may be more math to do, but there's little in the way of game theory or any other such high-level considerations at this point. My infant creeps, then crawls, and even takes his first steps. If it goes well, he's off to school. This part of the process includes the Terrible Twos, his Getting Picked On grade school years, and his Teenage Rebellion!

6. Submission/Publication -- I have no idea if this ever actually happens, but I'd liken it to my baby's graduation and/or attaining adulthood.

So far all of my games are either gestating or are in development. Here's to changing that in the next couple of months. *clink*

Note that it's not always this linear. A game can vacillate between Brainstorming and Gestation, back and forth, for months (or even years). Sometimes a game in Development is forced to crawl back into my womb (glad I don't have a real-world womb, those are a hassle) and into Gestation again if it fails spectacularly or if there's some problem that seems unsolvable (which means that only unconscious consideration will find the answer and that consciously working through it just gets in the way).

To sum, I don't think either classification fits well for me. Because the game ideas come whole, both theme and base mechanics, I think there's got to be a third classification.

-- Matthew

Ah, gotcha.

Well, I'd argue that I don't beat at it, that I sculpt it. Add some clay here, smooth it out there, with enough planning in advance to it at least resembles the thing to start with. I think that I "beat" and "hacked and slashed" in my first few prototype-level games (Everest, for example), but it feels more surgical every time, so the metaphors are troubling.

I do indeed look for specific problems. I made a little checklist of things to consider right before making the prototype and then to be watching for during playtesting, like kingmaking and turn-order effects, so it's a conscious thing during final initial development and playtesting, but I don't think consciously about them during most of design.

I know of one game that was specifically designed to test out a particular aspect of game theory. However, given that it's a dinky little card game that only explores this particular theory, it's more of an exception that proves the rule! (Fruit Bandits)

Like most people, I probably apply a mix of a and b: testing will make a problem evident, and then I use a whole bunch of techniques to try and address it. I'd agree with Matthew though; there's a lot less slash-and-burn now in my designs than there used to be - that's an obvious consequence of experience

Indeed, I read a similar article a month or so ago, and am a firm believer. Fact is for me -- and it seems most people -- for simple decisions your first instinct is almost always better than giving it thought, and for complex ones you're better off fact-gathering and then letting it simmer without much conscious thought.

I've been using that technique all my life, accidentally. When I ran a good-sized small business (120 employees), when I was presented with a complex problem I'd always say at meetings, "Ok, great, now that we've talked it through, let's move on to something else and table it until X," where X was as long as I felt we could reasonably afford, at least a day if possible. That's how I grew it from one employee to 120, anyway. :)

I very strongly recommend the book Blink by Malcolm Gladwell. It's short and very approachable, and looks a how people make decisions. You'd very likely be surprised, for example, at how strong "first impressions" really are. He also talks about the studies surrounding needing a long bit of background processing for complex tasks. The book's only a year or two old and is incredibly insightful and backed with fact.

-- Matthew