It is very hard to come up with a title for Week 4 since we did a ton of work in all areas. But anyways, we have decided to go with the biggest event happened in this week, Quarter Walkarounds.

Quarters is an activity that ETC has for student projects, happens usually in Week 4/5. In quarters faculty will be in groups and walk around all projects, listen to their presentation and give feedback. Each group will stop by each project room and stay for 15 minutes.

In a word, we had all faculty in ETC visited our project, and we presented our goals, progress and plans, then received very useful feedback. Below are more details in all aspects.

Production

In our schedule, week 4 is the end of pre-production phase. That means we have to get the answers to many questions, make a lot of decisions, and force ourselves to move forward and make something. The progress so far seemed well, however, it could easily fall into a place where little drawbacks can slow the entire project noticeably.

But at the same time, quarters brings many feedback to each project, and those feedback could affect decisions, or even directions of a project. So it is challenging to be ready for quarters, take all the inputs and then react fast to them, lastly make all the decisions, in only one week.

As a result, I think we handled it pretty well. We definitely realized that there are some work need to be improved to meet the mark of “ready for production”, and some decisions need to wait for some other work. Our solution is to get some help from faculty, and finish them up in parallel with our early production phase.  For example, the story will need playtest and iterations for its detail, but we will nail the major arc down in the first sprint; mini games are a little behind, we’ll start developing them in the next sprint.

The closing of pre-production is always a mixture of excitement, a little of chaos and some scare. We know we will build a good game, but there are things unclear and they can make people feel worried. We believe with more work being done, all those uncertainty and the anxiety will vanish.

Lastly, we have finished our branding! Check out the artwork made by programmers:) Credits to Tina.

– Magian

Design

In last week’s blog post we talked mainly about the dilemmas and difficulties of designing a progression system that suits the game’s purpose. We mainly had three problems: the progression system we had last week would impact the fairness of the competition itself, we needed to somehow bind the story and the problems together, and we needed to keep the players in the game for as long as possible.

In last week’s version, we planned the game to be split into 10 days’ worth of content. The player will either need to wait for the following day to progress, or do extra problems to fast forward; after further consideration we thought that this wasn’t fun at all.

If you look at the release schedules for shows on streaming platforms such as Netflix or Amazon Prime, you’ll notice that they’re gradually rolling out changes to these schedules: they no longer release their shows week-by-week, but instead they’d just upload the entire season at once. People don’t like to wait, and why not just let the audience binge when they have the freedom? The same can be said for our game: why not just release all the content at once?

Therefore, we decide to change the idea of “days” into “chapters”, and players will be able to go through the entire story if they’ve done enough problems. But that poses another problem: what if they’re players that just couldn’t figure out the solution?

Last week, the dev team at CyLab gave us two useful items: walkthroughs and tokens. If we can utilize the two in some way, we can make sure that the average player will never be blocked from finishing the game. After a few iterations, this is the current version of our progression system:

>> Story is sliced into chapters, players must solve problems to move forward.
>> If problems are too hard, players can play mini-games to earn extra tokens, which can then be used to buy walkthroughs.
>> Additional mini-games are also unlocked by making progress. Players will not necessarily have to play the same games over and over again.

With the help from our client, this design eliminates almost every of our concern last week, and currently it looks promising; as for the connection between the story and problems, we determined that mini-game wasn’t a good media for conveying complicated computer security knowledge, and we shouldn’t try to do so. As our story already revolves around a hacker, the problems should fit right in without needing big modifications.

After nailing down the progression system, we started to explore possibilities in mini-games. We started out making a big list of simple games, old games or even just concept that we might be able to use in our project; however as we are still not certain how our story will look, this brainstorm session is the only time we allocated this for mini-games, and we expect to come up with more mini-games idea next week, as soon as the story is complete and finalized.

– Brian

Tech

During this week, we’ve been focusing on game-server communication and merging the two prototypes of web overlays and basic movement controls.

We’ve setup a local copy of the picoCTF server for testing purposes, which is identical in function to the real server used in the competition. Because Unity editor isn’t a browser like our target platform, however, we need to simulate functions like login and cookies in order to test without building. So far, we’ve been able to simulate picoCTF’s login process in Unity, and receive questions from the server as well.

The merger of the web overlay and movement & interaction prototypes was a major step forward. Now that we can bring up the overlay and the shell in the context of the game to see how they work together. Additionally, even though we decided use the WASD control scheme, the point-and-click control scheme has been preserved for mobile compatibility. Currently, the shell module doesn’t work well with mobile keyboards, but the picoCTF tech team at CyLab is working on it, so mobile remains a possible target platform.

– Max

Story

This week we showed our treatment and story to faculty. The main point of the faculty feedback was that it was complicated. We might be making something that we would struggle to properly communicate.

Another point was that we should carefully consider our audience. We must cater to their tastes when writing the story and not ourselves or our idea of their tastes, and we would benefit from testing story lines on individuals from our target audience.

Lastly, interestingly, we received feedback from more than one faculty member that the player could play the role of the assisting hacker. We decided to potentially develop this as an alternate story-line to develop. We expect the speed of developing a story to be faster in the future now that we have some main events worked out.

We also had our own internal meeting studying a more finalized version of the story that contains a first draft of the dialogue and all the main events and is expected to work with the progression of the game. We considered writing the story in a screenwriting software, but the benefit of using a plain word document is that the text will eventually be shown in exactly that way, and it’s preferable to be able to see how it will be finally presented to the audience.

We also experimented with using a simple Powerpoint slide to storyboard the opening scene of the story. After internally testing it out, besides minor points of confusion, It’s helpful in setting the mood and demonstrating the format the text will be presented as. Eventually it may be worth it to make a fully story-boarded version of the script.

Our internal feedback identified several points of the story that need to be developed in more detail and several parts of the story that we found interesting that would be worth keeping and polishing.

Several points will need to be further worked on:

>> How and should we work things like game tokens into the story?
>> Better naming for each aspect of the story.
>> More use of the environment in the story.
>> Pacing. Bear in mind that the player controls the pacing with the speed at which they solve the problems. Avoid time-limits and false urgency that don’t make sense if the game does not progress quickly.
>> In addition, we decided to develop treatments (no dialogue, as it is the least relevant to the needs of the art and game design that depends on the story) of alternate story lines within the week.

– Tina

Other things we did in the week:

>> Game hour! Played two board games LOVE LETTER and CV. Also tested Max’s dice game for his Game Design class!

>> Prepared for our production phase. We had a meeting to discuss the scrum method we will use and scheduled our scrum planning meeting on next Monday.
>> Took our team photo, hackman yeah!

For the next week, we’re planning to:

>> Test our story with some middle school students
>> Finish the demo prototype
>> Think about scale and size of objects in the world
>> Make sure art pipeline will work

---