Hey! So, time runs really fast. In week 4 we finished our pre-production (in a certain level), and in week 5, we started our production phase. We planned out several sprints in the early production, and each of them contains around 8~10 working day. Week 5 and 6 is for the first sprint, please see more details below:

Production

The most important part of a sprint is a clear goal. With the goal in mind, we can be clear about the direction, know how far are we in the progress, and see the rights and wrongs. So the first thing we did for the week is defining the sprint goal.

We started with a production planning meeting. In that initial meeting, we talked about all our thoughts in mind about the games we have developed so far, and listed out everything we thought we should make in the game in user story format, and lastly prioritized them.

Then the top user stories will be what we will make in the first sprint. With the practice in the past weeks, we tried to estimate our capacity and pulled out the first two user stories: Navigation and Problem Solving. Then all team members wrote tasks for themselves.

With all above done, we had a good start. However, before a rough playable demo was built, team members still had different visions and expectations about it. What we did that helped was having a lot of individual conversations between each pair of us, so that the big picture got pieced together. We will continue doing that in the next week and make a clear list of functions with our shared vision.

– Magian

Design

Last week, we’ve finalized the game’s progression system. This week we’ve been working concurrently on several different aspects of the game: level design, mini-games and implementation.

For level design, we started by assessing how many rooms we will need — after all, time is a resource that we don’t have much. Our predictions landed at 18 ~ 30 rooms, which were all too much. We then focused on the most basic functionality of each rooms. Currently every room’s purpose was to present a single problem to the player. What if we merged many rooms together and make a whole room with several computers?

This solution led us to a basic total of 9 rooms, which is significantly less than what we had in mind before. Then after a few playtesting in the minds, we feel that it could be very frustrating for the players to walk around the room all the time just to solve one problem, and plus the computers are too small on the screen to provide any detail. Therefore we merged all the problems onto one computer, and that computer contains a list of the problems under a certain category. Since this is a dream world, we plan to make each room drastically different from each other. We plan to deliberately cause confusion to the players to reinforce the setting.

Like the rooms, we couldn’t afford having too many rooms just for mini-games. We started out listing out 25 random game ideas. Then as we designed the world, we came up with four additional ideas which sounded promising to the world; moreover, these mini-games don’t need their own rooms — they can be played in the main factory room.

– Brian

Tech

This week, we’ve been working on completing the question answering system. The first step was to add an input field and send the question to the server. There’s little difficulty making it work in Unity, as the code to send requests to the server is already there and all that’s needed is to handle the response to the answer.

However, it was more complicated to deploy it on the browser, as the response headers can’t be manually changed the way it’s done in Unity, and the web page has to be under the server’s domain to share the login credentials. It was a challenge as the server is hosted in a virtual machine managed by Vagrant, but after consulting the picoCTF tech team, we learned that it’s possible to set up a shared folder between the host and the virtual machine, and got the game up and running under our local picoCTF server.

The other task we worked on was control optimization. The keyboard navigation was based on physics and had noticeable acceleration and deceleration issues. It was revamped to replace the physics parts of the code with direct movement, and now it’s much smoother and responsive. We’ve also changed the camera from being fixed at the center of a room to following the player, as the rooms we’ve designed are much larger than what can reasonably fit in a single view.

– Max

Story

This week, with the advice of faculty, we changed tactics with our writing process to become more productive.

>> We converted the story from a script to bullet points of story beats that can easily be tested, described to people for testing, and rearranged

>> We built in questions that should stay in the player’s mind after each section of the story so that they are curious about the next part

>> We aim to better prepare the story for future playtesting and presenting

>> We prepared a continuously updated Glossary so that anyone in the team can easily look up canonical facts and clear up points of confusion for the story line

>> We experimentally prepared a document with storyline developments (like a software development branch) so that the whole team can look at story points in development that are not in the current draft of the story yet

>> We came up with a simple versioning scheme for the story, our main storyline is A# where # is the number of revisions, and additional alternative versions are B, C, D and so on.

>> We think this is a good time to re-articulate the goals of the story:

Maintain player interest in the competition
Convey a sense of mystery
Steer clear of sensitive subjects and controversy
Integrate well with the competition problems and format
Integrate well with game design, game progression, and mini-games
And a reiteration of the specific story format we are trying to use to achieve our goals:

>> There should approximately 10 main chapters, each as an award for player score milestones|
>> The chapters are presented linearly and do not depend on order of questions answered
>> The chapters are delivered in unexpected ways, partly by inserting after questions are answered as the speech of a hacker trying to reach the player
>> The events in the story should encourage the player to explore the world of the game
>> The climax occurs at our goal for the number of problems we want the players to solve. After that, the game is considered ended, and additional problems are rewarded with a simple epilogue.
>> Between chapters there are small dialogue and other story rewards that do not interfere with the main events if skipped
>> The problems are themed to integrate with the context of the story; the theming of the problems should be easy to do and should not depend on the order the problems are solved

– Tina

Art

We started on the concept art and the tile art for the main room of our game!

Our goals for the art:

>> We want to serve the story and the mood we want the player to have while playing the game – a sense of mystery and interest
>> We want our colors to help the user interactions be straightforward
>> We want to be programmer friendly: we will use version control and provide consistently-named assets to the programmers; we also want to test the effect of the art as much as possible before sending out the asset
>> We decided early on that we would be drawing mainly in a pixel art style, a relatively simple and manageable method for first time artists; also will result in small file sizes for our final build
>> We should bear in mind that we are inexperienced artists (we all have tech backgrounds) and often ask for advice, opinion and find references.

Concept art development process:

>> We consulted photographs we considered had the right atmosphere to select a suitable color palette.

>> We chose something that would suggest mystery, history and age, and would hopefully work well with lighting in Unity.

>> At the suggestion of the game development team we took into account using colors to indicate boundaries and intractability to the player

Tile art development process:

>> We made tile art with the concept art in mind so that we had a goal for the look and feel of the end result
>> We researched best practices for pixel art. There are specific ways of line drawing and shading in pixel art that looks good.
>> There are software specifically made for making tiles and pixel art but we chose Photoshop as the software we will mainly be using because of its familiarity to us and its flexibility (we may need other, non-pixel art for the game), and it’s helpful and simple to have all our files in one place, and in a format we can easily share with other teams without additional conversion. We made adjustments to Photoshop’s settings to allow for easy drawing of pixel art.
>> Tiles are drawn separately. We needed a method to rapidly check if our tiles work together as we draw them. We set up Photoshop with smart objects so that the effects of tiles can be tested and this method doubles as a way to make tiles into a sprite sheet without needing to manually arrange the tiles each time.

– Tina

Other things we did in the week:

>> We attended the award ceremony of picoCTF 2018! Had a chance to talk with last year’s winners. And really got some interesting feedback about previous games, and we hope we can have them help us test the game out!

>> Game hour! Brian brought a great movie The Bold, The Corrupt And The Beautiful.

For the next week, we’re planning to:

>> Playtest story with some target audience (already scheduled)

>> Integrate previous tech, design and art into 1st playable prototype

>> Complete the development of art pipeline

>> Think of ways to better demonstrate our design to other people

---