What started as a university graduation project has grown into a surprisingly chaotic restaurant game where the raccoon doesn’t actually do any cooking. Here, you’re running around the restaurant, delivering ingredients, protecting customers and dealing with monsters while the Chef does the cooking. Sous Raccoon has since moved into Early Access, with new content, controller support and online co-op for up to four players being added along the way.
Perhaps the most interesting thing about the game is that some of its biggest decisions weren’t part of the original plan. The team didn’t initially set out to make a roguelite, and co-op turned out to be one of the most difficult additions they’ve worked on. We spoke with Novice Flow Team Lead Phongsatorn Chotephongchana about how Sous Raccoon changed during development, how the team balances all the chaos, why some monsters were simply too good at making players’ lives miserable, and how one player’s attempt to use a controller ended up changing the game.
This interview would not have been possible without the wonderful people at Rising Tide Publishing. Many thanks Dustin Hucks!
It wasn’t supposed to be a roguelite
The original idea for Sous Raccoon was already unusual. Rather than making another restaurant game where the player spends their time cooking, the team asked a different question: what if working in a restaurant was dangerous?
That idea came while the developers were still at university, and the roguelite structure only appeared later when they realised their original plans were too ambitious for the time they had. The roguelite structure came from a practical development problem, but it ended up becoming an important part of the game.
To answer this, I need to go back to the beginning. We started Sous Raccoon while we were still at university, as our graduation project. The brief was to make a game for a competition, and it had to be unique. The concept we landed on was a restaurant game where you don’t cook at all. Instead you do everything else, including protecting the customers from monsters. The core question was: what if you worked in a restaurant full of danger? Once we had that, we thought, if you’re fighting monsters, your character should get stronger too.
Our first plan was a series of levels where players gradually upgrade, like a lot of other games. But our advisor warned us we probably wouldn’t finish in time for the competition. So we looked for another solution, and that’s when we found roguelites. We borrowed the parts we needed, which kept the game fun while letting us focus much more on what happens inside each level.
The decision gave the team another problem to solve. If every restaurant was going to throw different challenges at the player, simply changing the scenery wouldn’t be enough. The layouts, enemies and objectives had to affect how players actually approached each shift.
Making every restaurant play differently
The devs didn’t want one restaurant to feel like another with a different coat of paint. Instead, each one was built around a different skill or problem. Some restaurants make getting ingredients difficult. Others make protecting customers the bigger problem.
The key was separating which player skill each restaurant leans on. In some, ingredients are easy to deliver, but you have to run a lot more to protect customers. In others, defending is easier because there are fewer entrances, but the ingredients are much further away. Some have only a single entrance, so they’re easy to defend, but the tables are spread apart, which makes healing and serving harder.
And especially in the later stages, each restaurant has its own unique mechanic and its own kind of difficulty. In the final stage, for example, some restaurants have moving floors, some have water covering the floor that slows you down unless you jump over it, and in some you can even rearrange the layout yourself.
That variety also feeds into the game’s biggest balancing challenge. Sous Raccoon can have changing layouts, different enemies, random events and an increasingly angry Chef all happening during the same shift.
It would be easy for that kind of design to become frustrating. The team needed a way to decide when the chaos was still fun and when it had simply gone too far.
The customers are the game’s balancing point
Phongsatorn’s answer to that problem is surprisingly simple: watch the customers. As long as players can keep customers from piling up, the team considers the situation manageable.
Everything in the game revolves around the customers. Our rule for how much chaos is too much was simple: under normal play, customers should never overflow the restaurant, even with monsters around. Players can always hit monsters and heal customers, so no matter how many monsters show up, if customers aren’t piling up, the situation is still manageable.
Seated customers also have plenty of help to survive: the assistants (in Solo mode), healing perks, and barricades. That’s our main benchmark for whether a player can still cope, setting aside the player’s own mistakes. That said, the game is designed to be very hard, so we added selectable difficulty modes. That way, less experienced players don’t feel like they can’t keep up, while every mode still offers a real challenge.
The Chef adds another layer to that pressure. You’re not just trying to survive the shift. You’re also trying not to make your boss angry enough to fire you.
That fits the original idea of Sous Raccoon: you’re an employee, and the restaurant isn’t just a battlefield. You have responsibilities, and the player needs to work out which problem is most important at any given moment.
When bad luck isn’t really bad luck
The game has enough random elements that players can sometimes feel like a run has gone wrong because of circumstances outside their control. Phongsatorn explains that the team wanted to avoid that feeling as much as possible. The idea is that the chaos should be something players can read and react to, rather than something that simply happens to them.
It goes back to the original concept: you’re an employee. To make that feel stronger, we used the anger of the Chef, your boss, to communicate it more clearly. As for making players feel responsible, the game does have a lot of variables, including the scenario, which players choose themselves.
Sometimes players might feel they just had bad luck. But in reality, every variable always gives a warning sign beforehand. Our job is to design it so players see the chaos as a puzzle to solve, where they have to get their priorities right about who matters most in that moment.
Once co-op came, it created a completely different balancing problem. The player character is already capable of doing almost everything alone. The team couldn’t simply make the character slower or weaker to compensate for having more players, especially when movement itself was designed to be fun.
Adding co-op without taking away the fun
Getting up to four players into the same restaurant turned out to be one of the team’s biggest development challenges. Rather than making the character less capable, the developers made the restaurants more dangerous.
Adding co-op was the craziest and most headache-inducing decision we made, but it turned out better than we expected. Balancing co-op is really hard in a game where your character is already very capable and can do everything alone. And there was no way we’d make the character’s movement worse, because that goes against what we wanted from the start.
We put a jump into a top-down game because we wanted just jumping and spinning around to be fun on its own. So instead, we greatly increased the number of monsters and added a few more customers, just enough that the kitchen doesn’t explode. No matter how many players there are, there’s still only one chef cooking, and that actually makes the core idea of protecting customers even clearer.still only one chef cooking, and that actually makes the core idea of protecting customers even clearer.
That last detail is a nice fit for the game’s original concept. Even when there are four players running around the restaurant, the job isn’t to become four chefs. There’s still one person cooking, while everyone else is trying to keep the restaurant from falling apart. The monsters themselves follow the same general philosophy and are tied into the game’s food and stage themes.
The Garlic Crab was almost too good at its job
The devs describe the monsters as being themed around ingredients, with the stages adding another layer to their designs. As a result, the game is given a room for enemies such as Tomato Shark and Potato Bob, which can be funny to look at while still creating specific problems for the player.
Our monsters are themed around the game’s ingredients (except the bosses), a bit like the Gourmet World in Toriko. Every stage also has water in it, so most of our monsters are based on that stage’s theme too. The design depends on what we pick as the base. For example, the Tomato Shark combines the sea theme with an ingredient, and Potato Bob takes the idea of a root vegetable living underground and turns it into a mechanic. As for whether anything didn’t work: yes, but we didn’t cut it.
We chose to fix it and nerf it so it stayed playable. One example is the Garlic Crab. You have to bring it an ingredient before you can attack it, which sounds simple, but in actual play it turned into something close to a mini boss. To nerf it, we gave players more time before it needs the ingredient and limited it to only two on screen at once. Why not just remove it? Because we love every one of our monsters, we want players to see them, and we feel each one does its job well (messing with the player). Sometimes a little too well.
The Garlic Crab is a good example of something that can look perfectly reasonable during development and become a very different beast once real players get their hands on it.
They didn’t throw the creature away but adjusted it until it could remain in the game without taking over the entire shift. The willingness to change things based on how people actually play Sous Raccoon has already produced one of the team’s more unexpected changes.
One player changed the way the game is played
Early Access has given the developers plenty of feedback, but one request in particular had a bigger impact than they expected. It wasn’t a new restaurant or a new monster. It was a controller. The game wasn’t designed with controller support in mind until a player discovered that it could actually work.
The player feedback that had the biggest positive impact on us was controller support. We’ve been PC players from the start and barely ever played games with a controller, so we didn’t support it at all. But one player tried the game on a gamepad by setting up their own keybinds, just to see, and it actually worked (thank you, Unity Input System). They had a great time and asked us to add proper support.
It was tough at first because our UX/UI wasn’t very controller-friendly, but we kept reworking it, and now we think it’s good enough to play without any frustration. Trying it on a controller ourselves felt fresh and gave the game a different feel, and we’re really happy with how it turned out.
It’s probably one of the better examples of why Early Access can be useful for a small team. The developers had been looking at the game from one perspective because that’s how they normally play games. A player approached it differently, found that the game already worked surprisingly well with a controller, and gave the team a reason to rethink that decision.
What started as a university project has clearly changed quite a bit since then. The roguelite structure wasn’t part of the first plan, co-op became a major balancing challenge, monsters have been adjusted after seeing how players actually deal with them, and even the way people control the game has changed.
Sous Raccoon is a game about saving a busy kitchen from total chaos. The devs dealt with plenty of chaos behind the scenes too, but they made it through and built something awesome. We’re super excited to share our full review with you soon!
Leave a comment