Group Critique Session Post-Mortem

Yesterday I participated in a group critique session with several other Chicago-based game designers. It was incredibly helpful and something I haven’t really seen done before (at least not in the same format). Here’s a write-up about the experience.

Inspiration

Several months ago, I read about The Depth Jam, a four-day intensive design retreat organized by Jonathan Blow, Chris Hecker, Marc ten Bosch, and Daniel Benmergui. Reading about that experience made me realize that while there are plenty of game jams to get beginners to make games, there is a lack of events for more experienced game designers.

Around that time, I had also attended PRACTICE, a two-day game design conference organized by NYU. Returning to Chicago afterwards, I wanted to create a format where in-depth discussions about games could happen. Chicago has a fantastic indie game scene, and throughout development, I have organized several one-on-one playtest sessions with other designers, and had been able to have very deep discussions about my game. However, I think there’s a tremendous amount of benefit to participating in a group with a more structured format.

I decided to organize an event that would fit this niche. I was originally calling it a mini-depth jam, but after we did it, we realized it was really more appropriate to call it a group critique session, since we weren’t actually jamming.

Participants / Projects

While I would have liked to open the event the everyone, due to the nature of something like this, it has to be a small group. Originally, we were planning on having 6 teams with 6 games to discuss, but due to timing and other circumstances, only 4 teams participated. In the end, I think this actually turned out well, because a full day of critiques is pretty exhausting (we were there from 10 AM to 4 PM), and 4 games seems to be just the right number.

To respect the other team’s privacy, I will not be talking about their projects or problems in detail, just listing the rough nature of it.

There were the participants:

• Me, with RELATIVITY
• Sean Hogan, who is working on Even the Ocean.
• Benedict Fritz and Greg Wohlwend, with an unannounced prototype.
• John Murphy and Kevin Zuhn of the Young Horses, with 3 unannounced prototypes.

My problems were concerned mostly with the design of ‘World 2’. Here are a few examples of the questions I presented:

1. Players can solve one of the major puzzles without realizing what they’ve done. Should it only be “playable” when players can see it, or can it be affected regardless of player’s location and visibility? What if player is in another world entirely? Should the mechanics still be consistent?

3. How does the world and level pattern compare to that of “world 1”. Does it get repetitive and feel like a checklist? Is this a positive or a negative thing? 

Sean and my projects were probably closest in terms where we are in development. Both of us have been working on our respective games for quite some time, so the issues we were facing were quite deeply embedded within the project.

Benedict and Greg’s, as well as the Young Horses’ projects were both very early prototypes, so the nature of the problem was very different.

Preparation
About a week before, an email reminder was sent out to everyone to get a build of the game ready. Then on Wednesday, 3 days before the critique session, we all sent out builds of our games to one another.

Location

For the critique session, the Young Horses were very kind to allow us to use their office, which was pretty much the perfect setting for this event.  There is an area that has couches and a large screen TV. Whoever was presenting could use the TV to demo the game to show reference materials.

Format

The day started at 10:30 AM, and consisted of four sessions, each between 45 minutes to 1 hour.

Each session focused on one game, and would begin with the designer providing some context for the problem. This would usually consist of the designer playing through the game, and people would talk about the places where they got stuck or had issues.

After that, we would talk about larger design issues and problems, and try to work through them together as a group.

The playthrough at the beginning was in large part because this is the first session, so we all still needed to get familiar with the games and the issues at hand. I imagine for future critique sessions, we could probably jump straight into the problem since we will all have context.

I went first, followed by Benedict and Greg, then Sean.

At 1 PM, we decided to take a break and go to lunch. During lunch, we talked about what were things we liked about the format, what things we could improve, and how this can be expanded to include more people.

After lunch, we returned for the fourth session, with the prototypes from the Young Horses.

We finished around 4 PM.

I think this was pretty much the right amount of people and the right amount of time. By the end of it, we were all pretty exhausted.

Conclusion

We all decided that the group critique session was very helpful and something that we’d like to continue doing on a regular basis.

Here are a few issues and tips to keep in mind:

1. Game Stage – Where a game is at (early prototype vs halfway in development) has a big impact on the nature of the discussion. A bigger game that’s more developed obviously has more to discuss and has deeper problems, but it also takes longer to provide context and explain the problem clearly. On the other hand, for early prototypes, it’s easy to get a sense of the problem and its context, but the discussion tends to be more speculative and more like a brainstorm. Lots of “what if” questions, but maybe not as much concrete solutions. One way to address this is to have different session lengths – not every project needs the same fixed amount of time or attention.

2. Have good debug tools – this is more of a general game development tip, but is incredibly helpful in a group critique session. You want to have debug tools that can allow you to skip sections and make changes very quickly when presenting the game. For example, my game doesn’t have any debug settings (I’m working on it), and during the presentation, there was a bug and the character controller got stuck in an area with no way out. To get to the problem, I would have needed to quit and replay the entire section again. I ended up communicating the problem using pen and paper. Sean, on the hand, had a set of fantastic debug tools for Even the Ocean, and was able to make changes and adjustments on the fly when showing the game, skipping to different sections. This was incredibly helpful, and I’d recommend all games adopt this.

3. When sending out builds beforehand, tell others what feedback you’re looking for, and how long they should spend on the game– work-in-progress games always have bugs and areas that are poorly designed where players can get stuck. Let others know what some of these issues are beforehand, and particular areas they should be paying more attention towards.

Future

We are planning to do this again on a regular basis, meeting once every two to three months.

For something like this to work well, the group has to be quite small. For the next meeting, we wouldn’t need to provide context for our problems, and can dive straight into the issues. If someone new is introduced, then we would have to catch them up on the issues we’re facing.

I’d love to get more people involved in critique groups like this, but I’m not sure how to address that. We were thinking what would be great is to have multiple critique groups in the city, and hopefully the information here can help people start their own.

If you’ve done something like this before, or have any suggestions and questions, let me know!