Postmortem: Endless Swarm

29 04 2015

What Went Right

The project started off well; we met several times the first week to discuss design and team organization. We settled fairly quickly on a Sci-Fi themed twin-stick shooter. The original design had several rooms laid out in a circle, with a smaller circle of rooms inside, repeated until a single room at the center. The idea was that the player would need to work their way inwards against increasing threats. We wanted procedural levels, and upgrades for the character. The design work was performed quickly, and documented effectively, which aided the rest of the project immensely.


Diagram 1 – Initial layout for the map; we didn’t end up using this unfortunately, and went with a simpler, linear path.

We determined that the work for each week would be discussed in advance, and distributed as needed. We would be working in Unity, and keeping the work together with Git. The latter proved a problem early on, but became a great asset later in development. We would meet to merge, giving each team member a chance to explain what they’d done, and how it fit into the rest of the project. As a result we each mostly understood the others work well enough to interface with it later without delays. Additionally, having a remote repository meant no work was lost when I had to replace my hard-drive, and there was always an “official” current version.

As the project continued the most effective times for me were weeks with large blocks of programming. In particular, the weeks in which I worked on the Hive-Mind AI, and the MapBuilder class were especially productive, as I was able to sit down and work towards a goal with no dependency or merging delays.


Diagram 2 – Feature branching work-flow in Git.

After some trouble with Git, we sat down and determined a work-flow. Each week we would each create a branch off the “master” branch, though we didn’t settle on a naming-scheme which caused some minor confusion later. All work for the week would be done in our individual branches, and at the end of the week we could meet and merge them one at a time as explained earlier. We didn’t manage to stick to the workflow as closely as I would have liked, but overall it worked fairly well.

Part way through the project we determined that we needed to upgrade Unity to version 5. This gave us access to additional lighting options, and fixed some problems one of my team-mates was having with the prior release. The upgrade was entirely painless – the Unity team provided a utility which automatically updated all of our code to use the new APIs, and the upgrade was completed within a week, along with the rest of the work for the week.

The distribution of work was surprisingly smooth throughout the project, despite not having any particular process for doing so. Most weeks we determined a list of tasks which needed to be completed for the next version, then took turns picking things we’d be interested in doing. Each member of the team had somewhat different interests, so we rarely ran into any overlap, and had no problems even when we did.

For the most part, determining what needed to be done in advance permitted us to avoid getting locked up on dependencies. We were able to plan far enough ahead to avoid assigning tasks which were dependent on other tasks from that week or future weeks. The one exception we encountered arose from delays in the availability of assets for the enemy creatures, which lasted approximately 1-2 weeks.

Finally, while it took some tweaking on several occasions over the life of the project, we managed to adjust the player movement and camera tracking to something that feels right. Fast and snappy, but still smooth enough that it’s not jarring for the player.

What Went Wrong

At the beginning of the project we were constantly plagued by problems with Git. The repo set-up was relatively simple, but implementing a work-flow, and ensuring everyone was comfortable, took several weeks. During that set-up time work was slowed noticeably by delays triggered by misunderstandings of Git, mistakes made while committing or merging, and similar problems. These were mostly alleviated as time passed and we all settled into a work-flow.

Some of the Git problems remained throughout the project, however. In particular, the merging of Unity files (Prefabs, Scenes, etc) caused problems almost every week. The built in merging tools had trouble with the format of the Unity files, and tiny mistakes while merging would cause Unity to crash with no error. Eventually I wrote a script to search the meta-files (a particularly common source of problems) for the artifacts left by unmerged or poorly merged content, to make finding the source of the errors somewhat less painful. For future projects it would be prudent to research some of the merging tools available on the Unity Asset Store before beginning work.

Despite the script to find errors and our other solutions, the problems encountered with hosting Unity files in Git still slowed work that took place in Scenes or Prefabs. Even causing development of relatively simple systems, such as weapon swapping, to take just as long as the code heavy development of the Hive-Mind AI system.

In addition to Git problems, we encountered several issues which arose from our varied working environments. We each had different set-ups on our PCs, and as a result would periodically encounter errors which would appear only on one machine and not the others. Given the difficulty of finding times to meet in person, solving these problems was occasionally quite time-consuming. This was not entirely a disadvantage however, as making it work in different environments forced us to pay more attention to ensuring the game would run on different platforms.

While the design stayed mostly constant, we ended up cutting a few of our original ideas due to time constraints. In particular, we originally wanted many rooms connected by gates that could only be opened when supplied with sufficient power. This ended up being dropped for a more traditional rogue-like level design, with each floor being randomly generated with a portal to the next. Instead of falling back to the entrance to upgrade the player is given the chance between floors.

We also never managed to get the dual-stick controls working. This was largely due to a combination of time constraints, and a lack of consistent hardware. Since we only ever had the game working on the PC anyways we’ve stuck with mouse-and-keyboard controls for the final release.

Finally, with all of us both working and attending school, maintaining a regular meeting schedule grew more difficult as the project went on. In my opinion the source of the problem was that we had no one person responsible for setting meetings. In future projects I think it would be wise to assign the organization of meetings to a single individual, or to have it cycle each week on a predictable pattern.

Related Courses and Other Influences

Perhaps the earliest influence, CGDD 2002, Fundamentals of Game Design, provided us with a familiar vocabulary with which to discuss the design for the game. In particular, the concept of the MDA (Mechanics, Dynamics, Aesthetics), and the different methods for documenting a software design provided us with common ground to work on. A design document on Google Drive, maintained and adjusted through the life of the project, gave us a place to discuss and record design decisions for current as well as future work.

Our choice of Unity as a development engine allowed me to draw heavily on skills learned during my CGDD 3103, Application Extension and Scripting, course. The experience working in Unity, and the understanding of Component-Based Design were particularly helpful in organizing the project in a way that wouldn’t become overwhelming as the project grew.

As with most of my games projects, the skilled acquired in CGDD 4003, Digital Media and Interaction, were applied in abundance. Flocking-style behavior for the AI, and vector math for bullet trajectories and character movement, just to name a few. Additionally, while Unity already has a built-in particle system, an understanding of how they work allowed me to employ the existing system more effectively.

When I took CS 3424, Data Structures, Dr. Karam provided excellent instruction over and above the usual Data Structures material, including coverage of algorithm design and analysis. The application of which was used in the design of the Hive-Mind AI and map builder quite heavily. He also provided excellent exercises in debugging, and while the tools differ between C++ on Linux and Unity on Windows, the principles I picked up in that course allowed me to solve problems we encountered far faster than I could have hoped to otherwise.

In addition to skills acquired in college courses, the source control and team-management skills I’ve picked up while working with the Colonial Pipeline Company proved invaluable. The Git workflow we eventually settled on, as well as the conduction of the meetings and presentations were all heavily influences by my experiences at work. In particular, the heavy documentation before we started work was inspired in part by the documentation I had done for projects at work.

Finally, while no one member of the team was decidedly more experienced in all areas than the others, I was able to mentor in my areas of strength largely because of my experience working in the CSE lab as a tutor. My time working in the lab taught me a great deal about how different individuals learn, as well as how to identify and utilize these various teaching methods.