Student Post Mortem: Primordia

Preface:

Primordia is a top down sci-fi shooter built in Unity by a group of 15 students at the Tribeca Flashpoint Academy. Players take the role of Viktor Schell, one of very few remaining humans in the galaxy after a deadly virus wiped out most of humanity. Viktor has made the trek into deep space to a scientific colony called the Ark that was meant to find a cure, but has been dormant for greater than a year. Once aboard the ship, players meet the Ark's AI, ORSON, who believes a cure is still possible, but needs your help to finish it. Unfortunately, not all intentions are as pure as they seem.

The game was built over 4 months with a focus on creating a vertical slice of the whole project, so players have access to roughly 1/4 of what the total game would be in the story mode. In addition to that, we were able to add in a survival mode titled Annihilation, as well as throwing in several achievements to earn.

As lead producer on the project, the issues I bring up in this document are heavily slanted towards the production aspect of Game Studio 2 (GS2) and may or may not reflect the feelings of other members of my team. Because of this, several of my points are focused on direct actions I took that I feel had either positive or negative results.

If you would like to download the game, or play the web version, please visit the link here

Things that worked:

1. Cross-Discipline Communication

When we sat down at the beginning of the semester I knew that the only way to get things done in an efficient manner was to get people talking to each other. I’ve had issues on previous teams where groups would segment themselves from the rest of the team to the point where people didn’t even know some of their team members’ names. If communication doesn’t flow well on teams, things tend to get delayed. This semester I set out with the intention of limiting segmentation in the group by setting meeting schedules that would solely rely on cross-discipline communication. This would mean we would rarely have only art sitting down, but instead art and design, or design and programming coming together. Preventing group segmentation was not the only reason for wanting to do this. An added benefit was keeping each group up to date with what was feasible or not by having a check in place with another discipline to vet ideas against. How often have games been overblown by designer scope? This check allows people to really understand the issues other team members are facing, streamlining the whole process eventually.

Initially there were two methods I wanted to try when going about this goal. The first was to create strike teams assembled of various disciplines. This meant we would try to get an artist, designer, and programmer together to meet regularly and focus on specific aspects of the game to build or improve upon. This didn’t work out primarily because of weird scheduling issues with individual schedules not being able to line up correctly.

The second solution was only having meeting blocks that involved at least two disciplines. This worked a bit better, as we found once a week where designers had a four-hour opening with programmers, and artists were able to sit with designers. In the case of design and programming, the designers were able to immediately get responses to questions they had, and were able to quickly trouble shoot any problems that occurred.

2. Production Process

Somewhere around a month and a half into the semester I sat down with Bob McCabe to catch up. Eventually we got on the topic of GS2 and our team’s current progress. He told me that from his view, it seemed we were the only group that was following a traditional development process when approaching a game development. What he meant was we were utilizing the standard development structure of paper design, grey boxing, initial art pass, final art pass, and finally a lighting pass. This structure was likely what kept our progress moving forward throughout the semester.

By utilizing this structure, it meant our designers were never sitting around waiting for both art and programming to get tasks done, as well as front load our major art assets to the beginning of production. Our designers were free to work in a basic grid structure to map out levels on paper, and overall create our entire level well before they were even given the toolset to build it. Once we had the basic movement within the game, they were then able to take those levels and push them into the engine and move around, getting a feel for the space and making adjustments as needed. In addition, by having them work with grey box, we weren’t forcing art to get environment assets done early, which would push back progress on our larger, higher priority character and enemy art. When art was ready to start putting in environment art, all they had to do was swap out the current building blocks our designers used in their levels with the new objects. This meant we weren’t wasting a month of progress and allowed each department to keep their eyes focused ahead, rather than fixing issues from before. Not everything went perfectly, but it was our first time going through this process, and generally it kept us on track and seeing obstacles before we got to them.

3. Badass Dev Team

There’s no denying it, we had the best programming team in the school. If we didn’t have the people we had, this game would not have been what it was. Because I have nothing but praise to give to these guys, I’m going to openly say their names. Michael and Ben were both unbelievable in what they did over the semester, yet both held very unique positions. Ben had the raw organization skills to keep the programmers on task and looking ahead solving problems, and Michael was just a beast. After our final presentation I sat down with Ben to talk about everything and we both agreed on this: there was literally nothing we could give Michael that he could not handle.  I know on my end that I thought long and hard on what to give Michael that would give him a challenge and keep him interested, but the more I talked to other people, the more I realized he was perfectly happy just knocking features out. It eventually got to the point where I started to question in my head whether Michael was actually spending the amount of time he estimated on things because he was so good. That’s not even saying I was mad with his estimates, I think the longest time period he told me for a single project was three days. I have no problems with three days.

I don’t want to sing praise to just those two, because Adam was also an incredibly valuable asset. After about a month and a half of him working on gameplay programming, Ben decided to move him onto UI. Initially he was hesitant, but I worked with him and started brainstorming with him on cool things to do with UI, and eventually started to get into it. He ended up taking on a piece of the project that he was unsure of and made it entirely his own. In my opinion, we ended up with the best UI of any of the GS2 projects, and I solely place that result on Adam’s drive to make it the best possible. Since then he’s told me he is considering specializing in UI programming for several reasons, one of them being his enjoyment of it.

4. Picking Up the Slack

There was a core philosophy I had while taking my picks for GS2; I only wanted people who liked working with people, and didn’t like it when someone dropped the ball. When we finally had our first team meeting, I sat the team down and told them a few of my personal opinions on how I feel about teams I work with. First, I don’t tolerate people complaining about something they aren’t ready to fix themselves. Second, I don’t dictate work schedules, only deadlines, and I would work with them to set those. Each of them are adults that can figure out their own work/life balance, and as long as they keep hitting deadlines, I couldn’t care less on how they scheduled out their time.  Finally, if each of them put forth their best individual work, they need to trust the person next to them to do the same.

When it came down to roughly the last month of production, we finally had the exact dates we would be ending the project on.  At that point in time we were able to look at what we had, and where we needed to be before break started, and had a very clear picture of what was still needed to get to beta. Once again, the producers laid it directly out to the team and said, “We know you don’t want to work over break, and we don’t want to make you. From the beginning we’ve planned for December 16^th, and we need to stick to that to make this happen. Whether you guys have to work over break is entirely dependent on your ability to get the remaining things done by then.” They pushed and got about 90-95% of what they needed done.  But I knew this team by then, and that part isn’t what surprised me.

The last week before break, I started having people come up to me and basically say, “I don’t like this,” or, “I want this to get in the game,” and each one of them told me, “Can I work over break to make this happen?” Why they thought I would deny them that opportunity escapes me. More than half the team ended up taking up optional projects over break to get wish list features in and improve parts of our game we thought were lacking. Because of this attitude we were able to squeeze both Annihilation and achievements into the game.

5. Annihilation’s Popularity

There is a level of irony to the fact we spent four months building a story based vertical slice and then having a game mode we spent maybe three to four days on total become the more talked about feature. Obviously a major reason we were able to do it so quickly was because we had the sandbox already created, and all we had to do was some custom scripting for the game mode.

Looking back on it, the most likely reason is the same reasoning social and mobile games have so much popularity; it is easy to talk about. When you have a game mode that is purely score based it is easy to compare yourself with other people playing the game, and thus talk about it. In addition, we were able to create a strong enough ability sandbox that players tend to discuss strategies on how best to beat high scores.

The success of this mode is something we’ve taken to heart in concepting our next project, as it paints a clear picture of the value of good gameplay over story for us.

Things that didn’t work:

1. Lack of Art Export Experts

Honestly, we didn’t have a clue what we were doing with our export/import settings between Maya and Unity. We knew Unity was pretty straightforward in handling anything being imported, but we knew very little about setting scale initially and how that affects the whole game later on. What we did know was learned during our small UDK tutorial sessions the year before and involved setting snap settings primarily, which didn’t really teach us the lessons we needed to learn.  By setting these things early on we eliminate future re-works, and potentially provide a far more realistic product.

But, because of our lack of foresight, all our models ended up being 90 degrees off when we started to work in look-at functions with them, and required an unnecessary amount of back and forth to get them to the correct rotation. During the process we all recognized that this could have been easily fixed if we had more opportunities to sit the art guys down with the dev team.

2. Too Few Meeting Opportunities

This is mentioned a little bit earlier in this document, but we really had trouble getting enough of our guys together at the same periods of time. It ended up being completely impossible to get our full team together unless it was outside of the normal workday. Unfortunately, most of our guys traveled an hour or more to get into school per day. This caused us to be hesitant when scheduling meetings outside of the day period because it would mean people were doing 12-hour days. This meant that we didn’t hold a single full team meeting outside of class until 2 weeks before winter break occurred, or roughly 3 months into development.

Not having at least a single two hour full team meeting per week ended up costing us precious development time, and possibly could have led to increased bug fixing, and greater team collaboration.

3. No Idea Leader

The morning of our first GS2 meeting we were supposed to have a game concept pitch. That was impossible, and we knew that. There seemed to be urgency on the faculty’s end for teams to have a fully fleshed out concept extremely early in the process of development. This immediacy meant we had no time for a team who barely knew each other to break the ice and sit down to discuss ideas. We took the first meeting of the year and spent nearly six hours straight brainstorming with the full intent to have an idea ready by the next meeting. Basically, we got to the point where we didn’t have a strong idea that was really standing out, but one that everyone was just ok with. There was no spark involved with the idea, and I think we all felt it was derivative and uninspiring.

By not having that one great idea that everyone just keeps talking about, we lost out on having our team be fully passionate about the project and really take ownership on it. Even after we wrapped, I discussed this feeling with several of the team, and they felt the same. Everybody on the team only seemed to be about 50% for the idea. No one hated it, but no one loved it, and that kind of hurt our creativity on the project. If I learned one thing out of this process, it would be to never rush the brainstorm period. You might end up hating everybody on your team at points during that period, but eventually you all come together and get behind an idea that everyone thinks is pretty awesome.

4. Where Was Mother?

Luckily, due to the intrinsic nature of our team, our lack of discipline didn’t affect us nearly as much as it should have.  I feel terrible admitting this, but we never wrote up a single person on our team. We gave out a few warnings, but never enforced any policies we put in place. Personally, I view that as a complete failure on our part, because there were issues that should have been handled with written documentation. By not sticking to our values and giving repercussions for failure on our team’s behalf, we often fell slightly behind on features, which cost us when it came to trying to present those features.

The biggest example I can provide is with several of our art assets. They were coming in far later than they should have, and even the time estimates I was being given were being missed by a significant amount. Part of this was the lack of oversight by the producers, and eventually was fixed by instituting stand-ups three times a week for over a month of production.

In addition, our audio team was missing key milestones for their assets that were costing us revision time. They were busier than normal audio students based on their doubled schedule, but we should not have allowed things to get pushed back as far as we did. By not getting those sounds in on time, we lost opportunity to iterate and provide feedback in time.

Overall the issue comes down to two words: accountability and responsibility. No one up top was really holding the producers accountable for the overall project, which is what would normally be seen. In addition, the producers then take that accountability and make others responsible for completing assets and features on time. We had none of that structure, and never held people responsible for hitting their deadlines. Even simple warnings to people early on would have provided a greater sense of urgency across the whole team.

5. Decision Making

This was by far the most indecisive team I have ever worked on, and I take responsibility for a lot of that. Far too often we allowed conversations to go on about features that really needed to be set. This issue can be cited to so many problems on the production side; the two most notable ones were time sheet dates and task tracking. Let me go through each of those issues and their effects, then, I’ll back up and explain why this issue was happening.

In regards to time sheets, it took us roughly four weeks to nail a specific due date for them down. We kept becoming split between doing it on Friday, Monday, or something ridiculous like Wednesday. Usually you don’t think this would matter, but it really screws with things when your deadlines are Fridays, and time sheets are due on Monday. Does that mean people then need to get all their work done before the weekend? What about due dates on Fridays? Well then you aren’t giving people the breathing room to see if they need to push themselves over the weekend to meet the necessary hours per week. Eventually we ended up just leaving it at Monday and dealing with the deadline thing as it came. On our next project we’ve identified that the bigger issue is deadlines being on Fridays, for multiple reasons, and have moved them to Mondays. This means our deadlines will now coincide with time sheets. Taking four weeks to iterate on this idea was confusing for everyone and it didn’t start things off well. As you’ll see, we had just as many problems determining a task tracking system.

We utilized a total of six different programs over the course of the semester to track progress on the game. How can any individual keep track of that many locations? Don’t let that number fool you though, we didn’t use that many all at the same time, but instead cycled through them trying to find the thing that worked the best. Initially we were on Assembla doing all our subversion merges and tracking progress through that with Excel and Google Documents maintaining a larger picture. This was only meant to be temporary as we though the school’s solution in Basecamp would be the answer. When we got a look behind the hood of that, we backed away almost instantly. Eventually we moved to a program I pitched to Brian before the semester started, called Pivotal Tracker. After around six weeks of messing around with these different systems, we finally settled on a location that we failed to fully enforce activity on.

There are a couple things going on that screwed up our decision making process. If I can be modest, I’m a pretty gung-ho person at the beginning of a project. I like to get things moving smoothly as fast as possible. Unfortunately, doing that doesn’t take into the account other people’s feelings so much. Knowing this, I tried to involve more people on the decision making process, especially in regards to over all procedures. Quickly, or possibly slowly if we’re sticking with this issue, I realized people didn’t care, and they will end up using whatever solution you give them provided it works and over time can be improved. In general, it took far too long to set up the chain of command and allow a singular person to just make the big decisions. I still deferred design decisions mostly to the team, but when it came to how to manage the team, I became the sole provider of answers for that. Whether that’s the best thing in the long run or not, I don’t know, but it eventually worked, and it took far too long to get to that point.