Making A Run For It

Jason Wiles

12/9/13

Professor Scudder

Making A Run For It: A Reflection On How The Escape Came To Be

           Creating The Escape was akin to the classic story of the turtle and the hare, but with one noticeable difference- the hare was on the same team as the turtle. My team, Ouroboros Studios, was victim of its own best qualities. We would switch between two team dynamics: a slow and steady team with no stress and consistent progress, and a quick team with our stress magnified a hundredfold. We would morph into this machine of assets and implementation twice in the year- right after we had our mid term review, and the week before the senior team presentations. The sudden ramping up of production created a strain on the team that was so sudden, it created fractures within our team, fraying our patience with each other and hurting the team as a whole. Thankfully, we normalized quickly, and were able to finish off the year in a solid fashion.

The game itself was created on a whiteboard in the first two weeks. Our process was simple: We made a large list of features and mechanics and tried combining them to create something unique, sound of design, and fun. By picking three items off the list, we could come up with a general idea for a game. For example, by choosing controllers as a control surface, emphasizing a challenging skill level, and melee combat could create a classic arcade fighting game like Mortal Kombat, Street Fighter, or Tekken.  We held brainstorming meetings twice in the first week to look at this list and come up with various ideas. We were able to narrow them down to two: a Team Vs. Team shooting game centered around building and repairing your base and attacking and destroying the enemy base, and a Parkour racing game with effects that would trigger as you stepped over them.

The Team Vs Team game was based off of a combination of the Team Fortress series and the more recent Battlefield games. Team Fortress is known for creating one of the most popular maps ever- 2Fort. This map was the basis of our level design- having two fortresses positioned opposite each other with a no-man’s-land in between the two would create a clear story and a great space for all of our mechanics to be fully experienced by the player. The Battlefield games have a fully destructible environment, so players can shoot walls down to create a pathway that was not there before.

We based the Parkour racing game off of games like Split Second and Mirrors Edge. Split Second had a feature that made players able to trigger the creation of obstacles in a spectacular fashion- while racing down an airstrip, for example, a player could trigger the explosion of the control tower. This feature informed our use of triggers to create obstacles in the map. Mirrors Edge was a single player first person running game where the player could maneuver around the world, watching their arms pump and their legs move while they vaulted over obstacles and leapt from building to building. The experience of moving quickly around the world and creating your own path around the environment was a key touchstone to creating a great experience actually moving around and with creating our levels.

Going through the process of selecting our game’s concept from the list of potential ideas was a very difficult and a surprisingly emotional event. Between deciding which games were out of scope, arguing about the time, resources, and potential of games to move forward, along with balancing your own bias towards ideas you created made this decision a very hard one to make. The worst discussions were over ideas that we brought back into scope by changing the design slightly. I learned how doggedly people would fight for ‘their’ idea, how important saying even just one positive thing about each idea was, and that moving forward is key. We would occasionally revive dead ideas after making statements about a totally different game concept. Insisting that a dead concept stays dead would have saved the entire team a lot of headache and wasted time. But people always want their idea to be the one to move forward. Managing expectations and convincing people to put the group ahead of their own ideas is a key thing to do. We ended up trying the Team Vs. Team and Parkour game concepts, with the Parkour game clearly winning out.

Our QA testing told us a lot about how our game could have been viewed by our target market. Players reported enjoying the game, rating their satisfaction at around 75-85% overall. Improvements to the triggering system were well received, but we clearly needed to develop it further to make it more obvious to players what exactly was happening. However, players enjoyed trying to top their best times and reacted positively whenever a triggered obstacle blocked them, as long as they understood the controls well enough to quickly react and maneuver around the obstacles. When the professors got their hands on our game, however, they reacted with decidedly mixed reviews. The unforgiving nature of the game and the necessity of being quick on the controls caused several professors to give up nearly on the spot. But the few that did stick with it enjoyed their time significantly more than others.

This told us that our game was very difficult to those who were unused to the pace of high skill level games. Casual gamers could be frustrated to the point of disliking the game. We did not anticipate this being such a massive issue for us, to the point of barely considering our title. It puts forward the idea that allowing individual success is a total necessity. We did not design the game to be easy to understand and difficult to master. We designed it to be sink or swim, and it did not cause the players outside of our demographic to like our game very much.

Does this mean that game can fail because they’re too difficult? Perhaps, but probably not. We can look at games in the Kingdom Hearts series, which start with an hour long tutorial area. Those games have moved large amounts of units, and they hold the players hand constantly. But we can look at games like Dark Souls- a punishingly difficult game that encourage learning through repeated failure- which have sold millions of copies because of their unique difficulty. In the Champlain environment, perhaps we should have been closer to Kingdom Hearts. But through Dark Souls, we can see the shared values- that difficulty breeds fun- can sell well too. It’s a rough line to walk, but difficulty can create a successful game. What Dark Souls does so well, however, is put the character back in the game quickly, with the same chances they had of succeeding as before, but with more knowledge moving forward, knowledge that can lead to winning the challenge set before them. By implementing a quicker demo level, maybe our game would have moved forward.

The actual tech and design of the game were not within my areas of expertise, as I am a game producer and only educated in project management, marketing, and business administration. I was more interested in the target market and how our game tested with potential consumers, and my expertise in the implementation of tech and design is minimal. As such, my input here will be brief. We were aiming for a competitive experience, one where skill is rewarded with better times and therefore more success. We implemented a leaderboard feature that would track the time of the player and their competitors and display them side by side. We hoped to improve engagement and competitiveness between players, and we saw that it did- testers would visibly react if they won and a fair amount of trash talking was exchanged during QA sessions, especially over best times.

I learned that while the ideas of the game may be apparent to the designers, the player will need and want as many systems to improve their experience as possible. While the leaderboard itself was a fantastic addition, the addition of a guiding arrow or icons that helped the player get a better idea of the trigger system would have improved enjoyability as well. Many of the professors were getting lost in our corridors, and an arrow to guide them would have probably gotten them to stay and play. If we could have had a system that clearly indicated where and how triggers would impact the environment, the blocking effect would become both immediately apparent and useful. For example, if we placed a button with a comedic icon of a bridge opening up and depositing a stick figure that used to be running over it, it would be quite obvious that the player should press it when another player was on the bridge ahead of them. Players are not stupid, but players do need some basic guidance to grasp the game.

This whole project was a learning experience for me. I learned what it was like to have a member who constantly acted as a devil’s advocate, but to the detriment of the team. I learned lessons on how to effectively set up and give a demo (note to self, turn on the sound before demoing your game, and don’t make demo players feel like children). But what did I learn about myself? I tried to give my teammates the least stressful time they could have doing this capstone. I set goals too low and was happy with any progress, refusing to inspire my team to create more assets, refusing to push my team members. We became complacent and only created the bare minimum to reach our goals, and in longer time than would be optimal. Because of this, we sacrificed production for less stress. I should have pushed my members further, as this class did not require much time at all from any member. My emphasis on having an easy time is a great management tool, but only when the team is producing. I need to balance my desire to create a stress free environment with actual results. I learned that I need to think outside the box then it comes to my responsibilities. I could have created marketing materials, I could have made various elevator pitches, and these would have upped my low hours spent managing, making a marketing plan, and creating QA materials that I handed out and studied during and after testing sessions. I’ve grown from this experience and look forward to implementing what bits of knowledge I’ve grasped in the future.