Overview 

Pizza Rat is a top-down wave shooter. Design-wise, it’s a mashup of various subgenres; it’s a little bit “fast-paced twin-stick” and a little bit “casual rogue-lite.” Working sparingly, we spent three months developing the game. If we had been working full-time, it may have taken about a month.

The project had two goals: be an icebreaker for our newly formed team and get a finished game out in a short amount of time. To this end, we were happy to make something that was short, fun, and stupid. We were prepared to cut corners and rush certain elements in order to finish the game.

Here are the big choices we made during development, along with some thoughts about what served us and what we would do differently next time.

Build Upon Existing Code or Start Over? 

A couple of weeks into development, we passed the engineering torch from Pat to me. I had to decide whether to build upon Pat's code or to start over. I chose to build upon Pat's code.

The core game was already functional (you can move! you can shoot!) and it wasn't too hard for me to navigate Pat's code. Unity's modularity made me feel all the more equipped to build on top of what already existed.

If the game had remained tiny (you can move! you can shoot! let's toss in some rat art, a little polish, and call it a day), this would probably have been fine. The problem was that we added a few additional systems and we frequently reworked the core design. Which brings us to the real difficulty: No one person felt like they truly owned the code.

A single person owning the code isn't something you can necessarily expect in a team project. Collaboration—especially in a flat structure—means shared ownership. However, Pat switched entirely to design work, and even though I was building on his foundation, I changed the game enough that he—understandably—no longer had any idea where key pieces of code were, nor how they were set up. I, meanwhile, would get requests for basic gameplay features (how do we set enemy health? where are power-up values stored?) and I would respond with: "I don't know. That's something Pat made." And if Pat didn't know, and I didn't know, then nobody knew. 

The project was small enough that I could figure these things out without too much trouble. But I spent a lot of time figuring things out, forgetting them (because I still didn't truly feel like they were mine), and then figuring them out again. And sometimes I discovered that one of my new systems didn't play nice with an old system I'd never bothered to look at, and extensive rejiggering would ensue. Given the simplicity of the game in its early state (you can move! you can shoot!), the right move would've been to just start over.

That is… unless we had a contained design from the get-go.

Freewheeling Versus Strict Design Process 

We played with different (sometimes drastically different) design ideas up until the very end. This is fine.

I mean it, though. It was fine. Given that the project was an icebreaker, the point was to explore and to discover one another's interests and strengths in game development. Given this, I think it made sense to treat this project as more of an improv session than we might have otherwise.

While I think freewheeling was the right move for Pizza Rat, we'll want more structure in future projects—especially larger ones.

Miscellany 

One of the corner-cutting technical decisions I made was to use Unity's built-in particle system for projectiles. I figured: the system already exists, it handles collision, and everybody knows how to use it.

I was right that the system already existed. I was wrong that everybody knew how to use it. What's more, if I'd made a component from scratch, it would have had a few obvious inspector fields and that's it. Meanwhile, directing newcomers to the particle system and having them search through 300 inspector fields when all they want to do is edit speed is maybe a little much.

What's more, I also had us use the particle system for explosion collision. It ended up being possible to be within an explosion's area of effect and not get hit by a particle, and thus not get damaged. While this might be "realistic" in a sense, it made gameplay feel inconsistent and awkward.

If we were to do this project again, I would probably make a custom component for projectiles.

Wrapping Up

There was something else about passing the engineering torch: it didn’t happen instantly. There were a few weeks of ambiguity when it wasn’t clear who was doing engineering and who was doing design. Given that we established this project was a sort of improv session, that kind of makes sense.

So my takeaway is this: If you’re doing a small (but not, like, weekend-game-jam-small) project to test the waters with a new team, that’s exactly the time to set things up just so; to put in the extra work up front for solid structure and flexibility. I’m talking about communication, process, and project structure. Even if everyone on the team has been working professionally for years, if you’re new to each other, then that’s going to be a challenge.

It’s a fun challenge though, and can lead to something unexpected and amazing. And that’s why we do this.