Archive for July, 2015
I previously mentioned that I had originally created some promo buildings for New Bedford, based on games I enjoyed and was inspired by. One of them was the Coffee Roaster inspired by VivaJava: The Coffee Game. Then, once I played Brew Crafters, I decided I needed a Brewery, too. So when I signed with DHMG, I knew I had to make some promo buildings based on previous DHMG games. Plus, that’s something of a tradition, as you can see a lot of self-referential callbacks in the other games if you know where to look.
The original game of New Bedford was designed around 20 buildings. There were two reasons for this. First, 20 allows for a wide variety of plays and strategies without requiring the players to track huge number of new buildings in each game. Second, I could fit 20 building tiles onto a sheet of 8½” x 11” paper.
But I had more ideas. A lot. Read the rest of this entry »
Previously, I wrote about what feedback to listen to, and what feedback actually tells you. But the issue I left for last is how to ask for feedback. While this might seem out of order, it is important to cover the other two topics first because they inform what we look for and ask of our players. When you try to listen to all feedback, you need to know how to get as much of it as possible. And you need to make sure you get the right kind of information out of your players so you can separate the good design advice from the opinions. Trying to accomplish both of these things is not a simple matter. Read the rest of this entry »
After spending some time in Dry Dock, undergoing upgrades and repairs, New Bedford is headed out to sea again!
The Kickstarter campaign is live, so please consider joining us on this voyage. Thank you for your support.
The previous post in this series looked at why you should listen to everybody. But at the same time, you definitely shouldn’t do everything people tell you to. The problem is that everybody wants something a little different. When you listen to all the feedback, as I recommend in the first part, you need to be able to recognize whether the feedback is telling you something about the game, or the player. Making that distinction is one of the biggest skills a designer can learn for dealing with feedback Read the rest of this entry »
In a previous post, I introduced a series of articles about how to use playtesting feedback from players. This article takes a look at the first important point, what feedback you can use. I’ll save you time by giving the answer now: all of it.
Read the rest of this entry »
Summer is convention season, and that means lots of opportunities to play games, and for a designer that means playtesting. In the past two weeks [at the time of writing] I played a lot of games of New Bedford, as well as some other games, at Origins and a local Unpub Mini. As I prepare for the relaunch of New Bedford in a few weeks, it’s very important to get everything I can out of these last-minute tests.
You can get a lot of information from a playtest. A lot of it is watching how the players interact with the game. When players are engaged in the game, that’s a good sign. If players are distracted, you know that there is some part of the game that they aren’t connecting to. A lot of information comes from simply seeing what players accomplish in the game. Wins, losses, and scores can reveal new strategies or new problems, or confirm old ones.
Since I was teaching a lot of games, I participated in most of them. That gave me the opportunity to try things that new players wouldn’t think of right away. But when you’re playing the game, you only get to see events as they happen. You can get a different perspective by sitting out and watching, sometimes by seeing how different people deal with varying information.
But one of the most important ways you can get feedback on your game is simply by asking for it. And that’s the real focus of the next few articles I have planned. How I use feedback from players. First I need to make a distinction, playtest feedback as opposed to feedback as a mechanism.
In this context, I’m talking about feedback as everything a player tells you about the game. Now, a little motivation for why feedback is important. All of the successful designers I know say that playtesting is a huge part of making a game good. And most, if not all of them will also tell you that feedback is an absolutely vital part of that process. The reason for this is that feedback gives you direct insight into how players react to the game. That is why it is such a big part of the Unpub program. If you are only getting one perspective on the game (your own) you’re missing a lot of understanding about your game. Feedback is how you get that outside perspective.
One of the challenges with dealing with feedback is knowing what to use and what to ignore. A great post by Doug Levandowski over on the League of Gamemakers gives a great overview of different stages of feedback. It’s my intent with these articles to be a little more in-depth with how to get and use feedback. The first article will discuss what feedback you should use, the second one will discuss what feedback you shouldn’t use, and the third one will discuss specific ideas for getting more out of the feedback you ask for. And of course, this isn’t just for designers, it’s also useful information for playtesters to understand where their feedback fits into the game, and how to improve the feedback they give.
[Note: These links won’t be active until the articles are posted]