Codecrunch: An Indie Flash Post-Mortem

Cross-posted from Sulli.ca

Codecrunch is a Flash-based puzzle game based of the classic code-cracking puzzle game Mastermind. Over the course of many months our small team of 6 worked to complete our first real game under the banner of Thermite Games. Being our first independent project together (and in some cases first game project at all) we had a lot to learn about working as a team, handling scope, coping with real-life priorities and ultimately delivering a title worth playing.

Codecrunch Mascot

You can play Codecrunch now!

The Setup
For the duration of the project we had a team that included two programmers, one artist, one designer, one web programmer/designer and myself as the producer. Most of us didn’t have work experience in the role we were performing for this project so we did our best to manage scope appropriately, taking into consideration that learning would be an important part of seeing this title to completion. It’s worth noting that those of us working in the industry spent some time researching our non-compete agreements and anyone following in our footsteps would be wise to do the same before starting their own projects, especially as a group.

Codecrunch Title Screen

At the start we only knew that we wanted to make a game – something that we can look at and say “yup, it’s done, and it’s a game!” and something we could gain appreciable knowledge from creating. In both cases I believe we were successful even though to this day Codecrunch hasn’t been seen outside of the developers that created it – though that may change now that we’ve taken the time to properly deconstruct the best and worst parts of the development life of Codecrunch.

Despite the initial ambiguity of the project we eventually settled on a Flash game that would be released under the Thermite Games banner as a Facebook game. At the time Facebook games still hadn’t reached their peak – big names like Zynga hadn’t yet begun to dominate the market and there was a lot of room for independent developers to become known. We were naturally attracted to the inherent “shareability” of Facebook games as well – a game standing on its own isn’t nearly so successful as a game that enables and encourages its own redistribution. Flash was chosen as our platform after much discussion primarily for its low barrier to entry for developers and ease of web distribution.

What Worked

Crunch

We finished the game! Far and away this is the biggest success for the project. The vast majority of indie/hobby games that are begun never see the light of day (some for good reason, some not) and while everything we learned during the project was invaluable, actually reaching completion was undeniably satisfying.

We learned a lot! As will be detailed here everyone on the project learned a great deal from our successes and failures. Everyone also gained experience in the component of game design that they are most interested.

We met regularly! Despite being in different parts of the province the team met almost every week via Skype to discuss the status of the project. These meetings were both functional and fun which was critical in tracking progress but setting a friendly tone so no one was afraid to speak their mind or admit to having made no progress that week. Google Wave was instrumental in creating collaborative documents that could be modified and commented on in real-time over the course of the week.

Google Wave

We planned and documented before working! As much fun as it is to jump headfirst into Flash or Unity and start building we knew it was critically important to design first and build later. Using Google Wave designers could document how the game should play and their progress with various features. Towards the end of the project Google Wave (now “Apache Wave”) was invaluable for tracking bug fixes (see image). Google Docs was also used to track and update design documents as they became finalized.

We kept our scope in check! One of the biggest game-killers in the indie scene is lack of scope management. Game designers love to add features and make their game as incredible as possible, but the inability to prioritize those features and keep the game at an appropriate complexity is something that many developers (both big and small) fail to do. Codecrunch benefited from a clear vision and a simple design that helped keep the team focused on the core elements that mattered before expanding the feature set.

What Didn’t Work

Crunch Failed

Unrealistic work distribution! The biggest thing we took away from Codecrunch is that platform and design choices have to be made in the context of the team building it. While Flash is a great platform and met our needs only one of our developers was fluent in actionscript forcing a large majority of the development work on his shoulders. This had the effect of bottlenecking the project with one developer while simultaneously leaving other developers with nothing to do. If we were to make Codecrunch again we would make efforts to organize the workload better. It’s critical that everyone on the project is able to materially contribute to make them feel valued and to engender a sense of ownership in the product.

It’s okay to not work! As mentioned above there were times where it was unrealistic to expect everyone to contribute to the project when their skills didn’t match the majority of the work necessary (art and actionscript). We handled this the wrong way by finding work for these individuals, most of which was ultimately unused and wasted. It would have been better to suggest these individuals work on their own projects until their skills were needed instead of creating work for them.

It’s not enough to finish the game! Despite our success in actually finishing Codecrunch we failed to deliver it in a meaningful way to an audience. Though we had plans to build in Facebook’s sharing features we didn’t execute on them and Codecrunch was never truly released to the public. The lesson here is to think beyond the final line of code – you’ve created a product and you need to know how to deliver it to as many people as you can.

Real life is hard! We tried hard to be realistic from the outset as far as time expectations from the team and while asking members how much time they expected to contribute to the project each week was the right thing to do (and necessary for basic scheduling) the actual time worked each week was erratic at best even when we did have specific tasks assigned. This is normal and you’d be mistaken to expect otherwise when dealing with real people who have real lives and real jobs. Life and relationships will always come before hobbies and side-projects and members should never be criticized for this.

Conclusion
While Thermite Games never went on to complete another project (though we had and continue to have many great ideas) we all learned a great deal and took those lessons to our respective careers and lives. If you’re interested in game development I would highly recommend getting some friends together and create something fun – whether that be a game mod, board game, short film or anything else that forces you to put your ideas into action!

Play Codecrunch now!