Designing Sausage Sports Club

Also check out my posts on (Programming, Tech Art, and BizDev)

What Is This?

I worked on Sausage Sports Club for 3 years and learned an insane amount in the process. I was incredibly lucky to be surrounded by experienced and generous game makers in that time who were willing to give feedback, advice, and help push me and my game forward every step of the way. I know few people have that privilege, so this post is to lower the ladder a bit and hopefully make making games a little bit easier. Here are the topics I cover in this post:

Design Pillars

Every design decision made along the way was based on a few design pillars I set at the start of the project. It’s not necessary to do this, but defining pillars is useful in deciding what game you’re trying to make and in giving some semblance of objectivity to making design decisions. When faced with any question in designing your game, you can always check whether they support these pillars.

My design pillars for Sausage Sports Club were:

Player Select

One aspect of the game’s UI design I’m conflicted on is the Player Select menu. Many people playing for the first time notice and comment that it resembles the Super Smash Bros’ Player Select. I was pretty annoyed by this because getting to that design was the result of solving small UX problems over many iterations. I spent a lot of time making changes to try and differentiate it more, but most of those changes added complexity and made the menu harder to use.

Looks a bit familiar, right?

Early versions of this menu front-loaded the customization process so players had to select their character, skin, team, and hat one step at a time through a small window where you could only see one option at a time. With 14 characters, 3–4 skins per character, 8 team options, and 60 hats, this was a long, burdensome process that was intimidating for new players and boring for decisive players. It became clear I needed to focus on reducing how much information new players needed to see before getting started, which meant fewer required choices and that getting through this menu should take as few clicks as possible.

Here are some ways I reduced complexity of this important initial menu while retaining the depth of customization:

Screen space is limited and showing the same information multiple times wastes it. Sausage Sports Club has a fairly large pool of characters to choose from, so it makes more sense to show all of them at once instead of forcing each player to cycle through them one at a time. I show a grid of all available characters in the center of the screen and each player’s individual information in widgets along the bottom of the screen.

Using a paradigm of cursors as each player’s avatar and tokens as each player’s selection has a lot of benefits. The most important of these is that it helps smooth the flow of getting into the game by allowing advanced players to help get newbies started. Before this change, when families with younger kids played, parents would often have to take their kid’s controller to help and I wanted to avoid that condescending break in game flow.

Having a cursor that’s free to move around the screen is also inherently more fun than locking your selection to a widget. It gives players room to play because they can steal from each other, change each other’s selections, and even hide tokens. It makes adding and managing bots easier since everyone can help pick characters for bots. It also establishes an interaction language that can be used in other parts of the game, like the Team Select menu which happens just before a match starts and lets players drop their token onto different team slices.

Team Select also uses the cursor-token paradigm!

Starting players off with tokens in-hand makes it so someone can play after only hitting one button to select their character. And if they’re overwhelmed and another player wants to help them, they don’t need to do anything or even pass their controller. If you can’t find your token, that’s fine too- the cancel button will retrieve it, even if another player is holding it.

Hiding advanced, optional customization and options behind small, relatively hidden buttons keeps them from distracting new, overwhelmed players without adding the extra complexity of a new menu. In Sausage Sports Club, players have advanced options like skins and player names that aren’t needed to play, but add depth for advanced users. By auto assigning the first available skin when a player picks a character, we let players get started without having to teach about skins or giving players too many choices before they’re ready. Player names are also auto-assigned because they carry player’s save data including hat progress and input rebinds but not until a player has played enough that those become relevant.

Some other notes about player names: Because Sausage Sports Club is family friendly I wanted to limit how dirty players could make their names. I noticed by limiting names to 3 characters, basically every curse word is left out and there’s a few bonuses. With only 3 letters, a much high proportion of the names you can make are funny without players having to be clever. This limit also gives a hard cap to how many players saves can be created, which keeps me from having to implement and communicate a cap even on platforms with limited save data size.

Here are the biggest lessons I learned from designing Sausage Sports Club’s first time user experience (FTUE):

Adventure Mode

At the halfway point of development, I had figured out the gameplay and art pipeline for everything, but was seriously worried about differentiating Sausage Sports Club from other local multiplayer games and especially that the game didn’t offer enough for solo players. To quell that fear I decided to add a campaign mode built for single-player and co-op with up to 4 players. I spent weeks deciding how it should be structured to add the most value, while keeping in mind the big limitation that I’d be the one writing dialogue, building environments, and coding everything. Once I’d weighed all the pros and cons, had a plan for Adventure Mode, and accepted it would add at least 6 months to my development, I decided scope up.

I’d already spent 1.5 years on the game and didn’t have any project-related debt, so why not follow through in making it the best thing I could and give it the best chance to succeed?

The Overworld!

So what is Adventure Mode? It’s a reality TV show where you’ll meet NPCs and help them solve interpersonal drama by competing in sports matches. On each day of the season, more of the Overworld will open up and give access to new biomes filled with toys and entrances new arenas. As you play, you’ll unlock new characters and skins, while also earning coins you’ll use to unlock hats. Most importantly, each playthrough holds new quests and arrangements of the Overworld meaning your adventure is always different. Elevator pitch aside, how does this work?

I knew there was a limit to how much content I could make alone, so instead of making one linear story that would only last one playthrough, I chose to make many short stories that could be re-arranged, interspersed with random sports matches, and replayed. I referenced sitcoms which similarly have short episodes, always feature the same characters, and can be watched for the most part in any order or combination without being too confusing.

To get the procedural sitcom feel I wanted, I wrote lots of quests; over 2x as many as I’d expect or want players to go through in one sitting. They all feature different combinations of characters, have their own 5-minute contained stories, and (for the most part) can be placed anywhere around the Overworld. When starting any day of the season I randomly grab a few from this pool of quests, making sure to only use any character once per day and to not reuse quests later in the season. Then I pick random locations to place them in the Overworld, which was important to encourage players used to linear games to go out and explore. A season requires players to go through 12 quests and the full pool is 26 quests, so you’re very likely to see lots of new quests for at least the first 3 or 4 playthroughs.

I’m pumped with where Adventure Mode ended up, especially that the structure feels so different from any other game and that every player’s experience really is unique, but the process of getting here was tough. All told, I spent another 18 months on the game after deciding to add Adventure Mode which is a lot more than the 6 months I first expected. Much of that was hustling at conventions, porting the game to Nintendo Switch, and moving to Austin to start a new job, but I definitely bit off more than I expected. Much of that extra time was spent redoing work after my first (or first few) versions sucked.

Here’s a few memorable spots where my first attempts at parts of Adventure Mode didn’t work out:

Quest Editor v0.1

Exciting dialogue!

Progression

As Adventure Mode, arenas, and characters all started getting finished up it became clear that player direction and motivation was lacking and I needed to look at how other games keep players interested and invested over time without making things feel like a grind.

I referenced addicting multiplayer games with repetitive gameplay loops like Overwatch, PUBG, TF2 to see how they kept players engaged. Here are the common threads I noted:

Up until that point, I thought my plan for progression and unlocks was good, but players weren’t responding to the implementation. At that point you earned coins (which are used to roll for a random hat) after each Adventure Mode quest and filled a meter towards unlocked a random character, skin or arena. I thought just having these elements in the game would be enough for a tight, compelling loop but it turned out that the little details of my implementation made a huge difference.

At that point in development there wasn’t enough time to add more unlockables, or add other progression systems I had in mind and I was hopeful adding juice would be enough to sell these moments. So I decided to keep iterating on each of the unlock sequences until playtesters started connecting with the systems.

Earning hat coins!

Here are all the changes I had to make before players would continuously play through seasons of Adventure Mode and revisit the hat shop to roll for hats:

I don’t share this example to suggest that any feature can work if you spend enough time polishing it, but to highlight that little details like pacing, timing, audio levels, camera angles, zoom, and music volume matter a lot especially in features closely related to making players feel a specific emotion.

Level Design

After building all the spaces in this game I’m convinced level design has to be fun before you can build anything worthwhile. That means making things fast, playing them fast, and jumping between fast. That workflow is going to be different for everybody, but you should think seriously about it and use any tools you have to make it better, whether that’s building your own tools, asking your team to prioritize tools for you, or buying good tools.

I used ProBuilder for some early levels and I still do to make collision geometry, but the interface is too slow and clunky for sketching. Specifically needing to look from a straight-on angle to select things and the tedious process of creating a new primitive and putting it in place slow me down so much compared to Maya’s refined toolset. When building levels I use Maya to sketch ideas with primitives and more complex shapes as needed. I select everything and export as FBX then run around in Unity on the sketch. I have a component in Unity that automatically adds mesh colliders to all mesh renderers in children, so I don’t need to take any extra steps in Unity after each export before I can test.

Some early shots of the Overworld in Maya.

At the start the start of this process I take a lot of notes and tear up the sketch a lot more, then as things get more refined I go back and forth making little tweaks. I’ll also throw on temp materials to various objects in Unity to help get a sense of how the space will look as it gets farther along. Once I’m happy with the layout of a level, I’ll start polishing in that same FBX by replacing primitives with higher poly shapes. I’m pretty frivolous about using many materials since I use a lot of tiling textures and find optimizing UVs boring. I generally only split props out into separate FBXs. Unless something has an especially simple shape I almost always use a mesh colliders for static geometry. For anything dynamic I’ll place a few colliders to approximate the shape.

Building the Overworld was especially challenging because of all the extra spaces and expectations it affords. It’s notably different from all the arenas because it’s one continuous space that sprawls in many directions. Also, everyone’s attention isn’t focused on objectives in the same way it is during matches, which means players are free to run in any direction.

With these constraints in mind, what were my design principles in building this space?

Camera

The design of the game created a few constraints for the camera. Since it’s local multiplayer only and supports up to 8 players, the camera needs to be dynamic and controlled by the game’s state rather than any individual player.

Given these constraints and 3 years of time iterating, rewriting, over complicating, and simplifying here are the important aspects:

The camera doesn’t move as much in arenas!

With the above lessons in tow, I decided to add a sprawling Overworld for Adventure Mode and it came with a host of new camera problems. Because different areas of the Overworld face different directions and afford different views, I needed a way to define settings quickly for different areas.

To this end I setup dozens of camera zones that each define the aforementioned settings and a few new ones:

Inspector preview!

One major takeaway from writing this camera system over such a long time is that more variables aren’t necessarily better. Especially as a game grows and more parts need to be tweaked, limiting variables to the fewest necessary to achieve the important range of outcomes can save time and make systems more intuitive and fun to use.

Shameless Plug

Thanks for reading, I hope you found this valuable. If you’d like to see more content like this please support my work by checking out Sausage Sports Club and sharing it with a friend. It’s out now on Steam and Nintendo Switch!