A humorous, chaotic puzzler about a lumpy potato rolling around a magical house, built over the course of 2 semesters. I was responsible for much of the initial prototyping before transitioning into a more support-oriented role as lead/systems programmer.
That Potato Game started as an offhand comment during a concepting meeting. Someone made an offhand comment roughly along the lines of “we already have a decent concept, let’s just make a throwaway one about, I don’t know, a potato.” Someone else thought that was funny and we spent the rest of the meeting making half-serious jokes and refining them into gameplay ideas. Sending our two prototypes to testing a week later, we had a clear winner: the game was just as fun for testers to play as it was to make.
This stand-up comedy style of development continued for most of the project, although towards the end we had to focus more on polishing what we had, and we had to be vigilant about scope. It yielded many of our more-prominent ideas: the eye-stalk growing ability got a horrified-yet-intrigued look from testers, and shatterable objects were added because testers kept pushing objects off high surfaces just to see what would happen.
While I had planned to accelerate our development with the systems I had already built in previous projects (with the teams’ permission), with such an unconventional direction I ended using a bit less than I had hoped. I was able to make full use of a dialogue system that had already evolved over the course of 3 projects before, and that one of the designers had worked with on the project prior. I also reused an AI steering and sensor framework in our initial prototyping, which helped us find that concept not viable.
During the second semester of development, we found that we did not scale as well as we thought–especially our ideation process, since it previously involved the whole team. With the increased team size, scheduling a meeting where everyone could be present was impossible. We found ourselves quickly encroaching on the period reserved for prototyping without much direction, and just chose our best candidate for the next level. On the technical side, our experiments weren’t faring much better: myself and another programmer were working on enhancing the squish ability using Bullet’s soft body physics, but the package we used had numerous errors and an code style more suited to the underlying C++ than C#. After a month of constant issues whenever we thought we were close to a breakthrough, whether proxying function calls or migrating existing code and assets, I had to make the call to shelve it in favor of more time-sensitive features.
As a lead, I had to provide enough structure to make sure our direction was unified, while also making sure people felt they could work on the features that interested them and pitch new ideas. To accomplish this I decided to take more of a support role, which at this point I had grown accustomed to as a systems programmer working closely with design. Our weekly programmer meeting served simultaneously to percolate information from leads meetings to all team members, while also being open to concerns/questions for next leads meeting, and being able to ask questions and get help.
While I’m used to doing odd jobs and answering random questions as they come in, I found that especially on larger teams this approach would destroy my productivity, especially if work on more complicated systems was being interrupted. Fairly early on in the project, I decided to try approaching documentation differently. Instead of the main Technical Document being a resource by programmers for programmers, it was a one-stop reference where each feature had a brief overview, then subsections for each discipline with guidelines for what level of detail was appropriate for each. By keeping everything in one place, it was also easier to maintain. I also assembled a brief document to unsilo our Git knowledge, clarifying workflows and how they would work with Unity, heavily based on other documentation I had seen.
Since we had more time for development, I decided to try a couple things to further our scalability. In the break between semesters, I set up Jenkins for automatic builds uploading to Google Cloud Storage, which helped us with deadlines and ensured we always had builds ready for testing. We also had tools for embedding build time and commit ID, which coupled with automatic logfile uploading to help us catch and track down numerous bugs.
Late in the first semester I wrote an analytics system to track player movements, send them to a server, and have them be viewable as individual paths. This helped us make data-driven decisions about efficacy. In second semester, we found the higher volumes of data killed editor performance, so I wrote a second editor tool to draw the data as heatmaps and overlay it in world.