The Kansas City Game Designers

Last year, I moved my family to Kansas. After doing so, I founded a game design group called the Kansas City Game Designers. Please feel free to visit our website at www.kcgamedesigners.com.

Business Analysis and Game Design

One thing that's changed a lot in the past few years is my career direction. About a month before I finished my MBA, I got the position for which I had been aiming for quite some time and that's as a Business Systems Analyst. What that means is that I essentially try to be the detective around a project, interview subject matter experts (SME's) within the company on the different areas that relate to a particular software project, document the requirements from the business's perspective of what the software needs to do, and then I follow up by testing the software when it's all done to make sure the business got what it asked for from the developers.

It's a very fun job and I'm struck over and over again by how my background in game design has helped me acclimate to the position. Here are some reasons why.

Playtesting and feedback help a person let go of the prideful notion that they are going to get things 100% right without having to go through iterations.

Business Analysis is a very iterative activity wherein something that seems to make sense after a meeting with one set of SME's doesn't actually hold muster when looked at by a different set of SME's who find holes that the first set didn't know about or consider. This can be a very difficult prospect for someone who takes a lot of pride in their writing (such as myself) wherein one works really hard on a document only to find out in short order that most of what was written needs to be changed. This requires a certain amount of patience that I've had to learn via putting prototypes out for playtesters to critique. This leads right into my next point.

Accepting that prototypes are essential in getting proper feedback helps one realize the importance of creating documentation that people can react to.

This is an interesting lesson as I've learned how important it is to actually write up drafts to get the feedback I need. It's not enough to just explain something to someone. Once an idea is in the form of a document, people can react to it much better and see things about it much more clearly - not only what's right, but also what's wrong. This hearkens back to the notion in game design of how some designers are reluctant to build a prototype. They are content instead to hang on to their idea, just tell people about it, and then believe that the feedback they are given off of their idea description is worth much more than it actually is. Don't get me wrong. It's not worthless, but it's so many levels removed from the truly effective feedback that comes from people who are actually trying to experience a game rather than just listen to a description of such.

In many ways, it's the same thing with Business Analysis. One has to go in and create the process flows, write the user stories, create the context diagrams, and do many of the other things required to document the intent, vision and specific requirements for a software project before one can truly get feedback from others about what's right and what needs to change. Accepting early on that one is writing a particular draft of a document as a means of getting additional feedback is so much more effective than approaching each draft like it's going to be the last one. One attitude is very receptive and welcoming of feedback while the other sees feedback as a threat to one's ego.

Explain things clearly - but succinctly.

In documenting software requirements, one has to explain things clearly to an audience who has not done all of the research and gotten into the guts of the project like a business analyst might. In the same way, a game designer has to write a rule book explaining his game to someone who hasn't been involved in the many iterations of the game's creation. The person reading the rule book only knows about the game what the rule book explicitly lays out.

In writing requirements, it's funny how many times I'm reminded that I need to spell something out. I'm also reminded of how much one has to leave fluff out of it so the reader's patience isn't exhausted.

This is one area where I made a mistake in writing the rule book for Heavens of Olympus. I approached the rule book like I approach teaching a group of people how to play a game. In explaining a rule to a table of gamers, often a brief thematic explanation of what the rule is trying to represent goes a long way in helping the group remember certain specifics. However, in writing a rule book, taking that same approach actually hinders the reader's ability to get to the essence of the game. It comes off as fluff, tries one's patience, and the comments on BoardGameGeek tend to bare this out about how I made this mistake.

Test boundaries and think about extreme scenarios.

Game design forces one to think about all the wonky ways a player might try to approach a game. In so doing, it forces one to consider extreme scenarios that might actually break a game. Software development and requirements gathering can be very similar. Thinking about all of the possible ways a particular software solution can play out helps one see much more quickly where certain danger paths might be.

Conclusion

I feel like there are many corollaries with my new career and what I've learned from my game design and playtesting experiences. I also had a job for a time of being a software usability researcher and I found that tied in very neatly with certain principles of how to make a game more accessible to a player in terms of layout and presentation. When I have more time, perhaps I'll come back and revisit that connection in a future post.

What I've learned about myself in the past two years.

I haven't posted an entry here for quite some time. So, I've decided to post about why I haven't posted, how it relates to gaming, and what I've learned about myself in the process. I hope what I have to share might be of interest.

In early 2011, around the time my board game was published and around the last time I posted here, I went back to school to pursue an MBA. I've been working on it ever since and I should be graduating early next year.

During this time of going to school, homework has dominated my free time. Because I'm married and have a couple of kids, this means that the natural give and take between husband and wife with respect to "I'll watch the kids while you go do x and then you watch the kids while I go do y" has very much been a matter of my wife watching the kids a lot while I'm putting in time with the books.

As such, my opportunities to game have been very, very limited. Further, because of when my classes have been happening, I haven't been able to attend the board game designers guild meetings for some time (I believe it's been at least 6 months).

The reason why I'm sharing all of this is because my gaming tastes have changed dramatically during this time. I used to be a typical Eurogamer with strong interest in balanced mechanics and only minimal interest in theme heavy games if they veer away from balance to much. However, with only limited amounts of time to game, I found that playing euro games was fine but I needed more. I found myself needing story. I found myself needing theme.

So, I've been putting in time running an RPG campaign. The irony is that running a campaign is usually a very time consuming bit. But, I have a group that is willing to meet once a month (or once every two months if need be) to accommodate my schedule. Further, when we meet is at an odd time (we usually have to start at about 9pm and game until midnight) primarily due to the fact that we have to game after my kids are in bed.

In running these RPG sessions, I've found a true love for the story-telling nature of games and I really appreciate the lasting impact of a gaming session (reminiscing with someone about some crazy turn of events that almost killed one of the characters, etc.). If having vivid story-driven experience comes at the expense of some balance or elegance, so be it. If rules start to become a bit crunchy so the elements involved in the story telling can come through, then that's fine with me.

In short, I've changed in terms of my gaming tastes. When I look at a new game now, I find myself looking for what kind of stories the game is capable of telling. This shouldn't be taken as some sort of rejection of past preference. I still love Puerto Rico, Princes of Florence, Caylus, etc.. I just find myself looking at different things now that previously weren't as important.

Heavens of Olympus featured in the Deseret News

I was recently interviewed by Carma at the Deseret News about Heavens of Olympus. Here's the link:

http://www.deseretnews.com/article/700123283/Good-heavens-Gamers-dream-comes-true.html

Heavens of Olympus Images

I offered a demo of Heavens of Olympus tonight at Game Night Games where I work. Here are a few images that I uploaded to Board Game Geek:

Design History of The Heavens of Olympus

I wrote an article over the weekend detailing the design history of Heavens of Olympus. The article was posted yesterday on BGG's News section. Here's the link:

http://www.boardgamegeek.com/blogpost/790/figuring-it-out-designing-the-heavens-of-olympus

Official Video Tutorial for "Trollhalla"

This is an official video tutorial for the game "Trollhalla" - published by Z-Man Games (www.zmangames.com).

I was asked by the designer - Alf Seegert - to do this video and it has been approved by both him and the publisher. Alf, the artist - Ryan Laukat, and I are all members of the "Board Game Designers Guild of Utah". You can find us at www.bgdg.info. Here is the video:



Due to Youtube's 15 minute cap on video time and because of my desire to keep this tutorial as all one video instead of a several part series, I had to keep the pace of the video high. I hope you enjoy it.