Week 3 is for the real work in pre-production. In this week, we majorly worked on preparation in every aspect of the production, including story, gameplay, art and so on. Following are the details!

Production

We know that we have a small team working on a delivery project, so inevitably there will be more than one title for each team member. Therefore, making responsibility clear and locate different tasks on different person is very important. So after two weeks of accommodating and adapting in the team, we finally had a meeting to make the RACI chart. We think this chart will cover the most area of the project, and we will keep it updated if anything happens and changes our mind.

Take a look at our scrum board!

Lastly, for the quarter walkarounds next week, we prepared the slides that includes a general overview of our current progress and details in all aspects followed. Retro is our language!

Design

It was particularly a rough week for design as we dig into more details on the competition. The main demographic for our game is the players who have a genuine interest in computer security but are not aiming to complete the competition. The skills of these players range from totally no knowledge of command-line operations to players who have a decent amount of experience but still struggles to complete harder problems. Finding a way to accommodate both ends of the spectrum is an interesting question to answer.

In almost every game out in the world, when a player is met with difficulties that seemed unbeatable, the world (or the game) offers hints to the player. In picoCTF however, it’s impossible for us to give out hints, as this design could potentially impede the fairness of the entire competition: serious players wouldn’t play our game for more efficiency, but it could require them more time to solve the problems, as opposed to play the game, get hints and solve them right away.

Another problem we set out to conquer is the connection between the story and the problems. We saw this problem in last year’s (2018) game, in which the story has virtually nothing to do with the problems. To us, this caused a serious disconnection and it felt really awkward, almost too intentional; other than that, the mini-games present in the game were supposed to teach players about computer security concepts, such as encrypt/decryption, buffer overflow and more. Yet the mini-games lacked instructions and context, and it was extremely hard to notice the lesson that the experience was trying to convey, let alone learn.

Our least concern is the duration of the contest. The 2018 edition of picoCTF lasted 10 days. We thought that if we wanted to invite new players to come and play, and eventually find out that computer security is an interesting and important topic to learn, we should definitely keep them around in the competition as long as we can. Of course, due to our team size it is unlikely for us to make 10-days worth of content, but this is an interesting direction that we’d like to explore.

After taking all of these thoughts into consideration, we currently have a very rough design that works as follows:

>> The entire story and content is split into 10 portions, and each day the portion is made available to the players after they solve a problem that day.
>> If players didn’t play that day, or failed to complete the problem, they must solve it before he can proceed.
>> To encourage players to do more questions, there will be a separate section in the world that provides extra problems to the players. When they complete enough problems, they will be granted early access to next day’s content.

Although this could be a solution, such design contains many flaws and holes, and it wouldn’t work well on a number of levels. For example, what if the players simply couldn’t work pass a problem due to their own capability? Where do the problems from this “extra section” come from? If players are able to overcome the harder challenges in this extra section, how would they be interested in coming back and solve the easier problems?

On top of all that, releasing content day-by-day isn’t something pleasurable to the players: Netflix, Amazon Prime and several streaming services are now altering their publishing plans for their new shows, for people like binging.

However, after our Friday meeting with our client, we received a few key items that might come in handy in our design:

>> Extra Hints (walkthroughs): In the original set of problems, each question comes with a hint. The problem dev team mentioned that they can also offer walkthroughs to some problems at the beginning. At first we were shocked about this, but then it became reasonable since for serious players in this competition, the easy problems will never harm their chances of winning; in fact, only the last few Ph.D. level ones are the million-dollar-questions.
>> Tokens: This was an idea given from them. Maybe we can utilize the concept of tokens in our game, and find an alternate way to replace the need of developing an extra set of problems.
>> Response analysis for 2018: After the meeting, they sent us data from last year that records all the statistics from last year’s competition. These numbers include the solve rate, participating rate, difficulty, and their own retrospect on each problem. This may come in handy as we believe there will come a time when we need to draw a line to tell which problems are the easy ones, and which are the ones that hurt more.

With all these new items and suggestions, I believe we will be able to come up with a better version, and finalize it before next week ends.

Besides designing the progression system for our game, we’ve also touched some of the following topics during this week:

>> Getting used to 2D pipeline in Unity
As we have nailed down the art direction we’re moving forward in, we tried to familiarize ourselves with Unity’s 2D production pipeline. We learned about the capabilities of the tools, and learned how to create a simple yet beautiful scene with it.

>> Drafting out UI designs
In our game there might be much to be conveyed, so we needed a clear UI design that holds as much information as possible while not overwhelming the player. Currently these designs are temporary and subject to change, but it shows a bit more of how we think the game should look like.

Tech

Prototype:

We decided to begin with making prototypes of the game with some basic interactions to try out so that we all have a more solid idea what the game would feel like. Our plan was to make prototypes with 2D top down mechanics first, and if those didn’t work well, try platformers instead.

The prototypes we made turned out to be adequate. By the end of the week, Max’s prototype had the following features:

>> Point and click movement
>> Interaction with world objects through the UI
>> Movement between rooms

During the process, it was discovered that Unity has no native support for pathfinding in 2D, and it requires either downloading external assets or writing our own pathfinding algorithm. However, we decided to move to a keyboard control scheme using WASD instead of keeping the point and click control scheme like last year, so the problem is no longer an issue.

Tilemap:

We also explored tilemap in Unity, which is the primary means to construct a 2D scene in Unity. Unity tilemap comes with a collider setting, which means we can define certain tile textures as impassible colliders, which would help us build scenes faster.

Story

In the previous two weeks, we had brainstormed a mix-and-match chart of relevant story ideas and themes that we would be interested in.

We then collectively rapidly brainstormed and developed several storylines and narrowed it down. Based on our votes, we all liked the idea of a mystery where the player figures out the world as they are playing, and the idea of a dream world and dream logic.

Throughout the process, we kept several factors in mind:

>> Mystery. The story should puzzle and excite the player, intrigue them and invite them to explore.
>> Sophistication. We are aiming a little high for the “fanciness” and complexity of the story, partly because we suspect middle and high school students shouldn’t be underestimated (this should ultimately be proven or disproven by testing, of course), and partly because we expect to provide relatively simple art work for the game, and so wish to compensate with a more complicated story.
>> Giving context to the problems. We will try as much as possible to have the story be friendly to the integration of the hacking problems, since those are a central aspect of the game.

By the end of this week, we narrowed the storyline down to one and presented a logline and treatment to the client to receive feedback.

The feedback we received was positive. The main point of improvement the client suggested was that it would be preferable to emphasize, as much as possible, the idea that studying computer security can lead to legitimate security jobs, and to veer away from “lone hacker” ideas.

Next week we will attempt to finalize our story by mid-week, so that we can make more design decisions and test the story on audiences.

Other things we did in the week:

>> Team Dinner! Yay! We went to Fogo de Chao, a Brazilian all-you-can-eat steakhouse. It was SUPER. If you’re also in Pittsburgh area, don’t miss it!
>> Prepared quarter slides
>> Set up weekly team hour!

For the next week, we’re planning to:

>> Get feedback from quarters
>> Merge the current prototypes
>> Find/make more concept arts/Moodboards
>> Have a thorough story
>> Take team pictures. So excited!

---