Built with Bezi, Plush Time is an ambitious social party game that re-envisions the genre to emphasize player agency as the main driver of the core game experience. Ahead of its Steam release in early-mid 2027, Bezi spoke with solo developer Matheus Suchy on his debut game.

Bezi: Indie breakouts seem relatively rare in social party games. What interested you about the genre, and what did you think Plush Time could do differently?

Suchy: A big part of the motivation was seeing how much the way people consume and share games has changed. There's a huge audience around what I'd call "friendslop" content — groups of friends playing together, creating funny, chaotic moments that end up as memes and TikToks and get shared in group chats.

I saw an opportunity to design a party game specifically around that experience, with major improvements. We wanted Plush Time to be faster and more immediately entertaining, so something funny or unexpected happens frequently instead of long stretches of downtime. A good session should produce moments that are funny even outside the game — something you could clip and send to friends, and they'd get it immediately.

B: At the same time, you didn't want those moments to feel random. How do skill and physics fit into that?

S: A lot of the current conventions of this genre were designed around creating suspense and giving everyone a chance to participate.

Instead of randomness, we're more interested in physics and player-driven interactions. You can make an amazing shot, launch your friend across the map, accidentally cause a chain reaction, or completely ruin someone else's plan in a way that nobody expected.

"I think randomness can and should be replaced, to some extent, by player-driven chaos. Instead of the game randomly deciding that something funny happens, the systems should give players enough freedom that funny things happen naturally."

Basically, I think randomness can and should be replaced, to some extent, by player-driven chaos. Instead of the game randomly deciding that something funny happens, the systems should give players enough freedom that funny things happen naturally. You can have a very skillful player make an amazing shot, launch your friend across the map, accidentally cause a ridiculous chain reaction, or completely ruin someone else's plan in a way that nobody expected.

That creates a nice balance where there's still unpredictability, but it's coming from the players and the game systems, rather than simply from a random outcome.

B:  Tell us more about how you thought about the physics and the mechanics of aim in your game.

S: A big part of this comes from wanting the gameplay to feel more player-driven. The aim aspect plays the biggest role in the board mode. The board is our take on a combination of Mario Party and something like Worms, where players move around a shared board but also have more direct control over their actions and interactions.

That gives us a lot more room to explore things like aiming, trajectory, positioning, and physics as actual gameplay skills. Instead of simply selecting an option and watching the game resolve it, players can directly control what they're doing and potentially outplay each other.

B: How do you balance skill expression with keeping the game approachable for people who may not normally play competitive games?

S:  I think a good example of what the balance that we're aiming for is Mario Kart. With Plush Time, the basic controls and objectives should be easy to understand, so someone can jump in with their friends and immediately have fun. But underneath that, there should be enough depth in things like aiming, movement, positioning, timing, and understanding the physics that more experienced players can consistently perform better.

Another important part of that is rubber-banding, especially in the board mode. We don't want someone who gets ahead early to simply snowball and make the rest of the game irrelevant.

A big part of the solution is giving the other players tools that let them actively fight back. For example, players can get offensive items like bombs and landmines, which can be used to attack or disrupt the player who's currently in first place. That creates a natural dynamic where the winning player starts attracting attention from everyone else. If you're in first, you're not just racing against the board anymore — suddenly everyone has a reason to mess with you.

And honestly, that's also just fun. Teaming up to troll a friend who's running away with the game creates a really funny social dynamic, and a huge part of what makes this genre enjoyable.

B: The Plush Time demo has 9 mini-games, and the final release is set to have around 30 mini-games. That’s a lot of mini-games! Tell us about your ideation process. How do you decide which ideas make the cut?

S: This is actually where Bezi shines the most for us. We have a very fast prototyping process; I can come up with an idea for a mini-game and go from that initial idea to a playable prototype that we can actually playtest in a single day.

That makes it much easier to experiment. We can try an idea, play it with the team, and quickly figure out whether the core mechanic is actually fun before spending a lot of time on it. If it works, then we can start investing in the art, juice, sound, polish, and additional mechanics. If it doesn't, we can move on without having spent weeks building something that ultimately wasn't fun.

"One of the biggest things we've learned is that a mini-game can be fun as a standalone activity, but still not work particularly well as a social party game."

One of the biggest things we've learned is that a mini-game can be fun as a standalone activity, but still not work particularly well as a social party game. One example is a prototype we made called "No More Olives." We had a prototype called "No More Olives": all the players sat on a giant pizza while olives spawned around them, and whoever threw the most off won.

The mechanic was perfectly playable, but public playtesting showed there wasn't much reason for players to interact. Everyone was doing their own task next to everyone else — you couldn't really interfere with your friends.

That's become one of the biggest criteria we use when deciding whether a mini-game is worth keeping. After playtests at several events, the pattern was very clear: the mini-games that get the strongest reactions have the most direct player interaction, especially when there's elimination or a threat that gets passed between players.

"That's become one of the biggest criteria we use when deciding whether a mini-game is worth keeping… The mini-games that consistently get the strongest reactions tend to be the ones with the most direct player interaction."

BombTag is a good example. One player starts with a bomb and has to pass it on before it explodes. Suddenly everyone is watching everyone else — you can chase a friend, force them into a bad position, fake them out, or deliberately target someone. As the timer runs down the whole group gets invested, and there's usually a huge reaction when someone gets eliminated. You're not just chasing a high score; you're actively trying to screw over your friends, and they're doing the same to you.

B: This must be a deceptively complex game to develop. How did you manage your time across the project, across networking and core game issues, vs. development on individual mini-games? How long did it take overall?

S: Plush Time has been in development for about four years, mostly solo. It started as my college graduation project, which won four awards — Best SFX, Best Gameplay, Best 3D Art, and Best Pitch — and that gave me the confidence to keep going. Those four years haven't been steady content production. We've discarded a lot of work, removed whole mini-games, and gone through different art styles, and that iteration is what got the larger commercial game that it is today.

One of the biggest things that made the scale manageable was building the game's architecture specifically around the idea that we're going to have a lot of mini-games.

I created a MiniGame Manager architecture where individual mini-games inherit from a common base and automatically get access to a lot of the systems they need. Things like player spawning, point rewarding, player deaths, countdowns, starting and ending the mini-game, and other common functionality are handled by the shared architecture rather than being rebuilt for every mini-game.

That means when I start a new mini-game, I'm mostly focused on building the unique gameplay mechanic instead of spending time recreating all of the infrastructure around it.

The same philosophy applies to networking. We're using FishNet with a P2P architecture, and the networking systems are structured so that mini-games can inherit a lot of the generic multiplayer functionality as well. Things like player transform synchronization, animation synchronization, and other common networking behaviors are handled at the framework level.

That architecture has been really important because otherwise the development cost of every additional mini-game would grow enormously. If I had to individually implement all the fundamental systems from scratch for every mini-game, getting to 30 mini-games would be much less realistic as a solo dev.

"The goal is to build the infrastructure once and then make each new mini-game mostly about what makes that particular game fun and unique… This has been really important because otherwise the development cost of every additional mini-game would grow enormously."

B: Plush Time supports both local and online multiplayer, which adds another layer of complexity to every mini-game you create. How has networking affected the way you design mini-games?

S: This is one complication I don't regret. From the beginning, I wanted Plush Time to properly support both local and online multiplayer rather than treating local multiplayer as an afterthought.

One of our design rules has always been that all players should be able to fit within the same camera frame during a mini-game. That sounds like a small constraint, but it has actually been really useful. Because we design the mini-games around everyone being visible at the same time, the experience translates very naturally between local and online multiplayer. We don't need split-screen, separate camera systems, or completely different level layouts depending on how you're playing.

That also led to a feature I'm particularly proud of: local and online players can be mixed in the same match. Three people with controllers at one PC can play online with three people at another, and the game treats all six as players in the same match.

"From the beginning, I wanted Plush Time to properly support both local and online multiplayer rather than treating local multiplayer as an afterthought."

This is something that came from a problem I had myself. I often find it annoying when my girlfriend is at my place and we want to play something together with our other friends. Usually, you're forced into either having two separate machines, or playing a completely local co-op game.

I wanted Plush Time to solve that problem. If you're sitting next to your friends or your partner, you should be able to play together on the same machine and still join your other friends online.

The hardest part online has been physics, especially ragdolls. Players can get knocked into a ragdoll state and get back up once they come to rest. Locally that feels natural, but online, physics can differ slightly between clients, and with something as chaotic as a ragdoll, a tiny difference in force becomes a completely different trajectory after a few collisions. I'm still working on it, because I don't want to remove those reactions just because they're hard. They contribute too much to the game's personality.

B: How does Plush Time fit into your arc as a developer, and what comes next?

S: It's by far the biggest project I've worked on, and for four years I've watched it grow alongside me. We now have over 1,500 members on Discord and over 30,000 followers on Instagram, and seeing people share their favorite mini-games and ask when they can play has been incredibly motivating.

I've also learned a lot about listening to players without losing the original vision. Public playtesting has shown me things I'd never have discovered myself, but it's still my job to interpret that feedback rather than implement every request.

After release I want to move on to other projects, but I don't think release is the end of Plush Time. I'm exploring console ports, and I think there's an interesting future for it on mobile. For me, it's both a culmination of everything I've learned so far and a foundation for whatever I make next.

Plush Time does not use AI in any of its art. Wishlist Plush Time on Steam now.