Introduction and overview of the project

Dark Clutches is a student pitch project developing the next evolution of tablet gaming. Our game combines aspects of classic 2D platformers and intuitive gesture controls to create highly cooperative multiplayer gameplay. Two players will band together to explore a hidden dragon temple where they find relics from the past that allow them to alter the game world.

Our goal was to bridge the gap between console and mobile games. We did this by blending local multiplayer and dedicated play sessions with the intuitive interfaces of touch devices. While our primary platform is the iPad, we are taking advantage of an increasingly interconnected world and providing cross platform play between an iPad and a home computer.

Our final deliverable will be a short playable demo to showcase our experimental gameplay.

The Dark Clutches Team consists of Carey Davenport, Ryan Hall, Noreen Durkin, Prateek Gudihal and Peter Kinney.

Production

What went well

1.  Pre-Production

There many things that went well for production on this project.  The first thing that we did was take Entertainment Design Studio as a team.  It was there that we laid the foundation for the semester by completing a huge chunk of work including a networked prototype that could demonstrate drawing and pinging, a vast array of 2D and 3D art assets, a short sample of music, a rough schedule, the acquisition of JIRA for task management, and the team buy-in of using daily stand-up meetings in conjunction with a physical scrum board.

2.  Opening Our Project to the Masses

Another production strategy that worked well for us was the scheduling of faculty to come in every Friday.  We didn’t have faculty come in every single Friday but more often than not we did bring in focused faculty feedback.  In particular, very early in weeks 1 and 2 we brought in Shirley Yee to give feedback on the Visual style of our branding.  Her expertise was exactly what was needed in those first four weeks.  We also pulled in MK Haley by setting up Skype meetings.  She gave us invaluable advice in regards to staying on track early and throughout the semester as well.  Midway into the semester we were struggling with story and used Brenda Harger who suggested that we use story splines in order to find gaps.  We brought Jesse Schell into the room on two occasions to get feedback on gameplay and control schemes.  Finally we met with our advisor Chris Klug on a regular basis who also provided gameplay and control scheme feedback.

Having Jason Vandenberghe of Ubisoft as our External Advisor was another aspect that worked extremely well for us.  In total we had 4 Skype meetings and 1 in person meeting while attending GDC.  His feedback came at the right time for us and after each meeting the project came out stronger than before.

Early on we decided to have what we called an “Open House.”  3 of these events were scheduled where we invited the entire Entertainment Technology Center (ETC) to come and play our game at different stages of development.  The feedback we received from these allowed us to filter the great feedback and funnel the good stuff directly into design.  These were perfect for putting an end to debates or just seeing if our control schemes were liked or not.

The last part of this segment lies in that we called upon a focused set of people to give us design feedback.  We asked for designers that we really respected here at the ETC and wanted them to give us pointed feedback on controls and gameplay.  The final outcome is what you can play today and we happen to think it is pretty darn fun!

3.  Task Management and Daily Meetings

Some teams may dread using task management software.  However with my (Carey) experience and enthusiasm for JIRA I was able to sell this strategy to my team.  We used a system that I borrowed from Gearbox Software.  I would create “Mastertasks” for major milestones or tasks and then we would “Subtask” smaller portions of that larger idea out to individuals or groups of individuals.  This was used in conjunction with a physical scrum board.  Every day at 5pm we would stand up and do our daily meeting.  I would bring up tasks that had been sitting in JIRA for too long or ask if we needed new tasks.  As a producer, daily meetings were the bomb!  If I had nothing on my plate I could ask my team where did we need help and I would focus fire on that particular problem that needed attention whether it was 2D art, Unwrapping, Implementation or creating sound.  Ryan stated several times throughout the semester that production for the team in general went down with each day that we missed our daily scrum.  The daily scrum really kept communication lines open and it kept the team focused on the most important tasks at hand.  I only wished I had learned about KanBan before GDC!  If you don’t know about it go learn it because it could serve ETC projects quite exquisitely.  Go here for more info on Kanban: http://blog.agilegamedevelopment.com/2013/04/mixed-asset-production-pipelines-kanban.html

4.  Project Scope

Early in the project during pre-production we decided that we were only going to create a vertical slice.  This relieved so much pressure to create an entire game and I would recommend any game project at the ETC take this route.  We agreed to complete 2 levels (whatever that means) and just a small slice of what the bigger game would look like.  However, this scoping was still very large and we had to kill a lot of creeper features in order to stay in scope.  Midway through the project we identified a handful of such creepers and promptly destroyed them the following week..

What went wrong?

1.  Missing Daily Meetings

Prior commitments like weddings, family vacations, being Head Teaching Assistants (TA’s), and one spectacular dude being part of a company led to our team having dry spells of communication.  These are the days that Ryan referred to when he mentioned the absence of daily meetings and it’s relation to general productivity.  The use of JIRA and meetings before these dry spells lessened the blow but there were definite consequences that are unavoidable when communication becomes blocked.

There were times where I was so focused on tasks that needed completed that I failed to upkeep our board.  This led to team members coming up with their own tasks that they prioritized.  Lucky for me, this team was awesome at tasking themselves.  Even though they found tasks that were pertinent and deserving of attention, they didn’t always have priority in the order of completion that was needed.  Again this goes back to missing daily meetings.

2.  To Be Collaborative or Authoritative?

Having worked with this team before I knew that a collaborative stance would work very well.  There were times that I felt that I could have leaned a little more authoritative though.  It didn’t happen often but I think at critical times I could have imposed mandatory hours for the team to be in the building.  I also felt that there were time that I should have pulled the plug on iteration but I let it linger.  In retrospect, things turned out well like they always have for this team just in the nick of time.

Lessons learned and conclusion

What I learned in terms of production is that setting up milestones and creating a rough schedule should be done before any development has started.  However, a producer should be flexible in that schedule (considering the obsessive compulsive nature of a producer).  Producers should also identify when testing is needed and enact a plan for that testing to occur.  The testing should be done when the team will be the least interrupted during the development cycle.  That moment usually comes if the team gets stuck in a creative rut or there are a lot of bugs to work out.  When the team is developing, they should be meeting every day for a stand up meeting.  This keeps the team organized and efficient by reducing unprioritized tasks.  Task management software can help here but it isn’t a definite fix for maintaining communication.  Finally, a producer should know when to strike a balance between collaborative and authoritative stances.  Developing your collaborative skill builds respect with team mates and when the time arises they will respond more to the authoritative requests.

Tech/Programming

What went well

1. Unity is Fast

Our use of the Unity 3D game engine worked out really well for us because it let us develop and test very quickly do to all of the built in tools. The interface also makes it easy for anyone to use, even if they’re not comfortable with code, which made it easier to distribute the end of the pipeline.

2. Tools

We knew that we wanted to everyone to be able to contribute to the end project, rather than just creating assets and waiting for the programmers to implement them. To this end we created a set of tools that anyone could use. These relied heavily on the unity interface, but we had to make sure that everything was simple to use.

3. Source Management

The unity asset server is super convenient for sharing files in unity on a small team, but it makes it horrifyingly easy to lose work because more than one person has been modifying the same file/asset. We did a pretty good job of avoiding this issue through a system of frequent check-ins, and always letting people know that you’re about to start work in a file so they know to commit / stop working on that same file. That said, fair amount of work still had to be redone over the course of the semester.

What went wrong?

1. Unity is Slow

While unity is the fastest to get started, as you get deeper into the project the fact that all of those built in systems are closed off starts to create dead-ends. One such example is the collision detection system. It’s a powerful system, and very easy to use, but there were a few situations in which it provided inconsistent results. I ended up spending a few days just trying to isolate those situations and finding workarounds for them.

2. Not Enough Building

As a general note, we didn’t build to iPad as much as we should have been. There were too many times when we would work on completing an entire feature, instead of getting each piece of it done and seeing what we could do with just that. This stalled our iterations and slowed down production.

3. Diagnosing Lag

Performance was a frequent concern for us, since we were building a game for iPad. There are a handful of really useful tools within unity that we either weren’t aware of or couldn’t get working for a long time. One in particular is the script execution option in the iOS build options, which lets you turn off error checking, approximately doubled script speeds once we enabled it. Another is the built in unity profiler that shows you what features are causing the slowdown. Unfortunately, even once we got it working, the slowest category was ‘other’ which didn’t tell us much about what we needed to improve to get the frame rate up.

Lessons learned and conclusion

Ultimately, I still think that unity was the right choice for this project, and would continue to be the right choice as we move forward; however, we would begin to rely less on the built in systems of the engine and instead build our own or find more open solutions. For example, using SVN for versioning instead of the built in asset server and a 2D physics solution instead of unity physics. We did an alright job building generic systems so that they could be reused / modified easily, but we could have done a better job at that.

The networking solution we found may have been more trouble than it was worth. Part of me wishes that we had found a way to do the networking over bluetooth rather than wifi to reduce the latency issue, but I understand that that would have come with it’s own set of issues.