MasterKey is the capstone game I've been working on at FIEA with a team of 17, currently acting as project manager. In Review is a chance to take a closer look at some of the work I've been doing and discuss what I've learned.

FIEA Status Updates

To begin with, at FIEA we present biweekly status updates for our capstone projects to show the faculty and fellow students our progress and get feedback. We also get "funding" based on how well the faculty thinks we are doing, so a lot of work goes into presenting our game as best as possible.

With the framework given to us, there are plenty of considerations we've put time into investigating. These include questions like: what is the most important thing we want to convey with our update. whats the best way to present this content and how best can we use our feedback.

The Presentation

In our earliest updates, the main focus was to present as much information as possible. Every art asset, concept, programming and game play feature. While it was a great way to show we were doing a lot of work, we weren't telling enough of a story. For one of our presentation rehearsals our faculty adviser told us that we need to tell the game developer story, more than just assets, tell us how you got to where you are and where you are going with it. This is something we took moving forward and it has done really well for us.

We also realized that to present our game well on presentation day we would really need to rehearse. Our faculty adviser has witnessed more than one game play demo from us where we definitely had room for improving the flow of it. Since we present as a duo, with a speaker and a game player, we also realized we need to have a better scripted out presentation. Knowing when to pause during the playing, when to look around in-game, perform actions, and what to point out on screen are all things we focus on improving every time.

What We Learned

We've also learned a good amount of what works and what doesn't work as well throughout the process. I'll cover a few of the things that were received well, as well as some of the times where we didn't quite hit the mark.

Hit the Mark

Setting goals for what you will have for the next update. This helps give everyone an idea of where we are going, and allows them to see the progress. This also gives a better idea of when to show bigger development stories, like saving concept art that is already done for the next update where it will make more sense.
Owning up to our mistakes. This follows along with setting goals. When we showed what we did and didn't do in our second update, the faculty we're more impressed with us for being honest about what we didn't complete. This also allowed us to get better feedback.
Showing the big picture schedule. One of the biggest concerns with the faculty is trying to make sure our teams are planning ahead far enough to keep the big picture in scope. Nothing says it better than showing the schedule (it also helps them spot potential issues down the road!).
Before and After pictures are great. One of the best ways of showing our progress has come in showing our greybox levels switch to the same shot filled with our art assets. That gets us more than a few "wow" reactions.
Well structured presentation. This is a no-brainer, but goes back to telling the game dev story well. We realized instead of focusing on just showing tons of work, we should focus more on structure so that we can give the listener a clear idea of what went into the past few weeks work.

Missed the Mark

Presenting an update heavily focused on background work. One of our sprints that happened over a few weeks with a break in-between we decided to focus heavily on improving our processes, pipelines, and teamwork. While we felt it was really valuable, and we put in a lot of work, we weren't able to present these developments well enough.
- Solution: After looking back at the presentation and the feedback we got, the problem was in not convincing people that it was more important than in-engine work. To do this we should have better described the time being lost to the inefficiencies in our pipelines and processes.
Terminology can distract greatly. One example of where this got us was when we called our introduction level that had simple mechanics and story as our "tutorial" level. Once we said that it was a tutorial, most people instantly got the wrong idea. We also learned to be careful of saying what is a "proxy" or "prototype" and what is a finalized design.
- Solution: Keeping a better ear out for the terminolgy we use, as well as quickly correcting the terms. It is really obvious that getting ahead of this helps when team members still sometimes refer to our intro level as the "tutorial".

In Review

Looking back I find it funny how much work I thought it was to do a 5 minute presentation for classes in undergrad. Seeing the progress we've made in our status updates up to now makes me really happy in my team. It is also exciting to see how much better we can do later next semester. I've also gained a new confidence in presenting and taking steps towards being the member of the team who can convey the full development story.

Note- All of the Vertical Slice Presentations for our cohort were recorded and streamed live, if you want to check out ours, here is a link. https://youtu.be/gptMCkXAUNA?t=4737

The 10s Square

To start, lets explain what a "10 second square" is in this context. As it was described to me, it is, "A section of your level that takes 10 seconds of movement to cross". For us on MasterKey, our first 10s square is our Vertical Slice Art Target we recently presented pictured below.

The next question is, what are we going to do with this 10s square? The goal of the exercise is to break down exactly what it takes to make 10 seconds of level, from the earliest concepts to the final touches. With this information, I can now begin making predictions on how much content can be produced in the remaining schedule. In other words, the 10s square is a tool to help define scope.

The Data

Now that I had the area and contents clearly defined I broke down the tasks completed to create it all. I wanted to figure out a few things: how many manhours to create this 10s square, how long is the critical path, and how can it be scaled.

The first step was simply looking through our completed tasks on JIRA and getting the hours worked for each. The total time required for our first 10s square was 129.5 hours of work, with the vast majority being creating new art assets. Thankfully, a lot of these art assets were built to be re-usable so I broke down three categories for 10s squares. The first being a square with full original assets, the second being a square with some new assets (perhaps a set piece), and finally being a section where theres no new art assets, only placing them.

The Scope

Having broken down the 10s square into three scalings, the final step was figuring out what this data means for our scope. Keeping in mind we have a final presentation for MasterKey at the beginning of August, our goal is to have around 13 weeks of production, and leave several weeks for Alpha and Beta fixing. To figure out how fast each 10s square can be made, I looked at the critical path of development, ending up with something like this below.

Looking at the breakdown, for a 10s square with full assets, it takes at a minimum a week and a half. That ends up being pretty unwieldy, so fortunately the majority of our squares will be sections without new assets, taking only 20 hours total. With our team composition we are able to create three of these squares a week, allowing for about 7 minutes of pure movement at a maximum.

I would like to note here that before gathering the data I decided I would interpret these initial numbers with a grain of salt. The main considerations being: some rework will come in (currently looking at 3 additional hours of critical path for full art areas), and the idea that we should be improving our pace as we go and get more comfortable with the process.

In Review

For me, this is a tool that I find really helpful in visualizing how big MasterKey can be. This information will be continually built up with future 10s squares we develop, but it is already helping us plan out our schedule. I'm really interested in comparing the final measurements at the end of the project with these initial ones.