2plicity

2plicity

Summary: 2plicity is a co-op puzzle game where one player (the Agent) uses parkour platforming and a grapple hook to navigate an underground facility in first person view while the other (the Ops) uses cameras and maps to get an overview of the area, manipulate platforms for navigation, and communicate the shortest route to a destination. The game was born of a desire to have two players work together to accomplish the same goal through radically different means, allowing players who enjoy different types of gameplay to play together.

Team Members: The team, Strawberry Turtles, expanded to include eleven people:

  • Kai Godfrey, designer & team leader
  • Sarah Weber, lead designer
  • Tim Seyfert, producer & programmer
  • William Tingley, lead programmer
  • Morgan Hooley, programmer
  • Tyler Bolster, lead artist
  • George Foss, artist

Platform: PC. Made using Unreal Engine 4.

Project Timeline: Jan. 16 - May 2, 2017; 13 one-week sprints (participated beginning Feb. 21; 8 sprints)

    Hours Worked: 65 hours (24 production, 19 programming, 13 testing, 5 design); project total 794 hours

     
    2plicity_QA.jpg

    Contributions: 

    I had three major roles: producer, QA liaison, and programmer.

    This team was one of a handful that advanced past our junior year production midterms. As teams picked up members of teams that had been disbanded, Mean Crystalline Machine approached me for my organizational skills and ability to keep a team on task. My tasks here included organizing, leading, and logging meetings, maintaining daily communication, and keeping our team's redmine project page and wiki up to date and useful to both team members and superiors.

    As QA liaison, I was responsible for the majority of QA-related tasks. I signed up for, attended, and summarized QA sessions on a weekly basis. In signing up for QA, I was responsible for both our test plan (explaining the what, why, and how of our test session) and our feedback forms. In this semester I learned a lot about what questions to ask testers, how to phrase them so as to receive informative answers, and how to summarize data visually so the team can interpret those answers easily.

     

     
    2plicity_shaders.png

    Finally, as a programmer, I helped implement features where I could. Much of our programming problems came from networking issues, which I couldn't contribute to; however, I was able to implement shaders to make important game objects stand out, and force them to only show on one player's screen. Though we expected this to be a minor role, it ended up taking a lot of my time to complete to a satisfactory level.

    I performed this work while also maintaining duties as a lead producer for my section of production, and acting as a point of contact for all groups to solve impediments and facilitate communication between producers and executive producers.

     
    2plicity_context.jpg

    Game Context: You and a friend play as a duo of spies and have been hired to investigate Victipede Industries. VI has recently publicized that they are mining for the greater good, but suspicious activities have led people to believe otherwise.

    However, Victipede Industries has found out about your company’s activities and has started destroying their facility. They are using their high-tech robotics systems to break off the mining areas and cause them to fall into the Earth’s core.

    You and your friend must work as a team and play as an agent or an ops specialist, and will travel up through VI's underground mining facilities to search for incriminating documents and learn the truth about VI and their plans, before the robots destroy them all!

     

    Postmortem: I particularly enjoyed working on 2plicity, and I think the final product was fun. However, it's lacking in several areas.

    2plicity did not go as far as any of us wanted, and the major reason for that was the game's scope. The team did not realize that one of our programmers would become a dedicated networking programmer until we were past the point of no return. This limited how many features we could feasibly implement and debug.

    We also underestimated the scope of making a parkour platformer. As Kai had the most experience with making movement feel good, we assigned him most of the level design work and movement tweaks. But, as we learned, a large part of making movement feel good is making it sustainable, which in turn meant designing a large level. The size of the level meant we spent several times longer on it than anticipated.

    The final issue we struggled with was what we dubbed "the Player 2 problem". While the Agent had a lot of fun running around a beautiful level, making precise jumps, and grappling around pitfalls and laser sensors, the Ops mostly just watched the Agent have fun, and sometimes pointed out which way they should go to have fun or opened a panel so they could have fun. This even got to the point where in the final week, as we were applying post-processing to the build, we forgot to implement it for the Ops. In short, we never nailed down the design for the Ops player, and their gameplay feels lacking.