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
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.
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.
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.
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.
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.
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.
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.
