Other Ocean’s 4 Penny Coffins Keeps Its Ripper Secret Without a Dedicated Server

Other Ocean has built asymmetric multiplayer before. Their earlier game, Project Winter, hides traitors among a group of survivors, but the traitors are almost beside the point: innocent players just need to finish their objectives and escape, anyone can attack anyone at any time, and identifying the hidden killers is optional. It plays closer to an action game with a twist than a mystery.

4 Penny Coffins, the studio’s new game set in 1888 Whitechapel, inverts that structure on purpose. One player is the Ripper, hunting in secret. Up to seven others are investigators, and finding the Ripper is the entire goal, not a side option. Each round runs through three phases, Hunt, Investigation, and a formal Conviction vote, and the shift toward a single, identifiable culprit let the team build something slower and more cerebral than their earlier game, closer to Werewolf or Among Us than to Project Winter. The multiplayer runs on Photon Fusion.

We talked to the team at Other Ocean about that design shift and what it meant for the network architecture underneath it, from choosing a topology to keeping the Ripper’s secret while still letting a good detective earn it.

Having the Finite State Machine (FSM) add-on for an out-of-the-box solution for synchronized state machines was a huge boon and allowed us to get rolling quickly.

The Interview

Other Ocean already has experience with asymmetric social deduction multiplayer through Project Winter. Could you introduce the team working on 4 Penny Coffins and explain how that prior experience shaped the decision to build another hidden-role game, this time set in 1888 Whitechapel? What did you want to do differently that the earlier project didn’t allow for? 

One aspect of Project Winter that is very different from 4 Penny Coffins is the way social deception fits into the overall gameplay. Project Winter is very different from a game like Werewolf or Among Us in that the hidden traitors are almost tangential to the innocents’ gameplay. Innocent players in Project Winter have to complete their objectives and escape, and so long as they are able to do those things, they don’t actually need to identify the traitors. Additionally, in Project Winter, any player can attack each other at any time, making for a more action-packed experience.  

4 Penny Coffins is much more like a traditional social deduction game in that the primary goal is to identify the hidden evil player, who is also the only one committing murders. This change in structure has allowed us to focus on more slow, cerebral gameplay for 4 Penny Coffins that lets you really feel like you’re piecing together the solution to a mystery. 

4 Penny Coffins puts one player in the Ripper role, secretly hunting while up to seven investigators try to expose them using shared evidence. Hidden-role games create a specific networking problem: some information has to reach only one client while the rest of the world state stays consistent for everyone else. When did you realize this was going to be the central technical challenge, and how does your authority model handle it? 

One particular benefit of the design of the game is that it doesn’t actually do any individual player much good to know exactly who the Ripper is. A hacker exposing who the Ripper is to themselves certainly would give them a leg up, but it’s effectively as good as seeing the Ripper transform before your very eyes if a Ripper is uncareful. In either case, you’ll know who the Ripper is with 100% certainty, but it will still be entirely up to you to convince the rest of the players that this is the case through evidence, and “I know because I am a hacker!” is going to be the kind of testimony that gets you reported. If you lie about the evidence you’ve collected to cast suspicion on the exposed Ripper, all you do is cast suspicion on yourself because it won’t line up with evidence others had collected.

Because of the above, and because the game is intended to be played primarily with friends, and isn’t all that competitive, the risk of exposing the Ripper on the client side didn’t outweigh the benefits of using the shared topology, so long as the Ripper maintains state authority over the things that are strictly specific to the Ripper.

You built the game on Photon Fusion. Given it supports online multiplayer up to eight players alongside a solo investigation mode, which Fusion topology did you settle on (Shared, Host, or Dedicated Server) and what made it the right fit for a game where one client’s information has to stay hidden from the rest of the room? Did you evaluate other networking approaches first, including whatever Project Winter used? 

We settled on Fusion’s Shared topology for the reasons explained earlier – it gave us the right balance while still ensuring the Ripper maintains state authority over the things that are specific to the Ripper. 

Each round runs through three phases: Hunt, Investigation, and a formal Conviction phase where players vote on a verdict. How did you architect the transitions between these phases so every client stays in lockstep, and were there specific problems keeping the Conviction phase’s vote and verdict logic authoritative and resistant to tampering? 

We use the Finite State Machine (FSM) add-on for keeping track of the phases, where each phase is a separate state. We wanted to be able to support completely rejoining if possible, so we made sure that anything that is networked is stateful, stored in networked properties, and scoped to the appropriate objects that should have authority over that behaviour. We do use the shared topology, but each player has authority over their own votes. They could certainly tamper with their own votes, but it feels like it would just be easier to change your vote through the intended UI.

The master client has authority over the session state machine, so it just responds to the OnChanged events on the players’ votes, so a verdict can be determined by the master client once the votes are in. It was quite a smooth process all around, especially due to our use of the FSM add-on.

Your marketing describes evidence that “can be faked” and trust that’s “earned slowly and lost instantly.” That implies interactive, sometimes falsifiable clue objects scattered across crime scenes that investigators pick up and compare. How is evidence represented and synchronized across clients, and what trade-offs did you make between giving the Ripper tools to plant false evidence and keeping the system fair from a networking standpoint? 

The networked objects representing the items in-game are owned by the master client. Each item has particular data that is associated with it and is populated or updated by requests to the master client. Since evidence items just expose data that would have been synchronized to all clients already, the master client can just provide the information as it is known at the time it is requested, such as is the case with collecting witness testimony. 

The master client synchronizes which players have been observed by which witnesses, and which witnesses have been bribed to add or omit players from their testimony, creating a complete picture of what information should be provided to a player when collecting testimony from a witness. For fully falsified evidence, a request is sent to the master client to produce an item with the bespoke data. 

The game uses dynamic role assignment, so no two sessions play out the same way. Walk us through what happens technically between players finishing matchmaking and the first Hunt phase starting. How are roles assigned and communicated, and did you run into problems with late joiners, disconnects, or players dropping mid-investigation? 

I’m afraid the answer to this one is just “we used FSM” again, haha. For most of the game’s development, this was pretty straightforward for this very reason.  

The roles players have are states with associated data which tell it which character rig to load when hitting OnEnterState, and we tell the players to switch to whichever profession state they’re going to be when entering the first hunt phase. The use of the state machines in general has been very useful for having clear boundaries for managing the lifecycle of objects. 

Where it got complicated is when we added the hub world players are sent to before and after matches. Because this is a whole new scene, and because we allow the players to choose which profession they’d like to play in the hub world, it created a complication in that we needed that information to be synchronized and be able to persist across scene loads, since we load whole new player objects in each scene (again, to be good stewards of object lifetimes and dependency scopes). We were able to achieve this with a master client spawned object which is simply marked to not be destroyed on load. 

Can you share a specific bug or problem that only showed up once you had real players testing online? Something related to desyncs, an information leak about the Ripper’s identity or evidence state getting out of sync between clients? How did you track it down, and what changed as a result?  

For most items, any “desyncs” were more of an issue of some local NullReferenceException occurring on the visual representation of an evidence item, leading to it failing to populate itself with whatever images or text was necessary to present the evidence. These were more often just caused by dependency injection issues rather than a problem with the network state. These issues are usually fairly easy to isolate in singleplayer, so we can set breakpoints and walk through the code without having to worry about timing out and disconnecting while the breakpoint pauses execution. In some instances, we’d do something silly like forget to despawn any previously existing items when starting a new round, leading to ID collisions with how we identify item instances. 

The trickiest bit was probably more related to the jobs system, since we needed to ensure that each client has the same jobs on their boards, and that we’re updating each board accordingly when jobs are taken, since we limit each job to one player. Populating and synchronizing the initial state for the jobs required a bit of trial and error, but mostly just due to how the network data becomes an abstraction for the identifiers used locally to retrieve the correct data, and the complications that brings. 

Now that you’ve shown 4 Penny Coffins at Gamescom 2026, what has playtesting told you about how the networking holds up under real conditions with strangers online rather than friend groups? What advice would you give another small studio building a hidden-role or social deduction game? 

My recommendation for other small studios building a game like 4 Penny Coffins is to ensure that you develop a solid sense of the gameplay structure before diving headfirst into implementation! There are a lot of moving parts to any online multiplayer game, and those parts are compounded even further by the social systems required for a social deduction game. Having a solid sense of how your game will function (and what games you want to pull inspiration from) gives you the best shot of preventing your team from having to rip up floorboards if you have to change directions, though of course, some iteration is necessary no matter what. 

Conclusion

With 4 Penny Coffins, the networking held up because the design question got settled first. Narrowing the mystery down to one culprit and one set of crimes meant the team could reason clearly about what actually needed protecting, and the answer turned out to be smaller than it first looks: not the Ripper’s identity itself, but the evidence trail that turns a guess into a conviction. That single insight is what made Photon Fusion’s Shared topology, with the Ripper holding State Authority only over Ripper-specific state, enough to carry the whole premise.

The Finite State Machine add-on did a lot of the work other teams often end up building by hand, representing round phases, player roles, and persistence across scene loads as networked states rather than a pile of custom flags and event listeners. Treating most “network bugs” as ordinary code bugs first, before assuming the network layer was at fault, kept the team’s real debugging effort focused on the places that needed it, like keeping shared job boards in sync across every client.

With the game now ready to wishlist, Other Ocean has a working answer to a problem specific to hidden-role games: how to keep a secret without needing a fully authoritative server to guard it. Their answer wasn’t more infrastructure. It was making sure that knowing who did it was never the same as proving it.