TPS Report Simulator

In November 2016, GitHub ran a game jam (called “GitHub Game Off 2016”) with a broad theme of hacking/modding/augmenting. My friend Eric has wanted to build a game for basically his entire life, and lately I’ve been meaning to carve out time for a coding project but never seemed to get around to it. We decided to team up for the Game Off so we could both make some progress towards our respective goals (plus it was an excuse to hangout and play video games.) Our game, TPS Report Simulator (play / source), is a retro-inspired pixel art “shooter” in which the player fends off managers, hacks computer terminals, and tries to escape cubicle hell. We ended up learning a lot, building a fun game, and having our game featured in the Github write-up.

Our GitHub Gameoff 2016 submission: TPS Report Simulator


We built the game using Phaser, an open source JavaScript game library. Previously, we’d played around with some other options such as PyGame but found them to be a bit clunky and setting up a local environment was painful. I like Python a lot more than JavaScript, but Eric and I both have much more experience with JavaScript, and creating a web based game made it much easier to iterate quickly and see our game taking shape, which kept us motivated to continue working on the project.

I setup an auto-deploy from Github to Heroku so we could also always access the current version, even if we were away from our respective workstations, in case we had a sudden burst of inspiration or even just wanted to share the game with friends. The latter turned out to be really fun as the game progressed and we had some friends checking in periodically to see what new features we had added, bugs we had fixed, etc.


On past projects, I’ve had a tendency to obsess over choosing the “right” tools. On this project, we tried really hard not to do that. Instead, the first time we got together we spent about an hour looking online for game libraries. We came across Phaser and were both impressed with the examples on the site. After playing around with some sample code we realized how rapidly we’d be able to see results and we were hooked. There was a lot of value in not trying to over-optimize this decision. Phaser was totally adequate for the task at hand and hours spent evaluating other game engines really just amounted to time spent not working on our game.

We used git because, well, the gamejam was sponsored by Github. I work on developer tools at Uber, so this is familiar territory to me; my team supports the systems engineers use to build software, so I spend a lot of time talking and thinking about version control and repos, even if I’m not writing software much myself. However, Eric had never used git before. Fortunately, with a team size of 2 and both of us working in the same room most of the time, we were able to avoid many issues and work through the ones we encountered together. It was also good experience for me to spend some time teaching Eric git foundations, which required me to sure-up my own knowledge along the way.


Eric and I had to divide up all of the tasks to build a full, working game between the two of us. Given our interests and backgrounds, there was a pretty obvious division of labor: he is a talented artist, and while I’m not a software engineer, I have a lot more experience building software. This made it easy for us to focus in our respective areas, and this helped us to be productive. However, we also learned that we worked better together if we both understood at a high level how everything was working.

Eric was “just doing art” (this isn’t actually true; he contributed a fair amount of code as well and prototyped several features.) I was “just writing code” (this actually is mostly true; I contributed game design ideas and suggestions for how mechanics should behave, but I never touched any pixel art.) However, all the work from these two areas needed to be integrated to get anything close to a working game. We quickly learned how easily one of us could break the other’s changes.

We learned quickly that it was better for us to specialize. I was able to produce functioning code with relatively few bugs much more quickly than Eric. I could solve technical problems in our code base fairly reliably. Meanwhile, Eric’s pixel art made the game; it looked great and was fun to play largely because of the classic console feel. I didn’t have much to offer in this area. Despite this specialization, there was tremendous value in each of us understanding the workflow and considerations for both types of work. This helped us to manage expectations of one another (i.e. understand realistic time frames for getting something done) and work together more effectively.

We didn’t include any music or sound effects in this iteration of our game. At one point, around the middle of the month, we attempted to recruit a third friend to do some sound design/programming for us. He wasn’t available to join, so alas, our game is silent for now. However, if he had joined, I think there would have been value in ramping him up on how the existing graphic and game code worked, and each of us having at least a cursory understanding of how the sound effects code behaved.

Planning & Schedule

For most people there is a natural tendency to treat personal projects as “not serious” and therefore to avoid doing anything that feels like work. It’s easy to just dabble and write some code and say you’ll know when a project is done. It’s harder to set a schedule, commit to regular meetings, define a punch list to understand what “done” looks like, and to hold yourself accountable for shipping something on time. Fortunately for us, Github gave us the schedule (done by the end of November), and we were excited about the project.

I’m a project manager by day, and I’m a little bit obsessed with notebooks, productivity systems, and todo lists. I eventually realized that we needed to apply some of these tools to TPS Report Simulator if we wanted to have a full, functioning, non-broken game at the deadline. We spent the first week or so of November meandering around, talking through a few different ideas, and shifting our focus several times. During weeks 2 and 3, we built about 50-60% of a pretty awesome game: we had working controls, enemies, and some other basic mechanics in place. However, it was obvious that the game had some large gaps. We had game-breaking bugs. We had undocumented features and we weren’t steering players towards success or even satisfaction when playing. We reached a point where we were just kind of hacking here and there on different parts of the code and neither of us was thinking about the vision or direction of the game.

The last week of November is when we really got serious about making sure the game was finished, not just as in done, but as in polished and feeling like a cohesive experience. In our evening coding sessions, Eric and I would start by spending 30 to 60 minutes talking about what we should each focus on next. We identified the list of must-fix bugs, must-be-completed features, and tried to relegate as many things as we could to the nice-to-have-but-not-essential list. This last group would be a place to capture all the ideas we were excited about but couldn’t realistically implement in the time remaining if we wanted our game to be more than just a tech demo.

These planning exercises were extremely helpful. They allowed us each to understand where the other would be focusing and what tasks we had to check off to be measurably closer to finished.


Overall, this project was a lot of fun. It forced both of us to challenge ourselves technically and creatively. It called upon our existing experience while requiring us to pickup new skills along the way. We benefited from the two very different perspectives of artist and developer, and being able to safely suggest ideas even if they turned out to be bad or they weren’t viable. I think we made the right decision to specialize in particular areas while still having at least basic familiarity with how the different parts related to one another. Ultimately, the right game engine was the one that we could both use to make meaningful contributions with relatively little overhead.

Planning and defining our final scope was useful towards the end of the project. We should have probably done this a little earlier in the month. However, I think there was value in spending at least the first week or so talking about and playing with ideas and seeing where we ended up. This prevented the project from feeling too much like work that we would get tired of and abandon. Ultimately, we ended up with a game that we’re both proud of and that we enjoyed making. I hope you’ll take a few minutes to check it out.

Play TPS Report Simulator

Leave a Reply

Your email address will not be published. Required fields are marked *