Senior Capstone Project

At Full Sail University, the game design students are given the opportunity to pitch and create their own game with a small team over a short period. In our case we had a team of four designers and four months. While my own pitch of Steam Engine was approved (which you can also view here) the team I assembled chose to work on a fellow student's pitch for a third person adventure puzzle game with some interesting mechanics and level design challenges. The Museum was born from this. I'm going to sit down and do a small post-mortem on the project, talk a bit about the game itself, to demonstrate what went right, what went wrong, and what was learned from the experience.

The Game

We created a 3D puzzle adventure game, but instead of third person like we originally planned, it became first person due to technology pushing us in that direction. Clipping in dungeons and tight spaces that might make up some of our levels made the third person camera much much harder to create in a technical way.

We created traps and interactions within the game via a series of test levels and playgrounds. We attempted to find what worked well and what felt fun and interesting. Some of these were cut for technology reasons, some simply just didn't feel good. However, all of these were crucial when it came time to design the levels themselves.

I personally touched quite a few parts of the design and documentation, but I would say that my biggest piece of work was in systems and level design. I spent a lot of time making the various interactions in the game talk to one another, the enemies, and the players as needed. Some examples of this were a series of disappearing walls and traps that would appear or disappear based on distance from the player or other interactions. You could make them appear through other means such as shooting an arrow at them to make it visible for a short time. As well, I tested some other mechanics like a chasing boulder system that would follow the player through an area with a rubber-banded feature so that you could not outrun it too much. It would speed up the farther away you were from it.

Our Egyptian level was my primary level design focus. With a (nearly) blinding sandstorm in the intro, to maneuvering lights and mirrors to complete puzzles, as well as a small maze involving those disappearing walls, the major theme of my level was light and visibility. I enjoyed work on it immensely, even if I wasn't quite able to get all of the features and ideas I wanted implemented in the time I had available to me.

What went right

For the most part, the strongest element of the team was our willingness to roll with the punches. We met several major setbacks and challenges along the way in the project. However, we made every effort to proceed with the game in as close a form to the original pitch as possible. Several of our fellow teams met similar challenges and instead opted to rework their games. I am not necessarily saying that our choice was the superior one, but I believe that the desire to stay as true to the spirit of the pitch as possible is important in game design. Change is good, change to avoid having to come up with a more creative solution is not.

That being said, we also knew when to pull the trigger and put an idea aside. We did cut several features as needed. The biggest was probably the third character's weapon. Originally it was going to be a whip to allow for movement and traversal as well as trap interactions. However, after several weeks of development time, we hadn't achieved a prototype we were happy with so we cut the system. This hurt as we really wanted that style and flow in the game, but we split the sword and shield into two separate power sets.

Beyond that, we as a team also had good cohesion and communication. With a few exceptions we avoided any major foul ups by making sure we kept each other abreast of what we were working on, why, how, etc. We held regular meetings and updates to assess what needed work, what was progressing well and what needed more love and care from the team.

What went wrong

Being perfectly frank, we did have our fair share of difficulties. No project avoids them entirely. We did our best to make our code as robust as possible and make sure that it worked. This didn't always work as intended. Especially with different coding styles sometimes overlapping and butting heads. We should have made more extensive use of state machine logic within our original design, which cost us development time all the way up to the final weeks of design and implementation.

As well, we were over scoped at the beginning of the project. We of course didn't realize it at the time. Had some of  the technologies such as the whip come together easier (or at all) we might have been fine, but when developing ideas that haven't been put in engine by any of the designers to that point, time projections rapidly spiral out of control. 

We did have some scheduling and time management issues as well. While we did a good job communicating in general, scheduling times for team work sessions and having the entire team present was difficult at times. Bearing in mind we all have lives outside of school, this lessens the blow, but it was still effectively our job for four months. Forty plus hours a week with weekly sprints due for review and critique. We needed to do better with our timing and especially when it came to build time. I was in charge of builds. As team lead I felt that the buck stopped here, if it wasn't working or something went wrong, it was on me in the build to set it as right as I could. This sometimes caused some extra time to need to be put in at the last minute. As the project went on this happened less and less, but it was still critical to spend more time testing the build than we usually had available at the end of the week.

Lastly is a personal thing. While I feel I did a good job as a team leader guiding the project to completion, I know I could have done better in a few core areas. My own personality tends to get a bit on edge when a major deadline is coming. If everything's ok, it's all good, but if not, I do tend to come down on little problems that are causing the group problems. I could project that a bit better. As well, being firmer with due dates and work load expectations. I frequently let things slide when they were needed for a milestone or sprint and would take more onto my plate, or come up with a temporary solution/work around. This wasn't good for the team in the long run because it fostered an attitude of "We can hit that next week" which really started coming back to bite us in the last few weeks.

Lastly... We had a hurricane. In the middle of our second development month. That didn't help.