Postmortem: Terranaut

Terranaut

Terranaut is a 2D exploration game that took a team of seven developers over 500 man-hours to complete. In the game, the player assumes the role of the Pioneer as he attempts to save his home world from destruction by terraforming a new planet. Terranaut utilizes an air jump and air dash mechanic to aid the player in collecting crystals and exploring the various environments of the game’s world. In this postmortem, we go over the what went well, what went wrong, and lessons learned through the game’s development.

What Went Well:

High Team Cohesion

Team cohesion can make or break a game. Too often, a great game idea is ruined by a lack of team buy-in and bickering amongst members. Fortunately, our team encountered very few issues amongst each other. Communication within the team is open and frequent. When disagreements arise, we would discuss the issue and address each other’s concerns. For the most part, this was a quick process, as everyone on the team knew that we all want what was best for the game, and not just individual glory. As a result of high team cohesion, our team was able quickly deliver on milestone requirements, and more importantly bounce back from low morale after a problematic vertical slice milestone.

 Figure 1: Terranaut Team Picture

Fun Was Found Early

The air dash mechanic of Terranaut was discovered early in development. Terranaut was originally conceived with three mechanics revolving around three elements: fire, water, and air. We tested the fire and air mechanic for our proof of concept technology milestone, and found that testers gravitated much more strongly towards the air dash mechanic than the fire/projectile mechanic. As a result of the aforementioned discovery, we decided to focus solely on the air dash mechanic. This gave the team ample time to refine and design interesting scenarios revolving the air dash.

Strong Art Direction and Art Team

The art style for Terranaut was locked down very early in development. To set ourselves apart from the other student games, we opted for a painterly art style. Our two artists did a great job communicating with each other and the team, and were able to establish coherency between their styles. While this painterly approach presented unique challenges when we switched to a tiled approach for our level building method (the artists have to remake all of the environmental assets in a week and a half), the ultimate result was well worth it. Out of all the 2D games made at the Guildhall@SMU that semester, Terranaut won the award for best art, which would not have been possible without the strong art team.

What Went Wrong:

Did Not Stress Test Engine

Terranaut was built using an updated version of the Guildhall@SMU’s proprietary engine, GuildEd. Early in development, we decided to approach level construction differently than we have in the past. With this original approach, the level designers would initial design and construct the level with blank tiles, and then the artists would come in and paint over the level to give it a handcrafted feel and avoid the repetitive feel of tiles. The final, painted level would then be cropped into about a hundred unique individual pieces and imported into the engine for the level designers to reassemble in the foreground, over the structures constructed with blank tiles.

However, this plan did not go as smoothly as planned. The game engine, GuildEd, was unable to store a large amount of unique actors. This restriction of the engine manifested itself during the integration night for our Vertical Slice milestone. Our level could not be build, as the engine crashes every time we try to save the level. At the time, the team had no idea why this problem was happening, and our programmer worked tirelessly to figure out the cause of the issue, but was too late when we figured out the reason. With one more day before the milestone deadline, we were unable to redesign and implement a new Vertical Slice level, forcing us to demo the level layout using blank tiles and the art of the game separately. This problem would have been mitigated if we stress tested the capabilities of the engine when we started development. Fortunately, our gameplay was well received enough for us to pass the milestone, and the team was able to make a comeback by switching to a tile system for level construction.

Figure 2: Original Level Paintover by Austin Chalk

Low Morale Vertical Slice

The morale of the team, especially the artists, were understandably low after the aforementioned incident during Vertical Slice. When we switched to a modular tile approach for constructing our levels, the artists faced the daunting task of remaking all of the environmental assets in a week and a half. For a few days after Vertical Slice, the atmosphere in the room was somber. Luckily, the team’s high cohesion enabled us to recover from the low morale. The rest of the team was extremely encouraging toward the artists, offering support wherever needed. In a funny way, the problematic Vertical Slice brought the team closer together than any other event during development.

Some Design Decisions Were Not Solidified Early Enough

While the main mechanic of the game was locked down early, some of the other systems like the HUD and level objectives were not as concrete. This is due in large part to the desire of the team to respect everyone’s opinion. Because we wanted to make sure every team member has a say on the game’s design, our early design meetings were often pulled in many directions, and ended without a definitive decision. Luckily, we recognized the issue and added more structure to the meetings, such as writing out our ultimate goal for the gathering and referencing the pillars of our game to provide focus for discussions.

Lessons Learned:

Modular Design

One of the most important lessons we learned from our mistakes at Vertical Slice is the value of modular design. By building a level with tiles, the level designers can quickly iterate and change the layout after receiving feedback. Additionally, tile sets also gives artists time to create more assets instead of waiting for finished level layouts to be painted over. After we switched a tile system for Terranaut, levels were finished at a much quicker pace, which in turned gave us more time for playtesting and polishing.

Figure 3: New Screenshot of Game After Switching to Tiles

Manage Expectations

Everyone on the team wanted Terranaut to be special and wanted the game to include many more features. However, it is also important to take into account the amount of time we have to make the game. With only two months to complete the project, we had to be realistic about what we can include in the game. While we wanted to have five different environments in the game and animated intros and outros, two months is simply not enough time to include all those features and polish them to a satisfactory level. Instead, we had to focus on the core of our game, the feeling of exploration and the air dash mechanic, and bring those features to a high quality level.

Murder Your Darlings

Sometimes, features had to be cut from the game not because of a lack of time and resources, but from not being cohesive with the game’s core design. As mentioned earlier, we choose to focus on the air dash mechanic of the game because it resonated most strongly with the testers. We cut the fire and water mechanic from the game because we could not find a way to make them work with the exploratory aspect of our game. We also decided to cut our ammo system, which we put a considerable amount of development time into. We cut the ammo system because we found that having ammo made the game too restricting for the player, which conflict with our core pillar of freedom of exploration. For the good of the game, it is sometimes necessary for the developer to shelf some great ideas for a later project.