Capstone Reflection – Step 2 Part 1: Rapid Prototyping

Two sprints later, I would argue that Action Cactus (our team) is in a much different place than we were last time I reflected! Step 2 for our Capstone could essentially be boiled down to “rapidly prototype and explore three concepts in all facets to iterate and decide where the team wants to go.” While we aren’t out of the second step just yet (we plan to make this current sprint our last one for the step), we figured we would present our progress in order to gain some immediate feedback on where we were going with things and to cut down on the information we’d need to present the next time. So why don’t we talk about the process we went through to make it this far?

When we exited Step 1, we ended up being in a fairly advantageous position compared to other teams because our team’s composition and skillset aligned perfectly with a strange idea: prototype all three games simultaneously. Jacob and Andrew are both incredibly capable programmers who know how to make a quick and dirty prototype, which is exactly what we needed in this stage. In addition, I have a programming minor and love to be involved in the pipeline of design to implementation. The three of us also ended up being drawn to facets of a specific prototype, so it made perfect sense to each focus our time on a project. Our thoughts behind this were that most teams would be spending a week or two on each prototype, but we wanted to have as much time for our final prototype as possible without sacrificing that crucial iteration time, so by giving ourselves two weeks to develop all prototypes simultaneously and then spend a third week testing and iterating, we would be able to make the best use of our time.

While the prototypes were all worked on simultaneously, the actual creative thought processes and research we had to do for the projects were to be done on a weekly basis. All of the design documentation, art direction exploration, market research, and technical risk assessment have been progressing at a pace of one prototype a week, so by the time we finish the third sprint all of that work will have been completed.

This was setting ourselves up for a much different challenge. For one thing, because we were split with the prototypes, we had to maintain constant updates and communication about the progress we were making so that no one was left behind. It was also interesting to balance the overall prototype schedule versus the weekly research schedule, as progress on the prototypes was not being done uniformly, so our overall view of each concept had the potential to be skewed. However, this never became an issue.

The one area that I disliked, though, was that because we were not all working on the same project at once, the three of us were only experiencing individualized problems and we all became attached to the work we were doing. We’ve had preliminary discussions about what project we’d like to move forward with, and those discussions have had some biased opinions based on who has spent the most time on one project. Someone being an expert on a project can be helpful, but when they’re the only one working on it, it becomes difficult to look critically at it. Luckily, each prototype has 4 people to look at it objectively, so it hasn’t been an actual issue for us!

So with the three prototypes, which I described a bit in my last post, Andrew really enjoyed the arcady feel and multiplayer aspect of STAGE FIGHT (the theatrical combat party game), Jacob wanted to experiment with different types of broomstick flight for BROOMSTICK (the kart racer), and I had already spent the summer building the WITCHCRAFT prototype as a way to learn Unreal. This made the split natural, and being able to just add a few features to my prototype allowed me to spend the rest of my time on doing the design and QA work for all of the projects.

When we sat down going into Step 2, we knew we needed to make the most out of our limited time, so we had a meeting to just boil the concepts down to the absolute core of what we needed to test our player experience and get the main idea across to do some focus testing. A lot of WITCHCRAFT’s systems were already in place from my work over the summer, and all I needed to add were some features like a timer and money system to get the major point of the game across, which was to be setting up deliveries and then navigating the city using the arcady controls to perform the deliveries. For BROOMSTICK, Jacob really just had to focus on experimenting with different decent-feeling broomstick movement that we could test because it was the natural start to a movement-based game about mastery. Finally, Andrew had to set up some basic character movement with multi-directional weapon control and the base rules of winning when touching the enemy’s weapon and having the crowd react to the fight.

I added the timer and money features to the WITCHCRAFT prototype during Sprint 2 so that I could bring the build to QA during Sprint 3. I knew that the game needed a bit of design iteration because it felt like it was missing something, so I wanted to have the time to get testers’ opinions and work off of that. We asked a lot of questions in regards to what aspects people like and what felt missing, and the two biggest pieces of info we got were that players could easily see themselves playing the game on mobile and the game needed to have ways to vary the gameplay beyond deliveries. While the former piece of info was a very simple choice of choosing to target a mobile release, the latter was a more complex issue.

Already in the works was a system where players would help pedestrians on the side of the road in exchange for new spells, areas to explore, and employees that would help the business make more money. What made sense here was to take a Spider-Man (PS4) approach and make the game’s core focus be on the movement systems in the game, and have those pedestrian side quests be non-delivery tasks that test the player’s movement skills, such as chasing something down or getting a certain amount of airtime within view of the pedestrian. I also considered, seeing as the game already has a very mobile-centric structure, adding daily goals for the player that will be along the lines of “Perform 5 deliveries in the Eastern District” or “Make x amount of money in one day.” These would definitely incentivize players to play differently and keep them engaged.

As for the QA that I analyzed for BROOMSTICK, two pieces of data also stuck out most. First, we were considering making the game mobile-focused as we don’t know many kart racers on mobile, but players didn’t seem to want that. Secondly was the fact that players liked the idea of having the ability to switch between different movement forms for different reasons. This is something we hadn’t actually considered, but we as a team really liked the idea and found it helped us figure out another way to make the game stand out from the competition.

This upcoming sprint, we are going to be QA testing STAGE FIGHT and making a final decision on what game we’d like to move forward with. In addition, we as a team are going to tie up all of that documentation and research that we’ve been doing in hopes of moving on to Step 3. I’m extremely excited to see what we learn from that test session, as right now I personally enjoy all three concepts and don’t have any clear front-runner in sight. See you in a week!

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 )

Facebook photo

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

Connecting to %s