Community Building Round Up

I asked this question earlier on twitter yesterday:

twitter question

I got some really great responses.

twitter response 01 twitter response 02

It’s been known for a while now that with how saturated the game market currently is, you can’t just put your game on Steam and expect an audience to find it.

You also can’t really rely on press to discover your game. They’re bombarded constantly all the time by so many new indie games now.

I decided to take a look at the different platforms,  how I’m currently using them, and what I can do to better my efforts.

Twitter - This is the platform I’m probably the most active on. I post a lot of development updates here (along with a few dumb jokes). More recently I haven’t posted as much visual stuff as I’ve been dealing with saving and loading system, instead of level designing. However, that should change pretty soon.

Twitch - I’m also really active here. I’ve been streaming on average 4 – 5 hours a day, every day of the week. Sometimes even more than that. It’s been a fantastic experience, and the community there has been awesome. I’ve improved so much as a programmer since sharing my process up through streaming. You’re able to have instant discussions about the specific problem you’re facing, which is the best way to learn, as opposed to some abstract example in a textbook.

I’ve also gotten a few tips on how to improve my work pipeline in Unity through this. For example, I learned about vertex snapping on stream because one of the viewers asked me why I wasn’t using it. I just hadn’t known about it then. Since learning it, I’ve been using it all the time.

Streaming also has the added benefit that it helps me keep schedule and maintain focus. I’m in the last stage of the project, and it really feels like a drag a lot of the times. It’s all the boring and tedious details that were avoided early on in development, now coming back to haunt you. Streaming has been really helpful in getting through these rough spots.

Discord - This is really just an extension of the twitch chat. I hadn’t been super active there for a while as I was knee-deep in code, but getting back into it.

Mailing List - I set up a mailing list years ago for Manifold Garden announcements and put up a link to it on the Manifold Garden website. It now has over 3500 subscribers, and I’ve still yet to send a single email there. From William Pugh’s response above, emails seems like a really great way to reach people, so I think I’m going to start sending biweekly updates through the mailing list.

Facebook - I don’t really use facebook in my personal life so I keep forgetting to log in and check the Manifold Garden page. I should post weekly updates here.

Steam Forum - There seems to be a small but fairly active group of people posting on the Manifold Garden steam forum. Considering the game isn’t even out yet, this seems normal. I’m going to start posting weekly development updates there.

Group Critique Session Post-Mortem

group critique session 001

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.


Several months ago, I read about The Depth Jam, a four-day intensive design retreat organized by Jonathan BlowChris HeckerMarc 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:

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?

2. What are the “concepts” that you feel are being taught in the puzzles. Are the puzzles “clean” or do they feel muddled? By clean I mean that the idea that the puzzle is communicating is very clear and simple.

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.

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.


group critique session 003

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.


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.

group critique session 004

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.


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.


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!

Dev Feedback Loop

dev feedback loop

I announced something earlier today called “Dev Feedback Loop“.

It’s basically an initiative to get Chicago-area game developers to meet up and give each other feedback on games-in-progress.

It’s based on an earlier similar event took place here in Chicago back in 2012, which I participated in, where I showed the very first prototype of Relativity.

Anyway, if you’re a Chicago game developer and you’re reading this, I highly encourage you to sign up!

Other than that, I finished the first draft of my video for my Experimental Gameplay Workshop submission.

And here’s today’s perfect loop: