Tales of Terrachanics - Part III

The Art of Abstract Game Design

Working on Terrachanics taught me many things. Tackling it at the height of my battle with depression with many hurdles along the way, I learned valuable lessons about game design, the production process, and life itself. 

Our challenge of designing an abstract, mobile, serious puzzle game can be summed up in one word: communication. How do we explain our mechanics to our players? How do we sell the idea of advanced energy technologies? How can we make a game with cerebral depth, yet without intrusive tutorials? How do we integrate theme and educational content into a mobile game? How can we make a serious game that is both educational and fun at the same time?

Terrachanics is my team's answer to these questions.

A Brief Recap

Terrachanics is an abstract puzzle game designed by a small, virtual, indie team of volunteers for the U.S. Department of Energy (DOE). Its mission was to be a recruitment tool to attract prospective applicants toward job opportunities the DOE offered, as well as educate the public on alternative energy technologies. As developers, we also wanted to raise the bar for serious games, making something that could be every bit as fun as mainstream games on top of being educational.

As of this writing, we are awaiting some final legal resolutions before we can officially (re)launch the game to Google Play and the App Store. In the meantime, I recommend checking out this video for a primer on our mechanics, and if you feel so inclined, you can download and play the full PC version of the game from my website.

The Big Picture

From the outset, Terrachanics was created with two key goals in mind. For the DOE, we needed our game to help drive their recruitment efforts effectively. As developers, we wanted to make a game that accomplished this goal without sacrificing any of the fun factor from the end product.

Given the resources we had at our disposal, we had to find a way to tie in the theme of energy technology into a game that was simple enough to be intuitive, yet challenging enough to appeal to our S.T.E.M. field student demographic.

Initial Inspiration

In our ideation phase, we looked at a number of games on the mobile market. We knew early on that we wanted to do either a puzzle or strategy game, as we wanted the focus to be on problem solving. We debated on making a physics puzzle game (like Cut the Rope), or a trimmed-down city building game like Sim City.

Our discussions made us think hard on what key element of energy technology we wanted to represent, ultimately settling on the theme of interdependence. Having recently played Deus Ex: Human Revolution at the time, I was intrigued by its clever hacking minigame, and thought that perhaps with a little tweaking, this node-connection gameplay might just be the mechanic we were looking for. 

We came to develop a game centered on creating connections between buildings, representing resources shared across a resource network. This concept came to be the backbone of our game - the Linking System.

In a Nutshell

In a typical level, players must create a series of links from a starting point to an ending point on a map. The starting point represents a raw source of energy, such as a solar panel, while the end point (called a Hotspot) represents a crisis or challenge the player must fix by repairing and organizing an area's resource network. All Hotspots have a timer next to them, indicating how many turns you have to reach them. Creating a link, erecting a building, or commanding a Unit all take a turn to accomplish. In short, it's connect the dots with a countdown timer. 

One would think that a game based off of connect the dots would be simple. Yet we found early versions of this mechanic suprisingly difficult for players to understand. This forced us to get creative in how we taught our players how to work with this mechanic.

Linking

In DX:HR, players connect nodes together by tracing lines between them in order to reach a server. The lines between nodes represented connections between terminals on a network, with the ultimate goal of reaching a central mainframe. This theme was intuitive and worked well with the stealth and espionage focus of the game. While a solid mini-game, we felt the mechanics needed a bit more to it to hold its own as a game unto itself.

Our first major change was to add multiple types of links between buildings. These came to be called Resources, representing things like electricity, coal, or ethanol transported from one building to another. Instead of freely being able to link neighboring nodes, players had to examine and match the resource types to produce a path from their start point to their objective's Hotspot. 

For example, a typical level may start with an oil drill that produces Oil, with no requirements of its own. The player would then click and drag to make a link to a nearby building that required Oil. Providing power to this building would activate that building, unlocking the resources this new building would produce to be allocated to a new building. This would continue until you had a continuous chain of links leading to the Hotspot for that level.

While this worked fine on smaller maps, as maps became more complex, it became more challenging for players to figure out which icons corresponded to which buildings. We tried to mitigate this by spacing out buildings, and to keep icons close to their source, but it became clear that players were spending too much time parsing out what was on the screen, rather than intuitively reading what they saw and making the appropriate choices. Text-based tutorials proved to be too wordy and ineffective, and without a practical way to implement video demos, we decided to look for alternatives to teach and reinforce this essential mechanic of our game.

Audio-Visual Feedback as Reinforcement

As the design team worked to refine our mechanics, our Art Team was improving our game's UI and overall art style. We wanted every action the player took to feel satisfying and reactive, so even the basic actions of the game felt satisfying. As we saw these feedback systems develop, we came to realize they could also be an excellent tool for non-verbally communicating how the Linking System worked.

This realization allowed us to offload some of the explanation of mechanics off of our tutorials into the UI itself. Things like "resource rings" were introduced to show which resources corresponded to each building more easily, and animation of icons enlarging or flashing allowed players to intuitively grasp the concept of identifying and matching Output and Input icons. 

Implications for Level Design

It became clear early on that the manner in which we implemented the mechanic would have a huge impact on the pacing of the game, size of our maps, and overall flow of the game. Early concepts featured non-linear maps, where players not only had to create connections between buildings, but also determine where missing buildings aught to be placed. Even working with paper prototypes, we found this approach to be problematic.

At this stage, we were still favoring a more strategy-base concept, where players had to weigh the costs and benefits of different actions in an attempt to maximize their score. We had a system of Events that players had to reach in a specific number of turns. Depending on if they were reached in time, different outcomes would occur, such as a building catching fire due to an outdated electrical system, or a scientist volunteering to help you complete a level. The idea was to have the choices the player made operate under a "realistic" model of cause and effect, tying the game's experience in with an energy technology theme. Unfortunately, this non-linear level design model just wasn't compelling, as players lacked a clear starting point to get their bearings on a level, and it lacked a compelling objective. 

Thus we had our first major rework of the game. We looked at DX:HR again, and realized that each level had a clear start and end point. In making their hacking puzzles linear, it gave players a clear and compelling goal, with a continuous sense of progress start to finish. We decided to try this approach out for ourselves in an effort to streamline our core gameplay loop. Levels were simplified to include one main "Hotspot" that the player had to reach in a specific number of turns, making the player objective more consistent. We did, however, include a number of levels with optional Secondary Objectives, which worked just like Hotspots but without a timer. To reach these, players had to find the optimal solution for a level. Thus we were able to retain many of the top-level idea from our original concept and refine them into a more satisfying form.

In giving players a clearer, more consistent goal with a stronger sense of progress, it allowed us to design tighter, more polished levels that put the player's skills to the test in more satisfying ways. While it did sacrifice some of the more realistic themes we wanted in the game, we ultimately felt this was the better way to go.

As a result of this tweak, we removed the ability to freely place buildings on the map, reworking the concept into the Building Sites system.

Building Sites

Our early prototype featured a sideboard of missing buildings the player had to place down on the map in order to complete their link paths required to complete a level. Players were free to place them anywhere on the map, but had to do so carefully by matching resource inputs and outputs, as they did with Linking. We thought of it like assembling a jigsaw puzzle, visually scanning the map and seeing where each new piece belonged.

With our first rework, we determined we wanted to keep this mechanic, but simplify it and make it more focused and deliberate. Instead of allowing players to place buildings anywhere on the map, we designated specific points on the map called Building Sites as locations where a building could be placed. Thus it still worked like a jigsaw puzzle, but was closer to the end of a jigsaw puzzle, when you are finding the right piece to fill the last few holes.

This mechanic allowed us to further challenge a player's skills in reading the map, as it required a player to not only read the map and find the proper path, but visualize what pieces are missing to complete that path.

Units

Units were designed to make players think about the timing of their moves and be more deliberate in their link path choices. Players not only had to think about what path they wanted to create, but in what order they would make their Links.

Units served as abstract representations of important characters working with the player. They appear as icons hovering over a building, and when their building is activated players can command them to move to other buildings. When moving, they will follow the Link path you created, moving one building at a time each turn until they reach their destination. They would then interact with that building in some way based on the type of Unit.

Over the course of our development cycle, we ended up creating two Unit types: the Engineer and the Agent.

Engineer

The Engineer was created to introduce a timing-based gating mechanism. We designed some buildings to have an "Extra Output," or a resource produced by that building that is initially locked. To unlock the resource, the player must order their Engineer to go to that building to activate it and make it available.

Originally, we thematically explained this as the Engineer being a super-efficient worker, capable of boosting the resource output of a building they were connected to. While this was a decent enough theme for the mechanic, playtesting exposed a few problems:

1. Gameplay ended up just being a matter of going from point A to point B, as originally Extra Outputs only remained active while an Engineer was standing on that building.
2. Due to issue 1, this meant that if we wanted to have more than one Extra Output in a level, there had to be one Engineer for each one. This further would require larger levels to support the number of actions required to get them where they needed to go.
3. Explaining how the Engineer functioned was clunky and difficult through text-based tutorials, especially for a mobile title.

Then, during one of our weekly meetings, one designer inadvertently described Extra Outputs as "Broken" Outputs. What started as a mistake turned out to be a breakthrough for us, as it allowed us to intelligently tweak the theming of the mechanic. Now Engineers would repair a Broken Output of a building, and be able to and be able to do so for multiple buildings on a map. This change both cleaned up how to describe the mechanic to our players, and opened up exciting new level design possibilities.

Agent

The Agent started its life as the Researcher. It was a Unit that would move around the map collecting Data Fragments attached to various buildings, then deliver them to the Hotspot. It was an evolution on the Engineer concept, involving a two-step thought process in order complete the levels that used them.

In our original design, levels with the Researcher would contain around three or more Data Fragments, each representing a piece of a technology required to complete your mission. Some Data fragments would be components or blueprints required for the technology you needed to complete your mission, while others would be irrelevant information (like a silly email or spoof on an internet ad). Players would have to click on each Data Fragment to examine them, displaying a description of what they were looking at. The player would then have to determine which of the Data Fragments were useful, and plot out a path for their Researcher to retrieve and deliver them. The idea was not to make this task hard, but to force players to think about the function of the technology of the level and the components that composed it.

While this helped in terms of making our subject matter a more explicit part of the game experience, it proved too clunky in playtesting. Taking the time to examine Data Fragments felt more like a chore than an interesting challenge, and did nothing to make the technologies in question more interesting. We knew it wasn't working, but  we were reluctant to change it, as it was the last refuge where our game mechanics explicitly dealt with our subject matter.

We knew our problem was bigger than just this one mechanic. Shoehorning educational content into the game was a losing strategy that so many serious games before had done. It disrupts the pacing of the game and makes education feel like a roadblock to enjoyment rather than a source of fun. The mechanic also had the same problem as our early Engineer concept did, requiring larger, more complex levels than we felt would be appropriate for a mobile game.

We ended up rebranding the Researcher into the Agent. Instead of examining and picking up pieces of Data, the Agent would collect Packages, then deliver them to the Hotspot. There would only ever be one Package per level, thus players only had to reach it and deliver the Agent to the Hotspot. We distilled the mechanic down to its core essence, and as a result it was a lot more enjoyable.

As a result of this change, however, we had to re-evaluate our priorities as a serious game. Would we continue to water down our educational content in favor of making the game more fun, or would we have to sacrifice our gameplay to make such content more prominent? Fortunately, we found a solution that would please both parties. It involved re-thinking our approach to delivering educational content.

Educational Content on Mobile

As previously mentioned, the goal for the DOE with this game was to have a product that would attract players toward a job at the DOE. Our approach to this was to feature a variety of cutting edge energy technologies in a in a wacky, spy-spoof setting. The idea was that by contextualizing energy technology within a fun setting, it would entice people to want to learn more or explore career opportunities in that field.

Yet many times making a serious mobile game felt like a contradiction. Successful mobile games, like Angry Birds or Candy Crush, rely on fast-paced gameplay with minimal downtime between levels. Games that featured stories, like Tiny Village, often had easily skipable narrative segments, which were indeed all to often skipped. This posed a challenge for us in terms of approaching narrative, educational content, and tutorials.

So we decided to look at education from a different angle. We looked at TV shows like Captain Planet, which contextualized environmentalism in an action-filled fictional universe of empowered kids. We saw a similar dynamic at work with Pixar movies, like Wreck-It Ralph, which successfully featured compelling life lessons alongside moments of thrilling special effects. We wondered if perhaps we could approach education through inspiration instead of lecture, as they had done. What if we focused on an emotional appeal to get people to care about energy technology?

Thus we developed a new guiding principle - optional educational content. Rather than forcing players to read through data logs or be bombarded with facts and figures, it was our job to convince players to care about energy. Not only would we not try to beat players over the head with our subject matter, but we would make it so players could enjoy the game even if they had no interest in learning. Our goal shifted toward finding ways to entice players into wanting to learn, rather than being a traditional teacher.

This idea tied in with our distribution strategy. By putting enjoyable gameplay first, our goal was to go for volume. If 100 people played our game, 10 people would be inspired to learn more, and maybe one or two might visit the DOE job site. Multiply this by thousands or even millions of players, and suddenly we are reaching more people than conventional education or recruitment methods might never reach. This wasn't just a stab in the dark, either, as we were encouraged by the success of America's Army, which has been doing this successfully for years, achieving "more impact on recruits than all other forms of Army advertising combined." 

Integrating Educational Content

With this in mind, we decided that in order to sell our educational content, it had to be framed as a reward and take center stage. This informed how we developed our scoring system and narrative delivery.

We moved away from having a long story arc as we previously planned. Instead, we focused on a more emotion-driven narrative centered on our key characters. We presented narrative in the form of small vignettes to flesh out each character and establish the lighthearted tone of the game. Mission descriptions were brief, but usually featured a joke or two, with the goal of each mission prominently highlighted. For our loading screens, we used comicbook-style narrative sequences of the ECRB gang's various antics. These were interspersed with job descriptions for positions with the DOE. These all worked to make our subject matter prominent, without being too intrusive.

Mechanically, we made learning about energy technology more rewarding by merging our Codex system into our score system. The Codex was planned as a database of info on the technologies featured in the game, with one-click access to resources to learn more. With our score system, we had toyed with the idea of achievements, allowing players to collect badges for accomplishing specific tasks. After some thought, we realized that we could enhance both by turning them into a single system.

We decided to combine these two together, making Codex Entries on various energy technologies appear as badges in your Codex gallery. Not only did this make the Codex more visually appealing, but it tied energy technology directly into our award system, enticing more players to learn about our subject matter.

The Takeaways

As soon as you decide to make a game abstract, you immediately raise the learning curve of your game. This can be mitigated by clever thematic choices and use of visual metaphors. The more you can communicate non-verbally, the more intuitive the experience feels, and the more you maintain player immersion.

• Enhancing our UI feedback with this in mind dramatically improved how quickly our players grasped the nuances of our Linking System.

By the same token, it is also good to develop tutorials early in the design process, such as when developing a vertical slice. When considered alongside the theme of your mechanic, this helps identify sticking points in explaining the mechanic to players while creating a common vocabulary and understanding for developers to work with.

• By simply redefining an "Extra Output" to a "Broken Output," we were able to make the mechanic more compelling and intuitive.

In iterating on any aspect of your design, consider the purpose behind each element you put in the game. As you develop your game, compare this original purpose with the new solution in front of you, and decide which one has to change. Sometimes you will find alternate solutions that still satisfy the same need you had previously identified. This will help you develop a more strongly defined concept, helping both players and developers understand your creative vision.

• In playtesting our Linking system, we eventually came to define our game more as a puzzler than a strategy game, making all subsequent decisions more deliberate and focused.

Too many serious games are held back by fixating on their subject matter to the detriment of their gameplay. If you game is bad, no one will want to wade through it to learn about your subject matter. Don't try to be the one-stop-shop for information on your topic. Instead, be the gateway toward your player's own educational experience. Make them believe in the impact of climate change, the urgency of stopping violence against women, or to empathize with kids in war-torn Sudan. Touch their hearts first, and let them take the next step toward learning more.

• Terrachanics is a game first, and a message second. It is the icebreaker to intrigue players into learning more about energy technologies, and perhaps develop a long-term relationship with through a career with the DOE.

Please Help Spread the Word!

Thanks for reading! If you appreciate this blog series, or even better our game, please spread the word about us on your respective social networks. The wheels of government bureaucracy have not been kind to us lately, and despite completing development back in August, we are currently unable to properly release our game until some legal hangups are cleared up.

The DOE has also restricted us from making any social media accounts for the game, had us take down most of our videos from youtube, and our official website is currently down until things come together on their end. So any help in getting our names out there would be much appreciated!

Next Time on Tales of Terrachanics...

Stay tuned for Part IV, where I will be delving into some more philosophical revelations that came out of this experience, related to work ethic, leadership, and communication.