6 Games in 6 Weeks: A Look Back

A retrospective on rapid game creation

Confused? Start here.

6 Games in 6 Weeks was an interesting experiment. When we started it last year, we were all very pumped about it, and that energy definitely carried us through. At the end of last year, we had wrapped our 8th game over the 6 weeks, and we were all pretty tired. So, we took a few months off. We’ve been back at work creating things for about a month now, and it’s time that we look back at 6G6W and discuss what worked, and what didn’t. We’ll do that by looking at some of the games we made, and what we learned from them.

I Am Bomb — one of our first creations

I Am Bomb

I am Bomb was one of the first games we made for 6G6W. It was one that was very special to me, and when I reflect back on the entire process, I still feel like it was one of the strongest games we made.

If you aren’t aware, I Am Bomb is a game where you play as a bomb defusal expert, defusing a bomb which starts to gain sentience. It was intended to be a story about consciousness and the morality of war, framed through a puzzle game mechanic.

I Am Bomb definitely has problems. The story doesn’t come across as well as we intended it to, and the difficulty curve of the puzzles can be pretty unforgiving. Despite that, I still look back on it quite fondly, and I hold it up as the pinnacle of what can be achieved within only a week long development cycle.

The most important thing that we learned from making this game was that the process can work. It was very daunting creating games in only a week, and to have such a strong success right out of the gate was affirming. I Am Bomb cemented the idea that this process could have interesting, fun and artistic successes, and that such a short development cycle wasn’t something to fear.

Groupwork — A second in space

Cosmos

Cosmos was a project from week two of 6G6W. Coming off of the success of our first week, there was a definite drive to recapture some of the emotional storytelling magic. Cosmos was an attempt to do this, with mixed success.

Cosmos revolves around a long distance relationship, set against a space backdrop. The couple communicates by sending letters to each other, and the main gameplay mechanic in the game is firing these letters off on their way, using physics to bend them around planets and asteroids, trying to help them reach your partner.

As you send letters, you and your partner are communicating, unravelling the story of how your relationship unfolds. During the ideation process on Monday, we planned to have the story of this relationship be the emotional core of the game, and I think we succeeded at that. Where Cosmos didn’t succeed was the game surrounding its narrative.

While we focused on the narrative for Cosmos, we neglected the mechanics and art direction surrounding it. After we had poured a week of our soul into Cosmos, we felt that the final product failed our initial vision. For this reason, we decided during the third week to revisit Cosmos and enhance it. While this was something we agreed that we weren’t going to do at the start, we made the decision to change the process a bit, and we think it worked out.

Cosmos transformed from a solid game with a strong emotional core to a strong, beautiful game with a strong narrative. The lesson that we learned from Cosmos was that the rapid feedback we were able to get enabled us to easily decide what to do with the project next. We decided to put another week into it, and the project became quite clear in that time, as opposed to blindly moving along the early stages of the project until we narrowed down where to take it.

Groupwork

Groupwork was the other project we worked on during the second week of 6G6W. Unlike Cosmos, the design for Groupwork went in the complete opposite direction from the first week.

We wanted to create a less story-driven game with a light-hearted tone. The central conceit of Groupwork participating in a university assignment group, and manipulating your groupmates’ emotional states to keep them productive.

It’s a weird conceit, and it’s one that didn’t really immediately connect with players. Partially as a failure of the design of the game, and partially as a failure of the implementation. The game is lacking in visual feedback and ‘juice’ which would help convey this notion. But, at its core, the game is one that just doesn’t really mechanically work.

How nice it was, to realise this after only pouring 5 days of energy into it, as opposed to a few weeks or months. Previous games that we had developed, that didn’t work, we had worked on for months at a time before they flopped on a larger stage. While Groupwork was a failure in many ways, it really helped to highlight the strength of this process. We could build a game, test it and get feedback on it immediately. This meant that we could decide to invest further in projects, but more vitally, to kill projects that we realised weren’t working with a minimal investment. Groupwork failed, but it failed fast.

Funky Paint the Wall

Funky Paint the Wall

Funky Paint The Wall was a game designed to imitate a bop-it. I’m not sure if that’s a thing that exists outside of Australia, but if you aren’t familiar, it looks like this. The goal with Funky Paint the Wall was to capture a feeling of a group of people gathered around a phone, passing it around, laughing and playing together, against each other.

Funky Paint the Wall definitely had aspects that would make me consider it a failure. While the game achieved the emotional feeling we set out for it in playtesting, it was definitely incomplete. The rhythm mechanic of the game could become desynced, which for a rhythm game was a death knell.

Why did that happen? The answer is that we didn’t build Funky Paint the Wall sustainably. When I was working on Funky Paint the Wall, it was a lot of late nights hammering away at things to get them to work. That wasn’t a good working condition, and I think that was reflected in the way that the game ended up. While that probably means that there was a failure of scope, rather than of working conditions, they go hand in hand. The 6G6W process (as well as our own excitement) pushed us to work harder and harder on these games. This is something I think we got better at over the course of the 6 weeks, but still wasn’t great.

Would we do it again?

The honest answer to this question is — sort of yes, sort of no, sort of always. There was a lot we liked about the 6G6W process, and because of that, parts of it have been implemented into our regular work cycle. We still begin each week with an ideation, although we have the option there to work on old projects. We still stick to our weekly cycle of inspecting what we made that week, and rapidly prototyping. We still decide each week what we want to work on, and how much value that project has to the company as a whole.

Incorporating elements of the 6G6W process into our regular cycle helps us keep the good parts of this experiment — the rapid iteration, the quick decision times for projects and the constant inspection, while avoiding the bad. On the whole, we’re not sure if it’s a process that we would recommend for everybody (as it was very tailored to solving our goals at the time), but it’s something we really enjoyed, and really valued, doing.

Reuben is a co-founder of No Moss Studios. Follow him on Twitter here, or follow No Moss Studios here.