Powered Up
Terrachanics is a mobile puzzle game designed as a recruitment tool for the U.S. Department of Energy (DOE). It is designed to contextualize cutting edge energy technologies alongside mind-bending puzzles to attract STEM field students into careers with the DOE.
The game was built by a team of 321 volunteers from around the country. I served as the Lead Designer and Producer (aka Project Manager) for the duration of development, as well as the Programming Lead going into our second year.
The Challenge
Terrachanics was the largest and most ambitious project I had ever done. What began as an internship opportunity grew into what felt like running my own business. I was given unprecedented creative freedom and trust from the DOE, without any budget or time restrictions to speak of. With such a generous and rare opportunity in front of me, I wanted to use it to build the team and the game I’ve always wanted.
I learned many lessons over the two and a half years I spent working on the game. I wrote about my experience in detail in my Tales of Terrachanics blog series for the game industry website Gamasutra (now GameDeveloper). Here I will give a brief summary of the series, and highlight some of the main lessons I got out of it.
- Part 1 discusses the foundational goals I had for our game and team culture, as well as the personal struggles I had dealt with that shaped my motives going into the project.
- Part 2 describes the hurdles we encountered during the production process and the challenge of balance forgiving, nurturing leadership with holding people to a professional standard.
- Part 3 talks about the design decisions made to ease players into our abstract mechanics. Much of this involved iterating on our interface and tutorial design, as well as adjusting our theming to make mechanics more intuitive for players.
- Part 4 features my reflections on how the project turned out, what I learned about leadership, and how my experience changed by outlook on life. In a nutshell, I developed a much deeper understanding of the psychology of human interaction, and how to better motivate those around me.
The Lessons
Being heavily involved in the creative, technical, and managerial aspects of the project, there was a dearth of great lessons gleaned from the experience.
The Creative Side
In terms of design, I was most heavily involved in design of our mechanics. The most valuable lessons I found, however, came in the areas of interface design and critique.
Interface Design
Given the abstract nature of the gameplay, we had to get creative on how to present the mechanics to maximize player comprehension. We decided early on not to lean on tutorials too heavily, and instead design the game to be intuitive enough that its concepts could be easily grasped and retained by our players. We accomplished this through careful theming and aesthetic choices.
The effect of theming and presentation was most present in our core mechanic, linking, where buildings link together based on the transfer of “resources” from one building to another. We took several passes on designing the icons to ensure they were both readable and reactive to player activity.
Essentially, by creating interface elements that responded to player actions, it helped to reinforce the more esoteric aspects of the game passively and non-verbally. This way players only required an initial written explanation, and would be non-intrusively reminded each time they interacted with the mechanic.
Creative Leadership
I have come to realize that there are special challenges that come with creative leadership. Compared to technical contexts, there is much more subjectivity and emotional influence involved in maintaining quality work out of your team.
Because creative work involves creating novel ideas that no one has seen before, it becomes imperative to create shared aesthetic sensibilities. Accomplishing this involves not just verbal and written communication, but reference images, examples of similar games, music, etc. In short you must use a plethora of media sources to create a clear picture in the minds of the team.
This is especially true when it comes to critique. When offering an opinion on an asset, you must not only be able to clearly articulate your thoughts, but use it to contribute to a unified aesthetic framework. It is likewise important that each comment is honest yet supportive, inspiring artists to build upon their talent, not slow down through anxious friction.
In short, deep communication is required to ensure a viable and productive creative team.
The Technical Side
By far the most enjoyable part of the development process was working with code. While my direct involvement was limited to our prototype, I did end up working closely with the programming team to develop our weekly priorities and tasks and how best to tackle technical issues.
The Importance of Prototyping
A lesson I learned too late was the importance of having a working demo of your product early. While I initially leaned on our team of 6 programmers to give us a playable build, it turned out they did not have a firm grasp on our concept even 6 months into development.
As the designer responsible for our mechanics, it seemed fitting that I would create the prototype myself. Doing so allowed me to produce an interactive blueprint for our programmers, as well as an experimental sandbox for the design team to test our ideas.
By making the prototype a part of the conceptual phase, it gives us a live representation get our iteration cycle up and running early and quickly. I was able to identify edge cases and details early that allowed us to anticipate potential challenges later down the road, and thus account for them in our project plan.
The Management Side
While I had taken leadership positions in student projects in the past, the scope and scale of the project and our team tested my leadership skills to its limits. While I felt my leadership style worked fine with the programming team, I was less successful in motivating and directing our creative teams. In my desire to improve these skills, I came to learn some excellent lessons in inspiring others and mitigating destructive conflict.
In Theory…
I had lofty ambitions for our team culture. I was inspired by a behind-the-scenes DVD I watched from Blizzard Entertainment, detailing the culture of their studio. They believed in having every team member, every employee, have a say in the design of their game. They believed in leveraging diverse opinions and allowing everyone to make a mark on their product to create buy-in and a sense of collective ownership. The also believed in taking their time to perfect every product, ensuring the best possible quality for the end product.
Secondly, I wanted to give young developers and students a chance to prove their skills on the job, rather than be like so many companies and demand proven experience up front. I believed that given the right environment it would allow people to spread their wings and prove their worth. I was forgiving of mistakes and delays, believing that this would maintain higher morale.
In Practice…
It is indeed possible to create a team culture as Blizzard has done. Such cultures are discussed in even greater detail in such books as Collective Genius, by Linda Hill et al. Yet it requires a certain finesse and mastery of inspiring dialog and discovery on the team beyond the scope of my modest leadership background.
It is every bit as important to design your team as it is to design the product. I wanted to take a rag-tag team, but them into the “perfect” work environment, and witness what they came up with. The team I had, however, was largely composed of novices who lacked the confidence and drive to be as opinionated and passionate as I anticipated.
Giving people the benefit of the doubt and prove their skills on the job is a great sentiment, but can be costly in practice. I made the mistake of trying to be hands-off, holding back my opinions and tendency to micromanage everything. In spite of my intentions, this only created a vacuum that left my team without a clear vision of our goals and how they fit into them.
While I feel there is much more I have to learn about leadership, in my pursuit of learning more I did stumble across some excellent insights that have changed my views of the world. Collective Genius not only touches on how to seed vibrant and innovative cultures, but describes an approach where conflict and diversity is embraced and leverage.
The mantra “strong opinions loosely held”, sums up this sentiment perfectly. It injects emotion into the conversation to fire people up, while maintaining humility and curiosity to seek better alternatives to ones own ideas. I think this is a notion that could radically improve our workplaces and our world.
Epilogue
As of this writing, two years after completing the game, the Department of Energy has yet to officially launch our game. Given the time, money, and effort put into the project by myself and the team, this was obviously devastating news. In spite of repeated assurances to the contrary, it us unlikely the game will see the wide release or marketing push the DOE initially promised us.
As such, myself and my team have had to point our career objectives elsewhere. For myself, I have decided to concentrate on improving my programming skills, particularly Web Development. I have come to realize that my core interests lie in building and understanding systems, and I have felt the most engaged when building games from the ground up.
I intend to continue to make games as side projects alongside my Web Development work. Whether I rejoin the game industry some day in the future remains to be seen.
Additional Links
-
Total participants over lifetime of project. Varied from 16 to 2 at various times during development. ↩