I thought I would go ahead and continue with the team projects before delving into my personal work. Next on the list is Food Feud, a class-based FPS set in the delicious world of warring food cart vendors. I can’t deny that I had fun leading our team of seven to make a game that featured relish and hot sauce as ammo, but the development process definitely had its ups and downs.
Setting the game in New York’s Central Park made for some interesting and varied locations.
What Went Right
Scope
For this team project, we had to make a 4v4 multiplayer game with a single CTF map. I had made a 4v4 map a few months earlier, so I knew the tendency would be to make large maps with complicated mechanics. That’s not necessarily bad in the right setting, but we only had about eight weeks of production time on the project. In addition, there would be little to no time to teach players new mechanics or systems because we were limited to making a single level. Consequently, I was adamant about focusing on a core set of understandable mechanics and having a smaller map.
This turned out to be the largest reason for Food Feud’s success. Because we were mostly expanding on existing UDK functionality, we were able to rapidly create and test much of the core gameplay. The small size of the map also allowed us to build, test, and iterate quickly and often. In the end, scoping the project to the time and resources available to us helped us create balanced and fun gameplay and a polished, dynamic environment.
Structure
I’m a big believer in structure and order. I make to-do lists for myself, I set reminders and calendar events, and I arrange my collectible LOTR Pez dispensers by height. So maybe that bleeds over into the realm of OCD, but it’s served me well as a level designer, and it worked extraordinarily well for this project. As team lead, I met with the team and we all established a set of policies, schedules, and procedures. At first blush, that might sound unnecessary for a small team composed of seven peers. However, they proved to be invaluable over the course of production, and the fact that the team came up with them gave the policies credibility and created buy-in from the team members. These weren’t handed down, hierarchical creativity killers—they were collaborative guidelines that helped us reach our goals.
These included things like setting days aside for team-wide testing, establishing bug logging policies, giving leads control over UDK packages to prevent overwriting changes, and creating dependency charts to determine the schedule. These helped us develop core features like networked multiplayer almost immediately. They also helped us remain on schedule, resulting in only two days of crunch over the entirety of the project.
Theme
We built everything in Food Feud around one simple concept: zany food action. Everything had to relate to food. Our characters dressed up as hot dogs and tacos. Our weapons shot tomatoes and mustard and relish. Our flag was an elderly customer that players carried to their respective food stands. We named our classes after different restaurant positions (e.g., The Fry Cook) and gave them food-related abilities (e.g., The Grease Trap). Particles made of swirling hot dogs and tacos acted as the flag capture effect. For every element of the game, we went through and asked ourselves, “How can we relate this to food?” The art style perfectly fit this zany theme, and it resulted in a game that spectators easily enjoyed and players instantly recognized.
Every class has a food-related title and ability. The Mascot here is showing off his Showtime ability, which greatly increases his fire rate and sex appeal.
What Went Wrong
Communication Growing Pains
All of my previous projects consisted of three to four people, all working in the same room and all solely responsible for their areas of expertise. Communication wasn’t much of an issue when I could look across the table and ask my artist any question. But this larger team of seven people with leads who actually lead others didn’t come without its growing pains. We found that different specialties would make assumptions about the minutiae if it wasn’t specified, a problem that sometimes resulted in frustration and rework. For example, one of our artists worked on a set of modular rails, but the level designers didn’t specify anything about pivots or grid sizes or dimensions. As LD’s, we were used to working in a specific way, but we hadn’t communicated that to the art team. That artist had to go and tweak those assets for every detail we forgot to mention. I quickly learned that those assumptions can quickly pile up and derail an otherwise timely release if they aren’t communicated to the team.
Personnel Problems
Another byproduct of having a larger team is the seemingly unavoidable case of differences of personality. Not everyone is going to agree with everyone else, and team members are almost guaranteed to butt heads on occasion. Such was the case with this team. Disagreements and frustration are natural byproducts of the design process, but the problem came with how we handled them as a team, and I take much of the blame for that. When people would come to me with problems or issues, I would meet individually with that person and tell them in a roundabout way that I would like them to generally pick up the pace. That was fine, but I didn’t always mention the specific ways in which they needed to change. In so doing, I denied them a chance to improve in those particular areas, and I created plausible deniability—that person could honestly say that I had never told them what they needed to do differently.
As a lead, I didn’t do that person or the team any favors by withholding specifics like that. A leader must be kind and bold. Being considerate doesn’t do much for the individual or the team if it isn’t paired with clarity and honesty. I’ve spearheaded some policies and made some personal goals on my new team project,Voodudes, to prevent this mistake from happening again.
Insular Design
About midway through production I showed the game to a fellow LD on a different team. He mostly enjoyed it, but he commented that the lack of verticality in the level made it feel flat and stale. We hadn’t even considered that, but he was absolutely right. We made the change and the level improved so much that we gave him a special thanks in our credits. We made time for a lot of internal testing for our game, but we didn’t do much external testing. Keeping the design of the game so closed to others meant we didn’t get their feedback, and I’ve since learned that all feedback is helpful—even if it simply serves as a reminder of different considerations and points of view.
Soliciting external feedback led to some much-needed verticality in the level, and it allowed us to make peacock and sloth exhibits (which is all that really matters in the end).
Summary
Food Feud was a great experience because it taught me about the specific cautions and guidelines for working in a larger team. Food Feud continued my tradition of strongly themed games, but it also reinforced that even the best of ideas can be enhanced or derailed by the particulars of the team. Above all, it taught me some important lessons about structure, clarity, and leadership.
I'm a game designer with years of industry experience and a master's degree in design who's worked on AAA games, indie darlings, and free-to-play products.I love using my design and scripting experience to create awesome products, especially when it means working alongside a passionate dev team.Take a look around at some of my work, and please don't hesitate to reach out if you have any questions or opportunities!