Updated Introduction

The following is a postmortem series for Terrachanics, a puzzle game developed for the U.S. Department of Energy. It is told from the perspective of its lead designer, chronicling both the challenges encountered during the project, as well as personal challenges and revelations he made during the course of development.

Part I sets the stage by describing the circumstances that brought him onto the project, and the organizing principles that guided the development process.

Part II deals with specific lessons learned during the production cycle, relating to both leadership and indie team organization.

Part III talks about our design process, namely around teaching players through intelligent theming and audio-visual feedback design.

Part IV concludes the series with a step into the psychological and philosophical underpinnings that tie the psychology of leadership and depression together, supplemented by research into the power of mindfulness, emotional intelligence, and resonant leadership.

Trials and Tribulations

In Part 1, I talked about my motivations working on Terrachanics, and the history that led up to getting on board with it. In Part 2 here I will be getting into the meat of the production cycle, the challenges we encountered, and the lessons learned from those experiences.
 

As before, this will be focusing on my point of view of the events, as I believe it gives the best context to how things played out. All names and mentions of team members are done with permission from those team members. Personal and professional overlaps heavily here, but I will do my best to remain objective.
 

I will be highlighting the lessons I have learned as a result of my experiences, and subsequent reading I did in reflecting on the project. In Part 3 I will be diving deeper into some of these concepts to explore their ramifications.

UPDATE (3/6/15): I have revised this to be a four-part series. Part 1 describes the circumstances of the project. Part 2 talks about the challenges we encountered during our production cycle. Part 3 discusses our design process and the choices made along the way. Part 4 discusses the life lessons and big picture takeaways from my experience with the project.

The Timeline

Our initial team was made up of around 16 people, more or less evenly split into Art, Design, and Programming subteams. As Lead Designer and Producer, I was most heavily involved in the design process, though I worked with the leads of the other teams to help craft our overall goals and milestones.

Conceptualization
 

In the beginning, we had a wide variety of ideas. Most hovered around the strategy and puzzle genres. After voting on the most promising ideas we narrowed it down to two main influences - The Incredible Machine and the Deus Ex: Human Revolution hacking minigame. The former was appealing as physics puzzle games have been wildly popular lately, and the idea of emergent gameplay was appealing. The second was interesting in that it tied-in well to the idea of interdependence across resource systems, and was a novel minigame that had the potential to hold its own as its own game if fleshed out further. After some debate, we ended up settling on the DX:HR influenced concept, as it had the most reasonable scope.

When fleshing out the concept early on, I tried to keep the concept open-ended on a number of fronts to allow us to feel them out later. We knew we wanted to have buildings that would connect via shared resources, but we weren’t sure how many we would ultimately have. The idea was to keep the concept flexible so we could try multiple approaches when the prototype became available.

Lesson 1: Commit to a “first draft” for your initial concept. It is better to pick arbitrary values and change them later than to keep many different parts of the game up in the air. The bottom-up approach just isn’t practical or effective for some concepts. A first draft gives you a starting point and “levers” for you to pull to feel out what works best more effectively.

Preproduction

While developing the concept, we had our team of 6 programmers work on putting a prototype together in Unity. Not only did I think a team of 6 programmers would be able to get it done faster and better than I could, but I also wanted to them to maintain a sense of ownership over our code. Since several of the team members have not used Unity before, the design team and I continued fleshing out the concept through discussion and paper prototypes.
 

Unfortunately, progress from the Programming team was much slower than expected. Six months into the project, we had no playable prototype of the game. Further, discovering flaws in our original design, we ended up shifting gears quite dramatically, resulting in a sizable chunk of the existing code to be rewritten. All the while the Art team was creating concept art and initial assets for the game, but had no frame of reference for how it would actually look in-game.

Lesson 2: Being forgiving toward team member mistakes can be a good policy, but only if properly executed.  Be sure not to just “let things go,” and instead focus on a specific action plan to fix the mistake or prevent it in the future. Assuming that someone will fix the problem, or is able to fix a problem, after it is brought to their attention is not always a reliable strategy.

Over time, having an overly permissive policy can lead to a general team culture of frequent excuses and compromises, where no one feels strong or confident that the project is being handled properly.

I recommend reading up on situational leadership, a technique for identifying the correct degree of autonomy and direction each team member needs and adjusting how you manage them accordingly.

Lesson 3: Scope is a multidimensional concept. You may have an idea that is technically simple to create, but difficult to design and balance based on its many possible permutations and interactions.

Additionally, I believe in “organizational” scope, or the scope that pertains to improving team culture, trying out a new project management technique, expanding the skillset of existing team members. It applies to anything that involves improving your team member’s ability to work or gain value from your project, beyond just money or technical skills.

Our project was fine in terms of technical and creative scope, but out of scope organizationally. I will revisit this again in Part 3.

As months went by, interest on the side of the Art team began to wane, as the stream of new assets and critiques began to slow down. By this time, most of the team had gone back to school. They weren’t just college students - these were students in demanding, technical majors, and as such it diverted a lot of their attention. Afterall, at school their grade and career was on the line. On the project it was just the promise of fame and national recognition - a promise that felt more distant as time went on.

Lesson 4: Having a large, virtual team of people with only part-time commitment to a game project is a bad combination. Having too many team members, especially early on, dilutes the contribution of any single team member. It further means more schedule conflicts and unexpected developments to account for. With a small team you really want everyone to be motivated and excited about the game, with a desire and ability to make a mark that the world will see. Being a virtual team exacerbates this, as you don’t get the benefit of “the energy of the room” effect. (more on this later)

Lesson 5: Part-time commitment also makes it difficult to plan and schedule milestones.  To combat this, it is best to set up designated days of the week to have all-team work sessions. This ensures people can be contacted easily and that you have a guaranteed minimum amount of time where you have the undivided attention of all team members. We attempted to implement this a couple times, but our team size and varying school and work obligations made this unfeasible.

Team members began leaving the project. Some officially resigned, but others simply stopped responding to emails and disappeared. Despite my repeated speeches about the amazing opportunity we had in front of us, people started losing faith and stopped listening. Things were just going too slow and the promise of a payoff for our work was looking increasingly remote. By the start of 2013, all but two of the original team members remained (Katharine Uvick and myself), and a new crew of people had taken their place.

Lesson 6: It is important to regularly discuss your expectations of team members, and ensure that they understand their tasks and the purpose behind those tasks. Having an “open door” policy toward sharing questions or concerns isn’t always the best solution, as sometimes misunderstandings are not apparent until too late, or team members may be reluctant to ask for help or clarification. It is better to take a proactive approach than to assume it will happen on its own.

More importantly, empower team members to declare their own expectations for themselves and the project. This helps to cultivate autonomy and self-motivation.

Lesson 7: Don’t be afraid to let underperforming team members go, especially on a virtual team. It helps whittle down the team to only your most dedicated people, and came help motivate the people you dismissed to attempt to come back with a greater desire to excel.

On a virtual team, you also have the option of a “soft dismissal” by simply leaving them out of the loop. This is less harsh for both parties involved, and accomplishes the same objective. It encourages people to remain proactive in checking in as well.

By the same token, do not be afraid to have a hierarchy of engagement levels if you are working on a part-time project, knowing that some team members will devote more time and energy than others. (ie regard some as your “core” team members, and others as “freelancers”)

Escalation

Since I was working full time at a grocery store, I had little time for a life outside of the project or my day job. The team’s energy and ambition was fading, and I was worried that the project would go off the rails. I tried to understand what was going on, to figure out what to do. Between the promise of the project slipping away, and the chaos of my life at home, and my own guilt in failing to keep my team motivated, it became too much for me. I took a week off from the project to cool my head and refresh my thoughts.

Lesson 8: Factor in regular breaks into your project plan, especially if you are working on a virtual team. Working virtually blurs the line between work and non-work time, especially if you are a designer. Scheduling it ahead of time, rather than waiting for burnout to happen, allows you to clear your head without any of the guilt of thinking you are holding things up.

You may be tempted to skip this if you think it is a short project, but 9 times out of 10 it will take longer than you think.

While my break did allow me to refresh my mind, it exposed a bigger problem that I had suspected was growing. As the project went on, and people became more distracted by things outside of the project, more and more I felt I had to pick up the slack on the creative  front. People provided less and less feedback, ideas, critique - it felt increasingly like I was calling all the shots and people were just going along with whatever I decided upon.

This came to a head during one of our rare all-team meetings, where one team member remarked that “This is [Glen’s] baby.” Now, there was a time as a Freshman when I wanted nothing more than to be the Creative Director of a game project, coming up with the ideas and having a team of underlings bring my creation to life. Now I was living it, and it was terrible. Be careful what you wish for.

Lesson 9: Getting something playable and concrete as soon as possible is critical to keeping your team engaged and to give everyone a frame of reference. Designers tend to be more comfortable thinking about abstract concepts and theories behind games, but for others they need more of a focal point before ideas start to emerge. “Theorycrafting” too much before having a tangible, playable game in front of you is a bad habit that all designers ought to avoid.

At a time when I felt stressed out and tense, the last thing I wanted was a team of novice game developers dependant on me to give them direction. I was not getting input or pushback from either my team or the DOE, so I felt like I was completely on my own. The pressure to perform was intense - I felt no one was looking over my shoulder, no one was there to tell me if I was going in the right direction. If I failed or made a mistake, it had ripple effects on the entire team, exacerbating our already dwindling morale issues. Living in Vermont, with a full time job and under a lot of stress, I was very limited in being able to engage with the greater game dev community to regain a healthier perspective.

Lesson 10: Do not develop in a vacuum. Always stay connected with a developer community, in person or online. Do not be afraid to share your game with the public either, even at early stages, as it can help build a fanbase and a support network as a bulwark against any doubts or insecurities you might have. It also allows you to hear the stories of other developers, to know you are not alone in your struggle. You gain a sense of duty, as you see fans and peers applaud your efforts. Above all, you are reminded that the main goal of a game developer is to bring joy and entertainment to other people.

A Turning Point

To combat this, I brought on a friend from Champlain whose insight I trusted, Craig Ellsworth. Coming on as the Senior Designer, he helped me in tackling some of the design conundrums I had been encountering, while injecting some well-needed levity into our meetings. It went a long way toward helping us refine the design.

While Craig’s input was valuable, it did not make up for the lack of input from the rest of the team, and the slow pace of development. To help us have something playable, and to supplement my design documentation on the mechanics, I took it upon myself to create a prototype of our game in Flash.

Lesson 11: Have a code-savvy designer make the first prototype, before programmers are even involved. The most important thing is getting a prototype quickly and to be able to iterate on it fast. Do not try to make it the “right” way - hack it any way you have to until it works. After it has been tested and your team is comfortable with the initial framework of the game, then hand this off to the programmers to have them recreate it the proper way.

This gets the prototype into the hands of the design team (and even testers) much faster and lets you iterate much more quickly. Having programmers do it, before the design is settled upon, is both slower, less flexible, and unable to change to keep pace with the design team. The developers of Hearthstone themselves made a Flash prototype of their game and heavily tested it long before bringing their programming team on board (a fact I learned about a year too late).

Switching gears into programming again was liberating. It not only allowed me to explore and define our mechanics at a much deeper level, but seemed simpler, less messy than the affairs of design or project management. I felt I had found a niche that made me feel more comfortable and fulfilled than what I was doing before.

I decided to step down from my leadership roles and hand them off to other team members. I brought on another Champlain alumni to take over as our Producer, and I promoted Craig to Lead Designer. For about three months, I focused heavily on building out the prototype, while regularly contributing in fleshing out our mechanics and enabling the rest of the design team to build levels.

Over time, however, I felt like many things were being overlooked. Aspects of gameplay, ways to improve productivity - the things that had haunted my thoughts and brought me anxiety before seemed to be looming in the background. While Craig was doing a great job in holding the fort, I didn’t think he was looking at the project as deeply as I was. I bottled up my feelings for a while, hoping for things to improve on their own, but eventually I felt compelled to say something.
 

This lead to a confrontation where I accused him of not taking the project seriously enough, or not looking deeply enough. In retrospect, this was clearly an unfair judgement. I came to find out that in fact he only took on this role reluctantly, as a favor to me, always expecting it to be temporary. I, on the other hand, felt that promoting him to that level was doing him a favor, to bolster his portfolio.
 

It is clear to me looking back that this was the beginning of a darker trend that painted my perception of the project. While I was able to keep my depression at bay for a time, it came crawling back and distorted my view of the project and my team members. At the time I felt that no one understood the game on the level I could. No one could anticipate and diagnose the problems, and subsequent solutions, that I could. I simultaneously felt superior to my team members, yet deeply insecure about my decisions. Regrettably this error did not dawn on me until much later.

Lesson 12: Be upfront and honest about the motivations behind your decisions. In many cases it is the why that is far more important than the what, as the why can be a compass to guide others toward solutions you yourself had not previously considered.

It is also important to regularly plan out times to reflect on how things are going, revisiting the why behind decisions, and people’s feelings about those decisions. This allows you to create a stronger bond of respect and trust among the team, while providing prime opportunities to cultivate creative buy-in.

Lesson 13: Be honest in your criticism and critique, both of design decisions and organizational decisions. You should be able to take and receive criticism, but in a tactful way. “Brutal” honesty isn’t always the best solution, as it can create a negative atmosphere that over time saps energy away from the team. I highly, highly recommend reading “How to Win Friends and Influence People” by Dale Carnegie for a more nuanced technique that balances accountability with a non-threatening, empathetic approach.

Lesson 14: Avoid being conflict averse, but also avoid attaching problems to people. Whenever possible, try to externalize problems and frame yourself and the other person as two people allied against an external threat. This allows you to focus on the positive, while building a stronger relationship with one another.

Taking Charge

In early 2013, our Lead Programmer resigned from the project. For a long time he had been bogged down by working on multiple projects, on top of a heavy course load. I consulted with the Programming team to decide upon a replacement, but no one was willing to take on the task. In the end I ended up assuming that role, under the title of “Programming Team Manager” (I felt “Lead Programmer” would be misleading, as I wasn’t as heavily involved in the actual programming as the other members.) Additionally I found myself once again taking over as Lead Designer and Producer.

Lesson 15: Leadership is a skill like any other skill. Strong ability in one discipline (such as coding) does not translate into strong management skills.

Around this time we had attempted to reach out to the DOE to help secure funds to send a few of the team members to showcase the game at GDC. We spent about a month seeking funding sources on the DOE, and from foundations in the Washington DC area. While there was much promise, which helped fuel team morale, ultimately it did not pan out, and the few of us that went did so on our own dollar.

Lesson 16: Plan your milestones and promotion efforts around game industry conferences and events. This helps establish hard deadlines for you to hold yourself to, as often purely internal deadlines on a small team can be missed due to an accumulation of excuses and compromises. It also gives a tangible payoff at regular intervals, as you build hype for your game and re-energize your team.

Going to GDC did help perk up our spirits, especially mine. I was able to catch some great talks on team management, with some particularly good advice on virtual teams. Mingling with attendees and sharing my story got me into a Blizzard invite-only party, a chance to meet Dustin Browder and Ryan “Morello” Scott. Most surprising of all, a prominent MMO company offered me a design test right on the spot. Things were looking up.

Lesson 17: It is important for virtual teams to maintain a “virtual water cooler” so team members can easily see the progress of the project and hear about what is going on in different departments. We used Google Groups, which is a combination of a forum and a mailing list for this purpose.

Lesson 18: It is also better to conduct virtual meetings via video chat whenever possible, as it further helps team members feel like they are working with real people and helps combat the sometimes emotionless and sterile nature of emails or other text-based correspondence.

Another Setback

At least, they were until I returned home. No sooner had I accepted the design test, then I came down with a bad flu. When I finally got better, I rushed to finish the test. Since it was a “Content Designer” position, I focused on those parts first, as the scripting questions seemed easy. They were, just not when sleep deprived and done at the last minute. This error painted me as a scripting novice, and the opportunity was lost.

Thus my slumbering depression woke again. It felt no matter how much I had been through, that it got me no closer to my dreams. I resolved to focus all of my conscious hours to completing the project, thinking the end of the project was just around the corner.

Lesson 19: We have been conditioned by various old religious practices to believe in karma, or that we get what we deserve. In my experience this is a very unhelpful and inaccurate line of thinking. We get what we build toward, and knowing the correct steps toward heading in the right direction is key.

It is far more valuable to remain focused on what you are doing day-by-day to build toward your goals than to reflect on what you “should” have. This mindset keeps you focused on what is going well in front of you, rather than being envious of a fictional reality divorced from the circumstances that brought you where you are.

Lesson 20: Do not be overly boastful, but do not be too humble either. The unfortunate reality is that if you do not promote yourself, no one is going to do it for you. There are too many things competing for people’s attention, and too many people competing for the same job, especially in the game industry.

For the remainder of that year we spent building out or content, fixing bugs, and refining our art style. While our pace remained steady, it remained very slow. I myself found it more and more difficult to find the time to both manage the team and create content, and often focused on the latter.
 

Team members like Katharine Uvick and Ryan Vachon made a huge impact during this time. Katharine, whom had been with the project as long as I have, outperformed everyone in terms of hours put into the project, on top of regularly contributing to art, design, and programming and later took over as our Lead Artist. Ryan likewise helped us really flesh out our content, contributing the greatest bulk of levels. I was torn between admiring their commitment, and feeling guilty about my own.
 

Increasingly, the game became a source of anxiety for me. There were some weeks where it was literally painful to even think about the project. I felt tied up in the very idea of the project was the sum total of all my failures and lost opportunities. It was at once a source of tremendous stress and anguish, yet the only thing I could cling on to in hopes of a better life. Looking back I feel my negativity during this time was contagious, and one of the big reasons for our slow progress.

Lesson 21: Focus on the positive and use challenges as an opportunity to try something new. You should be using as much time, energy, and creativity in improving your team’s ability to work and remain productive as you do improving and refining your game. Every team member should make a conscious effort in doing this, though having a dedicated Producer is also highly recommended.

Lesson 22: The late Aaron Swartz wrote a great article on improving productivity. One of the key points he mentions is the need to “improve the quality of your time” and have a diverse set of tasks to tackle. That way you could do your challenging and mentally intensive tasks when you are awake and alert, and more tedious tasks when you are in an energy slump.

Testing and Production

Once we had around 25 levels, we shifted our efforts on playtesting. We reached out on social networks, to friends and family, but found our reach rather limited. We ended up with a few dozen testers, but very few of them gave us feedback. The few in-person, intense playtest sessions we did were immensely helpful, but regrettably few and far between. It felt like despite the unique aspect of our game and project, we were unable to stand out.

Lesson 23: Start playtesting early. Preferably, you’ll want to do it shortly after your first prototypes, but be sure that they are both easily playable and accessible to your testers. Making them available to playtest online is the best option.

This also helps you plan out tutorials, and the best way to introduce mechanics at an appropriate pace.

Lesson 24: Start building a playerbase early. Once you have solid concept art and a presentable vertical slice, devote time to reaching out and discovering players eager to try your stuff and contribute to its development. Kickstarter is a major testament to the power of connecting with fans, and even if you are not using it, learning about kickstarter campaigns can offer a great model for doing this.

Since or testing data was limited, I became more focused on analyzing the game on as many levels as possible. I used these insights to anticipate and correct issues and rough edges. It seemed like each time I tested the game myself, I found issues that the rest of the team and our testers had overlooked. Whether these were sparks of insight or madness, I cannot rightly say.

Lesson 25: The mark of a great designer is not the ability to create a perfect idea on the first try, or to anticipate every possible flaw or need from the player. It is your ability to gather and act upon feedback from outside of your team and your own mind.

Do not let your own judgement be a substitute the judgement of one of your players.

What I can say is that it made me feel at once like the only one holding things together, yet at the same time slacking off and not working enough. I made the bold, and perhaps foolish decision, to devote more of my time to the project. At a time when my family was moving to Massachusetts anyway, I quit my full time job and accepted a part time job, and remained at that level believing the end of the project was just around the corner.

Lesson 26: However close a project seems to completion, never sacrifice organization and best practices for perceived expediency. We made the mistake of getting more lax in setting goals, particularly long-term ones, as it seemed like the biggest tasks were behind us.

Lesson 27: After you have a reasonably sound and tested prototype, create a Vertical Slice. It should approximate the audio-visual and gameplay quality you are going for. Even if things end up changing, it helps you establish your asset pipeline (if working with new tools), create a quality benchmark to compare future content against, and gives the team and your potential playerbase a tangible thing to visualize when thinking about your game. Further, it goes a long way toward energizing your team to see something tangible early in development.

Trying to feel out your desired quality level later in development is very risky, and often results in feature creep, protracted development time, and team burnout.

The End that Wouldn’t End

Our next big milestone came with GDC 2014. This time we had a much nicer, nearly complete version of the game, and felt ready and able to show it off at the conference. In advance of the event, we pulled together and worked hard to get it to the level of polish we wanted.
 

Then we were hit by delays. We missed our first date due to weather, and suffered another setback a week later. Between my own overstressed state of mind, and the slow pace of development, I decided I had enough of managing other people. Following GDC, the design team was dissolved, with the art team soon to follow, until there was only the two remaining programmers and myself.
 

For the next six months, we focused on refining the game’s visual feedback, tutorial systems, and polishing off the remaining rough edges holding back the game. We incorporated our social media features, and brought on a dedicated QA Tester, Sarah Patterson, to help thoroughly test the game for remaining bugs. After months of playing bug whack-a-mole, we finally got the game to a polished state we were happy with.

Opportunity and Revelation

Around April I came across another great opportunity - the chance to be part of the Denius-Sams Gaming Academy. It was a program set up by Warren Spector to help educate aspiring game industry leaders the skills to be effective leaders. It was exactly what I was looking for, and with just a week before early decision I prepared my materials and sent them off.
 

I made it through two interviews, one with the man himself. I started reading books on leadership, interpersonal skills, and creative management. It finally gave me a moment to look back and understand what had happened over the last two years. Things were promising, but in the end I only got as far as the waitlist.
 

As disappointed as I was, it brought me toward a new revelation that motivated me to write this blog. For too long I had anchored my self-worth to this project, and sought personal recognition from enduring what I had and accomplishing a seemingly impossible task. But that’s not what I cared about. I had lost sight of the organizing principles I had for myself at the beginning on the project - the focus on creating a team culture. It is these realizations that will be the subject of Part 3.

Terrachanics is now available for Google Play, with an iOS edition coming soon. Stay tuned for Part 3 next week.

UPDATE (3/6/15): As of this writing, our official website is down, youtube videos disabled, and the game has been un-published pending some final legal procedures required by the DOE. In the meantime, a PC version of the full game is available to play on my website.

Read Part 3 Here.