“Mind Game” Postmortem: Lessons Learned From My First Public Project

For the past few months my classmates and I were working on a project in collaboration with Carnegie Mellon University CyLab. This project aims to create a game interface that wraps around picoCTF, an international cybersecurity competition for middle/high school students. We worked to provide an alternate means of participating in the event that would appeal to the more general public (i.e. people who have some interest in the topic but little to no prior knowledge).

Our team is composed of four members:

  • Magian – Producer
  • Tina – Artist, Writer
  • Max – Tech
  • And me – Designer
This was our team photo. Yes it was on purpose to look like the Rami Malek meme.
From left to right: Max, Magian, me and Tina.

In addition, we had approximately 15 weeks to finish the entire project, and the final product won’t go live until September 27th, when the competition launches. It has been a tiring but fruitful and amazing 15 weeks of my life, and in this post I wanted to talk about some of the challenges we’ve met and the lessons I’ve learned during the process.

Challenges

Low on workforce

As mentioned, our team has four members, and each one of us has our own designated role and responsibilities. In reality, however, we were all programmers. Unlike most other project teams, we didn’t have an artist, and we didn’t have a sound designer. While sounds are of less priority in this game, the lack of art skills is a serious problem we needed to address as early as possible. On a more general sense, having only four people on the team also meant that we would be having more on our plates compared to our friends on other teams.

To resolve the art problem, Tina volunteered to be the artist, but that wasn’t enough. Tina and I went through some discussion on the aesthetics and art style for our game, and we particularly examined last year’s game, which art-wise is a hybrid of 2D art cutscenes and 3D gameplay sequences. Eventually we came to the conclusion that making 3D assets wouldn’t be as efficient and cost-effective, since we then had to deal with materials, rendering and lighting problems that would take us extra time.

On the other hand, we thought that playing with 2D pixel art might not be a bad idea. It’s fast to iterate on, and is as expressive as other style of art. As we decided on making pixel art, we quickly ran over an art pipeline to ensure we are working at both the highest quality and the maximum efficiency.

I was totally blown away by the quality of work Tina has delivered. This is the layout for the volcano room and the lava actually animates.

Speaking of materials, rendering and lighting problems, I also went over the technical details with Max as well and established a standard procedure of adding, editing and deleting stuff from a shared repository. This was not just because I was the design lead, but also because I was the buildmaster of our team, so I needed to make sure that our latest working build is clean at all times.

Some guidelines I wrote on the README.md of our repo.

There isn’t any way to work around the challenge that we only had four people. One approach was to determine fast on what we can do in a short amount of time (like how we ended up doing pixel art); but generally speaking we were mentally prepared to do more than expected.

No control over difficulty

Interest curve is an important index of how a game captivates its audience. In my opinion, it often stems from the difficulty curve of the adventure. Remember how you started easy in Mario Odyssey and ended up clearing the Moon level? That’s an example of difficulty and interest curve. I think it’s safe to say that a good game has a good interest curve, and a good interest curve comes from a carefully-designed difficulty curve.

「mario odyssey moon」的圖片搜尋結果
Spoilers: this isn’t the end game level.

Unfortunately, we had absolutely no control over it. Mainly it’s because this was, after all, a cybersecurity competition. We weren’t in charge of designing the problems themselves, that responsibility lies with our client; but more importantly, the complete set of problems will only be made public when the event commences. This meant that we would have no idea — and we still don’t — on how the problems will be when it launches.

Looking back at the game from last year, the team worked around the problem by providing a problem interface within the game and put optional minigames that followed a storyline. For me, I experienced a disconnection between the problems and the game (story) itself, and such implementation kind of defeats its own purpose.

So, along with the team, we attempted to weave the progression of the story with the the completion rate of problems. Players will need to solve problems and gain points to a certain threshold; when this checkpoint is reached, it unlocks the next part of the story.

An early version of our attempt to address the progression and difficulty problem, drafted by me.

There is a risk, though: what if players aren’t capable of solving enough problems to get to the next checkpoint? We also can’t expect all players to be on the same skill level. This is where we used minigames as an alternate method to aid the players. In our game, whenever a player plays a minigame and completes a level, the player is given “hacker tokens”. This tokens can be used to buy extra hints, which are essentially videos that walk the players through the problems.

A previous version of the problem UI. The scribings on the right is only shown first time players activate the interface. If they’re stuck and have enough tokens, they can press on the “Hack” button and get a walkthrough at the cost of some tokens.

Since having walkthroughs is almost the equivalent of giving away answers, which could potentially harm the integrity of the competition, we were extra careful with the feature and discussed several times with our client on what problems are allowed to have walkthroughs. These problems are generally the ones that most people could solve (i.e. not the million-dollar question).

Overscoping

Our solutions to the previous two challenges along with other decisions made throughout the way added up becoming a helluva burden for us. Despite our efforts to start early, research proactively and cutting out unnecessary features, it was still a lot of work for all of us.

I think what kept us going forward anyways was us knowing that “this is it. This is the bottom line we could accept.” Leaving out any extra part and the project would become incomplete to us. I know I described it like it was Armageddon, but frankly I think this really was the constant atmosphere in the project room.

Lessons

Be Proactive

This is more of a lesson to myself, but specifically as a designer, it was my duty to not only design and re-design, but also to communicate these ideas and actions to our client as early as possible. For our project, although they didn’t really step into our production, it was them who had the final say. Being proactive mitigates the typical problem in which features have been fully implemented, only to find out that something went fundamentally wrong.

I keep a large cardboard behind my seat. I use it to stick brainstorm ideas, level layouts and notes. This way everyone can read and work from it.

Time is not your friend

Before this semester, all first years took a class named Building Virtual Worlds. It was an extremely fast-paced class in which teams are expected to turn in a playable demo within 2 weeks, basically rapid prototyping. Eventually we became so used to the time pressure that, upon knowing we had 15 weeks to turn in a game, everyone thought they had a lot of time.

This was totally not the case for us; we took the first 3 weeks researching and deciding early goals. We took the rest 12 weeks to build up the game, while playtests were scattered around the semester. This schedule was not effective for we could not harvest good playtest data. In the end it was almost like a blind shot into the void, hoping that the dart would somehow land near the bullseye.

But also rest good

Fatigue kicked harder and harder on me as the semester went by. Besides this project, I was also taking a Game Design class by Jesse Schell, which was also very demanding. Sleeping time started to gradually decrease, and in the end, I could feel the quality of my work deteriorating quickly.

Scope, scope and scope.

Scope is a hard thing to define. As a designer I maintained constant awareness of the magnitude we’re going for the whole time. Although we did overscoped, I said yes because I believed that it was still within reach, but we just had to push harder. But what if we aimed for something a bit bigger than that? Would we be able to complete before semester ends? I’m not so sure about that.

From my experience, overscoping generally ends in only two cases: either the product is not complete, or the product is complete but in very bad shape. I’d say that for our case, it was more of the latter.

Passion

I’m glad to be on this team. We maintained the passion we had when we set out on our journey, and I believe if we hadn’t kept that attitude, given the time and workload pressure we’d fall apart mid-way.

Speaking of passion, I’d like to apologize for sometimes pushing my teammates a little bit too hard. I know that for Tina, it wasn’t an easy task at all since we needed different sets of tiles for each room; and for Max, he had to deal with both back-end (communications with the problem server) AND front-end (Unity). But I’m glad we all made it through.

So yeah. I might be adding in more in the future, but these are my thoughts for now. Thanks for reading, and

thanks for the great semester, team.

Published by

Brian Teng

Game Designer | Pittsburgh, PA

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s