Riptide Interactive’s Tidal Nexus Online Pushes Photon Fusion Into MMO Territory

Riptide Interactive is three people. Arda Kirman writes the game’s networking and systems code, Onur builds the art and the custom shaders that make an entirely underwater world look and feel alive, and Utkan, a lawyer by training, handles the lore, the audio, the website and everything else outside the engine. Their game, Tidal Nexus Online, is a submarine-based open-world MMO set on the ocean planet Aquathar. It launched on PC on August 3rd.

There was no smaller version of this project first. It was never a single-player game that grew into an MMO, and there was never a co-op or session-based PvP version of the plan either. Arda had spent years building multiplayer systems for mobile simulator games on Photon’s infrastructure, and once he was convinced the tech could carry a persistent world at this scale, he resigned to build it. The company was self-funded from day one: motorcycles were sold, a law practice was mostly set aside, and friends contributed assets for free because they wanted to see it finished.

What came out of that is a server built to keep tens of thousands of NPCs, resources and events running continuously, using a custom Area of Interest system layered on top of Photon Fusion 2.1. Rooms are designed to stay alive for months at a time, and the team has already tested 264 real players fighting in the same interest area, with 400 targeted at launch and 600 as the next milestone.

Photon Fusion didn’t hand us an MMO in a box. It gave us a high-performance state-synchronization foundation, and Photon’s team helped us reshape it around a persistent world it was never originally designed for. That’s what let three people on a minimal budget put hundreds of players into the same fight on a single server, at a scale that would otherwise have been completely out of reach for us.

Arda Kirman, CEO Riptide Interactive

Interview

Could you introduce Riptide Interactive and explain how the original idea for Tidal Nexus Online developed into an open-world underwater MMO? What kind of player experience did you want to create that you felt was missing from other online games?

Riptide Interactive is a small independent development team building Tidal Nexus Online, a submarine-based open-world MMO set on the ocean planet Aquathar. There are three of us.

The journey starts with me, Arda. I’ve been a hardcore MMO player since childhood and I put an enormous amount of time and money into classic browser-based MMOs like DarkOrbit, Deepolis and SeaFight. Making a game like this was my dream project for years. Life got in the way, as it usually does, and instead I spent about five years building simulator games and their multiplayer systems for mobile, using Photon’s infrastructure. Even then I kept coming back to small prototypes of this exact idea, though none of them turned into anything serious.

I should be clear about one thing, because people assume otherwise. This was never a smaller game that grew into an MMO along the way. There was no single-player version of the plan, no co-op version, no session-based PvP version. It was going to be an MMO from the very first day. What finally made it real was fairly simple: after running my own tests, I became convinced that Photon had reached a point where it could actually carry a world like this. So I resigned to go and build it.

Onur joined not long after. He and I knew each other from the office. He’s a 3D artist with about a decade behind him and a particular talent for custom shaders and shader-based UI, which turned out to matter enormously in a game set entirely underwater, where light and depth and the water itself carry most of the atmosphere.

Our third co-founder, Utkan, came from outside games entirely. The three of us play in a metal band together, which is genuinely how we know each other. I sing, Onur and Utkan play guitar. The connection is even more roundabout than that: his wife and my wife went to high school together, and that’s how we met in the first place. He’s a lawyer by profession, with some music and web development background, and he started out helping us with small things almost like an intern. It was Onur who suggested we bring him in properly. As his contributions grew we offered him a full partnership, and today he handles more or less everything outside the engine: the website, all of the company’s corporate and legal work, every piece of audio and music in the game, the lore writing, and the wiki.

It’s worth being honest about what this cost, because I think that’s the real story of most small studios. The game earns nothing until it ships, so it was funded out of our own pockets. I sold two motorcycles to keep it going, one of them a Harley I’d had for years. Utkan effectively stopped practising law, and only takes the occasional case when the company suddenly needs cash for something. Our families and our wives backed us completely, and several friends made assets and contributed ideas for free, simply because they wanted us to finish it. Everyone did the work of three or four people for a long time.

There was one moment that changed our ambitions, and it wasn’t a technical one. Onur built a station dock, and it came out so far above the general quality level of the rest of the game that it reframed what we thought we were making. Once we’d seen that, we couldn’t unsee it. We extended the project and rebuilt the visual fidelity around that standard. That’s the point where Tidal Nexus Online stopped being a classic browser MMO rendered in 3D and started becoming its own thing, keeping the nostalgic feel of the games we grew up on while modernising them enough to hold a new audience. It’s had an effect we didn’t anticipate: old clans from those older games have found something like a home here, and they’ve brought a real energy with them.

We incorporated the company about a year ago, and the PC version launches on August 3rd.

What developed over time was the depth of the world rather than the genre. Starting from the core feeling we wanted, controlling a submarine, exploring an unknown ocean, running into other players in open water, we built outward into resource systems, factions, NPC ecosystems, territorial conflict, world events, trading, progression and large-scale PvP. Those systems ended up depending on one another, and each one pushed the world to be more persistent than the last. We wanted a place that keeps existing whether or not you’re logged in, where meeting another submarine can turn into a story.

There’s a second half to what we were after. The games I grew up on have aged badly, and over the years the genre drifted towards monetisation that treats players as something to extract from rather than something to host. That always struck me as a waste, because the underlying idea still has enormous potential. Nobody had given it a modern, honest treatment in a long time. So what we set out to build was that experience without the predatory structure and without the feeling that you’re playing something from fifteen years ago: the same sense of a shared, dangerous, persistent ocean, brought up to a standard that holds a player in 2026.

None of us imagined it would reach this scale. We set out to make a fairly simple MMO and finish something together. What came out is at a quality and stability we honestly didn’t picture at the start, and it was built by three people on close to no budget.

Persistent open worlds introduce very different constraints from session-based multiplayer games. Which technical requirements shaped the project earliest, and when did you realize that conventional object-by-object synchronization would not be practical for the world you were building?

The most important early requirements were server authority, a persistent world, a large traversable map, high player density in specific locations, and a world containing far more entities than any individual player could see or interact with.

To be honest, there wasn’t a single moment of realization for us. Because we knew from day one that this was going to be an MMO rather than a session-based game, we never really passed through the phase of treating the world as one large collection of conventional networked objects. A custom Area of Interest system was part of the plan from the very beginning. It’s one of the main reasons a project like this was feasible for us at all.

That distinction matters more than it might sound. Treating everything as a networked object is perfectly manageable in a session-based game, where a match contains a limited number of players and objects for a limited time. It becomes a completely different problem when the same server has to represent fifteen to twenty thousand NPCs, resources, interactable objects, missions, events and players continuously, for extended periods. Most of those entities are irrelevant to any given player at any given moment, and synchronizing them anyway is simply wasted work.

So instead of a turning point, what we had was a constant discipline: an entity outside a player’s interest area should exist with the absolute minimum amount of data, and should only become synchronized when it actually needs to be. That principle was there at the start, and we’ve kept optimizing around it at every stage of development. Separating the persistent representation of the world from the active networked representation seen by nearby players is what made the architecture scalable, and it’s something we revisited and refined continuously rather than discovering all at once.

There’s a practical dimension to this as well. With three people and no budget to speak of, we were never going to solve a performance problem by adding servers or hiring our way out of it. That constraint pushed us towards architectural answers rather than brute-force ones from the very beginning, which in hindsight was probably the most useful limitation we had.

You developed a custom Area of Interest system for the game. How does it determine what each player needs to receive, and how does its behavior change when players move from relatively quiet exploration into a densely populated combat area?

Our Area of Interest system is player-based. Each player sits at the centre of a three-dimensional volume, essentially a cube around them, and the entities that fall inside that volume are the ones that are relevant to that player. Relevance is decided individually for each player rather than broadcasting world state uniformly to everyone.

That volume is deliberately larger than what the player can actually see on screen. Because of the game’s fixed perspective camera, what’s rendered in front of you is only part of the picture. The submarine’s sonar works like a three-dimensional minimap, covering a wider range and directions the camera itself doesn’t show you. The interest volume corresponds to that sonar range, which means there’s a band where an entity is already relevant to the server and tracked for you even though you can’t see it on screen yet. That margin is what makes objects and NPCs resolve naturally as you travel, instead of popping into existence in front of you. Beyond that boundary, distant entities and NPCs simply aren’t synchronized at all, and since the vast majority of the world is outside any given player’s volume at any moment, that’s where most of the savings come from.

Pure distance isn’t the only rule, though. There are deliberate exceptions where gameplay relevance overrides spatial relevance. Party members are a good example: their positions are shared with you and visible on your map even when they’re far outside your interest volume. There are a handful of similar cases, and because the whole system is something we built ourselves rather than something we inherited, adding a new parameter or changing how a particular category of information behaves is straightforward for us. That flexibility has been very valuable during development. There are also a few cases where less important values are synchronized at a lower frequency, though that’s an exception rather than a general priority tiering system. For the most part, relevance is a yes-or-no decision rather than a graded one.

What changes between quiet exploration and a heavy fight isn’t the rule, it’s the load. Out in open water your interest set is small and fairly stable, and long stretches of the world simply never enter it. In a crowded combat area the same volume suddenly contains a large number of players and combat entities at once, everyone’s interest sets overlap heavily, and the contents of those sets change constantly as people move and fight. The system behaves the same way; there’s just far more inside the boundary and far more churn at the edges of it. That’s exactly why we test the dense case rather than the distributed one, because it’s the only version that puts real pressure on the design.

It’s worth separating this from the sector structure of the world, since the two are unrelated. The map is divided into thirteen sectors plus a battlezone, each with its own NPCs and harvestable materials, and players move into higher-level sectors as they progress. That’s a map and level design decision, not a networking one. The Area of Interest system works the same way regardless of which sector you happen to be in.

The world can contain tens of thousands of NPCs and interactable entities without representing each one as an active GameObject or continuously networked object. Could you explain how the global-time and procedurally generated path system works, including when an entity transitions from lightweight world data into something that must be instantiated or synchronized?

One of the most important architectural decisions was accepting that an entity doesn’t need to exist as an active Unity GameObject simply because it exists in the game world.

A distant entity can be represented as data rather than as an object: an identifier that also acts as the seed for its procedural path, its type, its movement parameters, and whatever persistent state actually matters. From that, combined with global server time, its expected position can be reconstructed at any moment. There’s no transform update, no animation system and no continuously synchronized NetworkObject behind it, just a very small background cost, with a handful of essential values kept in sync at a very low frequency.

Getting to that model involved at least one evening we’re never going to live down. We barbecue a lot at my place, Utkan runs the grill, and one night the three of us got stuck on a scenario: a torpedo chasing an NPC that’s moving along a procedural path, while the player who fired it is also moving. How do you resolve that cleanly from a seed and a timestamp? We argued about it for hours with the confidence that only comes from a few drinks, and eventually worked out that we’d wandered into something much closer to a three-body problem than a networking question. That’s fairly typical of us. We don’t drop a problem until we’ve understood it, even when understanding it turns out to mean admitting it can’t be solved the way we were trying. What it taught us was where the boundary actually sits. Reconstructing position from data works beautifully for predictable, independent motion. The moment two things start reacting to each other, they need to be real objects, simulated properly. That’s a large part of why the transition between the two representations is where all our attention went.

We also use some internal bookkeeping on top of this so the world can adjust how much attention it pays to a given region. Without going too far into specifics, the server has a sense of which parts of the world are currently populated, and entities in those areas are kept in sync somewhat more frequently than entities in an empty stretch of ocean, while still remaining pure data with no GameObject in existence.

The transition isn’t triggered by visibility. An entity entering your sonar range doesn’t need to be synchronized at all, because while it’s travelling along its procedural path its position can already be derived from the seed and global server time. What forces a real object into existence is interaction. The moment something pulls an entity off its path, it stops being predictable, and at that point it has to be instantiated, simulated in full detail and synchronized to the relevant players. When it stops being relevant, the state that matters is retained and the expensive representation goes away again.

The result is a world that feels continuously alive without requiring the server to actually simulate all of it at full fidelity. Most of Aquathar exists as inexpensive data most of the time, and only becomes a real object at the moment a player could actually perceive or interact with it.

On a related note, we also built a custom layer system on top of all this. It lets us place players into what are effectively separate worlds while they’re still on the same server. We use it for arena matches and for events like Tidal Royale, where a player’s interest can be redefined entirely and they simply stop receiving the data belonging to the world they came from. We won’t go into the implementation, but it illustrates a broader point. Fusion gave us a foundation solid enough that we could build systems like this around it rather than fighting it. A lot of what we’ve done is customization on top of what Photon provides, and the fact that it holds up under that kind of reshaping is a large part of why the project is possible at all.

Your Fusion rooms are designed to remain active as persistent servers for at least 24 hours. What problems only became visible during these long-running sessions, and what architectural or operational changes were necessary to make them stable?

Short multiplayer tests can be very misleading, because a lot of lifecycle problems simply don’t surface until a server has been alive for a long time. We’ve run five alpha tests, a beta, and a number of closed internal tests, and throughout all of it our world has essentially stayed up. We do a soft reset roughly every twenty-four hours to keep things like garbage collection healthy, and with that in place the world has remained live for stretches of up to three months at a time, interrupted only by updates.

That kind of uptime shifts your attention from immediate performance to cumulative stability. A small allocation, an uncleared reference, a duplicated event subscription, a timer that never gets removed, an object that doesn’t fully release: none of these look like anything during a thirty-minute test. Over weeks of continuous operation they turn into memory growth, longer garbage collection cycles, stale state and gradually degrading simulation performance. We ran into a fair number of these, and resolving them took real optimization work rather than quick fixes. In some cases the issue turned out to be on Photon’s side, and their team fixed bugs specifically for the situations we were hitting.

None of this stayed abstract for us. When something goes wrong on a server that people actually live in, you find out quickly. We’ve been woken up in the middle of the night by players phoning us directly to say something was broken. That’s a strange feeling the first time it happens, and it changes how you think about uptime. It stops being a number on a dashboard.

The practical result was that we had to become much stricter about ownership and cleanup. Every persistent system needs a clear answer to the same set of questions. Who creates this state? Who owns it? What happens when a player disconnects? What happens when an entity leaves interest? What happens when an event ends? Alongside that, we invested in longer soak tests, more detailed server metrics, explicit cleanup paths, and ways of detecting state that was staying alive longer than it should.

We were aware going in that Fusion wasn’t originally built for this kind of use, a room that lives for months rather than minutes, so we expected to have to work for it. The main lesson is that a persistent server is not simply a longer match. It demands a different level of lifecycle discipline, and that discipline has to be built into how you write every system rather than applied at the end.

You distinguish between values that need to be publicly networked and values that should only be sent locally to relevant players. What problem were you solving with this separation, and how much difference did it make to bandwidth usage or server load?

This is really a general problem of building an MMO rather than something specific to us. If you treat every piece of information as globally replicated state, your cost grows with both the number of entities in the world and the number of connected players at once. That’s a losing equation for a persistent world.

So yes, we do separate the two. Some values genuinely belong to the shared simulation: movement, health, combat state, anything multiple players need to observe consistently, all handled through networked properties. Plenty of other information only matters to one player or a small group, such as mission progress, contextual interaction data, local NPC details, UI-specific values and temporary event state. Not every piece of information in the world is publicly available to everyone. It’s delivered only to the places that actually need it.

There wasn’t a dramatic moment where we decided to do this. It happened the way most of our architecture happened. During optimization work it became clear at some point that this was simply the better way to structure things, and from then on it was a deliberate development choice rather than an experiment. Being three people on a small budget pushed us in that direction constantly. We couldn’t afford to solve problems by throwing hardware at them, so we tended to reach for the more efficient solution almost by default. Our whole process has been develop, test, verify, repeat, which meant both the server and the client were being optimized at every stage rather than at the end.

The important outcome is that network cost is no longer determined by the total amount of information in the world. It’s determined much more strongly by how much information is actually relevant to each recipient. We’re not ready to share an exact percentage, but the bandwidth we’ve measured under this model is very low relative to how much is happening in the world at any given moment.

On server load the effect is just as direct, even without a public number attached to it. Under heavy load our ceiling is CPU rather than network, and keeping irrelevant information out of the shared state is one of the main reasons that ceiling sits where it does. Without this separation, the dense combat testing we’ve been able to run wouldn’t have been possible at all.

You have already tested 264 real players fighting inside the same interest area and are targeting at least 600 concurrent players per area. How was that test structured, which performance metrics mattered most, and what bottlenecks still need to be investigated before you can validate the higher target?

An important distinction for us is that 1,000 players spread across an entire map is not equivalent to 100 or 200 players concentrated in the same place. Sparse distribution and dense concentration are completely different technical problems, and only one of them is actually hard. So we deliberately designed our testing around the harder case: players gathered together in the same sector, fighting, moving, targeting one another and using gameplay systems simultaneously.

The 264-player figure comes from exactly that kind of dense same-sector scenario, and the server handled it stably. In load testing we’ve since seen 300 to 400 players concentrated in one sector run without issues, and we’ve pushed to around 530 concurrent clients, though at that point the server wasn’t running at the stability level we want to ship with. For a small team, seeing hundreds of players fighting in the same place on a single server is something we’re genuinely proud of, and it says as much about Fusion as it does about our architecture.

As for which metrics mattered most, the honest answer is that server-side CPU is the one we keep coming back to. We watch bandwidth, memory behaviour and the rest as a matter of course, using standard Linux-based tooling, but CPU is consistently where the ceiling appears first, largely because of Unity’s single-threaded execution model. That’s also the main bottleneck still standing between us and the higher target. Everything else has room in it.

As for 600, that’s still very much our target and we believe it’s reachable. But we don’t want to validate it by extrapolation. Our plan is to launch with an initial capacity target of around 400 players on a single global server, confirm that it’s genuinely stable in the hands of real players, and then push further with deeper optimization work. It’s also worth remembering that 600 players in one spot is an unusual demand by any standard. Most established MMOs don’t attempt that kind of local density either. We’d rather reach the number properly than announce it early.

You have described this as a use case that Fusion was not necessarily designed around. Why did the team choose Fusion 2 regardless, and where did you adapt your own architecture instead of trying to force the game into more conventional networking patterns?

Honestly, the most truthful answer is experience and trust. I’d spent roughly five years building multiplayer systems on Photon’s infrastructure before this project started, so it was the technology I knew best and the one whose limits I understood most clearly. When I was deciding whether this game was even feasible, Photon was the option I believed I could actually make work, and that’s also what made me confident enough to start at all. Over time the relationship became a close one, and we’re now in regular contact with Photon’s managers and engineers through calls, email and Discord.

We never really evaluated alternatives. Photon was a settled decision from the first day, and we’ve been on Fusion 2 from the start rather than migrating from an earlier version. Beyond familiarity, the technical reasoning was straightforward. We needed a strong state-synchronization foundation, server-authoritative simulation, and networking tools that let us build and test gameplay without first writing an entire networking stack ourselves. As a three-person team, building that layer from scratch would have consumed the project. 

At the same time, we knew our world structure wasn’t a conventional match-based Fusion project, and we didn’t try to close that gap by turning everything in the world into a NetworkObject. Instead we adapted our architecture around Fusion. We built our own persistent world-data layer, procedural entity representation, custom Area of Interest logic, targeted data systems, our layer system, and the transitions between lightweight entities and fully synchronized gameplay objects. Fusion handles real-time state synchronization where real-time synchronization is genuinely required. Our architecture decides when that requirement begins and ends.

We do use client-side prediction, though selectively, mainly to absorb specific situations like latency spikes. Since Tidal Nexus Online runs as a single global server hosted in central Europe, players connect from very different distances, so we’ve had to put a fair amount of work into handling ping and packet loss gracefully.

That division of responsibility has been essential, and in a sense the project became a proof of it. We think this game demonstrates that Fusion can be modular, agile and efficient enough to support something well outside its conventional use case.

The project involved close collaboration with Photon’s Fusion engineers around unusual requirements, long-running rooms, and bug investigations. Can you share a concrete example where that collaboration changed an implementation decision or helped resolve a problem that would otherwise have blocked development?

We’ve reported a few bugs to Photon over the years. Some were big, some were small. Singling out one decisive moment would misrepresent how the collaboration actually worked. It’s been continuous rather than episodic. What I can give you is a sense of the kind of thing that comes up, because most of it shares a root: our rooms live for months, not minutes.

One example. Every NetworkObject removal was quietly accumulating an error that wasn’t visible to us from the Unity side at all. With normal usage you’d never notice it, but once you’re destroying thousands of objects it starts to matter. That’s exactly the kind of thing a persistent world runs into and a match-based game never does. We reported it and Photon turned around a fix almost immediately.

Another, with a much bigger effect on our architecture. Long-running rooms need to handle reconnection to the cloud gracefully when a connection drops, and in Fusion 2.0 that wasn’t really solved for a use case like ours. Photon added a flag specifically for us so we could handle it, a change made essentially for one studio’s edge case. In Fusion 2.1 they went further and built a proper solution for connection loss, which is now part of the engine. Robert and Luke on Photon’s engineering side were enormously helpful throughout, taking our situation seriously and developing solutions for problems that were specific to us. We’re on Fusion 2.1 today, and that work is a direct part of why our server can stay up the way it does.

Plenty of others follow the same shape including some game breaking client to server security issues. Something that behaves perfectly in a session-based game turns out to have a slow-burning cost in a world that never shuts down, and the only way to find it is to run one.

What strikes us looking back is how quickly it all moved. We’d report something and get a fix, sometimes within a day. Alongside that we’ve had a number of direct technical discussions with Photon’s engineers and management, trading ideas about how to approach problems that fall outside Fusion’s typical use case. Through that, we think we helped demonstrate that Fusion can be pushed into territory it wasn’t originally designed for: a persistent, large-scale MMO rather than a session-based match.

For a small independent team, that kind of support matters far beyond the fixes themselves. We’ve built a genuinely close relationship with Photon at every level, and we’re grateful for how open they’ve been, both with the technical problems and with the broader journey of building this game.

Based on what you have learned so far, what would you recommend that another small team decide before attempting a persistent MMO with state-synchronized networking? Which decisions would you make earlier, or approach differently, if you were starting Tidal Nexus Online again today?

A few things, and not all of them are technical.

Start by defining the boundaries of persistence and synchronization before you produce large amounts of content. Decide what must exist continuously, what must be authoritative, what must be saved, what must be synchronized, and what can simply be reconstructed when a player approaches it. Those are five different requirements, and early in development they tend to get collapsed into a single networked object, which is a decision you pay for later.

Design for maximum local density, not just total concurrency. Six hundred players spread across a world and six hundred players fighting in one place are completely different problems, and only the second one will actually test your architecture.

Keep your scope clear and small. This is the advice we’d emphasise most. The process is long and the project is enormous, and building a plan you can actually execute is genuinely difficult. Move in small steps and take concrete results from each one, and evaluate progress on working prototypes rather than on concepts. Something running badly tells you far more than something described perfectly. Our own process has been develop, test, verify, repeat, at every stage.

Your team matters as much as your architecture. You need people whose work you can trust, who can invent a solution when something unexpected is required, and just as importantly, people you can keep working with through the problems and the arguments, because there will be both. Over a project this long, that’s not a soft consideration.

There’s a part of this nobody warns you about. Fairly early on we came close to signing a publishing deal that was quietly stacked against us, and at one point the other side proceeded as though paperwork had been signed when it hadn’t. We got out of it because one of us happens to be a lawyer and could argue the details properly. We were lucky. Without that in-house, we’d have signed it, and the game you’re reading about would probably belong to someone else. So when I say your team matters as much as your architecture, I don’t only mean who can write the code.

Talk to your community constantly. An MMO is built for the people who will live in it, so their input isn’t a nice extra. They’re your most natural testers and often your best source of ideas. We have an active Discord with over 1,500 members and the three of us are in there around the clock, talking to people individually. It has developed its own culture in a way we had nothing to do with. The game has its own memes and its own taunts. There’s an AI moderation system that has never worked quite right, sometimes banning people for nothing and sometimes missing the obvious, so “don’t taunt the aimod” became a running joke. When a clan wipes another clan in the battlezone, somebody posts “bz clear” in all chat. None of that was designed. It appeared because the community had room to make the game theirs, and it’s one of the things we’re most attached to.

It goes further than the game, too. Players have travelled to İzmir to visit us in person, and some of them came to my wedding. When people invest that much in something you’ve built, community feedback stops being a process and becomes something closer to an obligation.

The one thing we’d do differently is build observability earlier. Our data analysis work started later than it should have. Long-running server logs, tick-time measurements, bandwidth statistics, interest-set counts and memory tracking should be treated as core development tools from the beginning, not as something you set up when you finally need to optimize.

One last thing. We started this with no plan beyond finishing a game together and trusting each other to do our part. Along the way we’ve had support we never expected, including government grants and the right to open an office in a technology park. If you’d told us at the beginning that any of that would happen, none of us would have believed you. So the honest advice is that you can’t plan the whole arc. You can only keep taking the next concrete step and stay worth working with.

The biggest lesson overall is that MMO scalability doesn’t come from optimizing one enormous system at the end. It comes from thousands of small architectural decisions that keep unnecessary work from entering the system in the first place, and for a small team, from finding partners like Photon who are willing to come along on that journey with you.

Conclusion

Tidal Nexus Online is a reminder that MMO architecture is mostly a series of small decisions made early and enforced consistently, not one big system built at the end. Server authority, a custom Area of Interest system, and the separation between publicly networked and locally relevant data were all decided before the team wrote much content, and every optimization since has been a variation on those same three ideas.

The team’s constraints shaped the outcome as much as their technical choices did. Three people with no budget for extra hardware couldn’t scale their way out of performance problems, so they were pushed toward efficient architecture from day one. That same scarcity is why the studio tests dense combat scenarios instead of just raw concurrency, and why a lawyer ended up reading a publishing contract closely enough to walk away from it.

Riptide‘s collaboration with Photon also shows what a small studio can get from its engine vendor when the relationship runs both ways. Fusion 2.1’s connection-loss handling exists partly because Riptide’s persistent rooms exposed a gap the engine hadn’t hit before. That kind of feedback loop, bug reports turned around in a day, features added for one studio’s edge case, is not something every team gets, but it’s also not something that happens without years of direct, technical contact.

Tidal Nexus Online launched on PC on August 3rd, with an initial target of around 400 concurrent players per server and 600 still ahead as the next milestone to prove out properly rather than announce early.