Capstone Reflection – Step 2 Part 2: Choosing The Final Game

Long time, no see! Last week we presented the first part of our jump into developing our final game for the semester, but we were pretty much done with most of the work we had to do. This week we spent our time tying up loose ends and, more importantly, figuring out which game we’d want to move forward with. In this post, it seemed like a good time to talk about how we made our decision and where it is going to lead the team.

During the last sprint, we had a bit of time to iterate upon all three projects as we went to QA test STAGE FIGHT and finish up our documentation in an attempt to close out Step 2. This meant that a lot of my time was spent getting things together for that presentation, including figuring out the best way to go about choosing our final concept. We liked all three of the projects similarly, saw potential in all of them, and got good feedback during testing for them all, so it was sure to be a difficult decision.

The first thing we did was set up some criteria for what we really wanted to rate these concepts in terms of. The first and most important aspect we looked at was what we  could take away for our own portfolios. At the end of the day, Capstone is meant to be a showcase of our interests and skills so that it best shows us off for the jobs we’re interested in. The second aspect was the scope of the game. Our goal is to bring our team forward into second semester, and therefore we need a game perfectly scoped for that two semester timeframe; too underscoped and the game will not have the need to be pushed forward, but too overscoped and we will be setting ourselves up for failure. The final aspect we considered when choosing our game was the game’s actual potential. We had clear interest in all of the games, so we really needed to consider how interesting and impactful the game we move forward with will be. With those in mind, we considered the three prototypes.



Demonstrating the randomly-generated delivery system of picking up an order at one location and dropping it off at another

WITCHCRAFT was a game I had been very interested in from the start due to my love for its inspirations (the film Kiki’s Delivery Service and the games Crazy Taxi and AdVenture Capitalist) and my ability to flex what I’d been learning over the summer about idle games and progression systems. I thought that there weren’t many standout games in either the arcade driving or idle game genres, so I looked into it and found the way they crossed paths to be interesting.

In terms of the team’s interest in the game, a lot of it came down to what systems we could pull experience from for our portfolios. I was interested in the progression and reward systems, Jacob really liked the idea of figuring out the player’s movement, Andrew was intrigued by the challenge of city generation and dynamic loading, and Michelle enjoyed the direction for the art. We also found the game to be pretty unique with a defined core loop that we could work towards.

However, Brett was worried that the game was too out of scope even though I believed it wasn’t. The big thing standing in our way was that the game was difficult to describe, and clearly needed to be proven in order to make sense as a complete package. For example, Andrew had completely been misunderstanding my design behind the game until we had our meeting to discuss which game to move forward with. What was clear and cohesive in my head was not translating to my communication. Therefore, the game seemed much more complicated to the rest of the team. The interest of other people also was a factor, as testers and people hearing the concept seemed to be into it, but no one was head over heels in love with it.



Demonstrating riding on a broomstick and wall riding

BROOMSTICK was a weird idea for us. It clearly stemmed from our interest in witchy flight from WITCHCRAFT, and we all liked playing kart racers so we were interested in what it would take to make one. The game’s value came from its mechanical depth, giving players options and tools to get better at the game with its movement forms and spell/Mana system.

BROOMSTICK’s strengths lied in its potential. The game was simple to understand, a concept/context that interested us, and we knew exactly what we were going to have to make. There was a lot of room for us to be creative and fun, from the track and character design to the different spells and tricks players could pull off. Players/testers really liked what we were doing, as well.

Unfortunately, as development went on, we started to see the holes in the plan. The biggest factor against us was scope: on the surface, it doesn’t seem too bad to make a simple kart racer. However, getting the movement to feel tight and play fun would take a massive amount of time, and getting tracks that make use of that movement would be an even larger time sync. Talking to Brenton Woodward about how his Capstone year had a racing game that only made 4 courses in two semesters with only 1 course feeling good made me very wary. The team, overall, was also less interested in the project because it didn’t have much to pull out of it that we were excited about.



Demonstrating the basic systems of players spawning in, moving the player character and their weapon, and the crowd reacting

STAGE FIGHT came together when I had proposed a random idea for a game where you try to die instead of killing enemies. There were a lot of morbid routes we wanted to avoid with that concept, so we came up with the idea of fake dying, and then that led to playing as actors trying to die to gain the audience’s favor.

There are a lot of things going for STAGE FIGHT. The potential was the obvious standout, as the game puts players in a headspace that very few or no other games can give. Testers had to play a round or two of the game to get their heads out of the idea of killing the enemy, but everyone who played it had a blast with the game’s unique spin. We also felt there was a lot of potential within the theming of the game with overdramatic actors and a bustling, lively crowd. We also found that the team had a lot of room to experiment in areas we were interested in because the game’s core experience could support a lot of additions.

The major downside to the concept was that we weren’t sure about the project’s scope. While the other two games could be overscoped somewhat, STAGE FIGHT had a really great core concept that we weren’t entirely sure the direction of. We had so many ideas, but would they be enough to justify the game being brought into the second semester?

So when looking hard at the three prototypes, it was pretty clear to everyone that we were going to immediately cut BROOMSTICK from the running. The game was an interesting idea and got promising feedback, but the scope issues were a little too much to overlook. In addition, we were all pretty excited about WITCHCRAFT and STAGE FIGHT, so we didn’t feel like we were missing much by letting BROOMSTICK fall to the wayside.

The next thing we did was tackle the two remaining projects from many angles. I wrote up my points of view on the projects from a designer’s point of view, and Andrew did the same from a programmer’s view. As the two of us were the developer of these prototypes, we were able to balance each other out because being that close to a project makes you unable to see the entire picture sometimes.

We then had a meeting where we considered all of those aspects, alongside various other ones like art, market, and general interest. We sat for an hour and a half discussing the pros and cons of each project, the difficulties working in Unreal or on mobile may bring, and trying to make everyone’s voice heard. We essentially boiled the projects down to the following:

  • WITCHCRAFT was a game that we knew the scope of, we could pull a lot of useful experience from, and Michelle had a clear vision for the art direction. However, the game’s concept and vision needed to be proven and it’d pose a formidable challenge to complete. It was a safe game.
  • STAGE FIGHT held a unique concept and context and gave us the chance to progressively build out the project and thus control its scope, but that also ran the risk of the game not coming together or having enough content to carry over into a second semester.

We decided to wait until after QA for STAGE FIGHT to make a full decision, but our plan was to fill out a form anonymously. Instead of just choosing which project we want to work on, which boils down our interests on incomparable games too much, we would have everyone rank their interest in each project from 1-10 and then add all scores together to see which game we’d move onto.

When I brought the game to QA, I saw our expected reaction of everyone playing the game thinking it was an interesting switch-up, and most players played many rounds before moving on. However, a few other designers were there and I got to talking to them about our struggle to decide on a game specifically tied to STAGE FIGHT’s scope. A suggestion that we discussed was that instead of just having a bunch of disparate ideas that we think the game could use, we should look at overall goals to improve the game’s core experience and use that as a way to group those random ideas. That way the ideas have an actual purpose behind them and we can better guide the game along the path we want it.

I told the team this information before we all voted, and it seemed to influence the decision, because STAGE FIGHT’s total score was much higher than WITCHCRAFT’s. In hindsight, we all seemed more interested in STAGE FIGHT from the start simply because of the reception the idea had received, but we needed to define our vision and direction for the game before we could take a leap of faith and throw our safe option out. With that out of the way, the team gravitated towards the project.

So moving into Step 3, we’re getting fully into the development of the game. Now that we aren’t simultaneously making three projects, I’ve taken over the Product Owner role so that we have a clear vision and cohesion behind the development. We have those groupings of features that we will be progressively working on and iterating upon in order to build out the core prototype. I’m excited to finally get production underway, and I’ll be back with an update in a couple weeks (hopefully with more footage to show.)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s