Highstreet: Calamity is a city-scale slice of Highstreet Market’s next-generation MMORPG. The team released it to the player community to test core features like combat and progression.
At this stage, the team is focused on scaling the multiplayer experience. During development, they encountered technical bottlenecks, but through careful profiling and iteration, they identified and addressed the root issues. Here’s how they did it.
How does a studio scale multiplayer development while overcoming technical challenges?
When they were starting to set up their networked game, the team faced two major challenges: compute and rendering inefficiencies.
“On the compute side, our biggest challenge was to handle computation efficiently. This is especially true for our server, that's tasked with simulating the world,” says Jack Qiao, CTO at Highstreet. “As we added more players and network entities, the server struggled to efficiently process all of them.”
On the rendering side, building large, immersive VR worlds is difficult. “VR demands an engaging environment with plenty of objects and points of interest for players to explore,” Qiao explains. “But standalone VR hardware has limited GPU power compared to modern PC GPUs, which restricts what we can render.”
To maintain quality, the team carefully designed scenes to look good from every angle while balancing performance limits inherent to VR.
Hit 72 fps on the most optimized game areas
Reduced the number of Scriptable Render Pipeline (SRP) draw calls from 80 to five
Decreased the number of triangles in a single mesh from two million to 500,000
The team first built a custom server on top of Mirror’s transport layer to handle data flow and game logic. “At the time, most networking tools were designed for casual mobile titles, not large-scale MMOs, so we had to create our own,” says Omar Sleam, Highstreet’s head technical architect.
When Unity introduced Netcode for Entities – a production-ready framework built for performance and massive-scale games – the team saw an opportunity to transition to Unity’s Entity Component System (ECS) and Netcode for Entities. Designed with scalability in mind, the framework introduced chunking, which breaks complex game data into smaller, more manageable units – something the team viewed as essential for their MMO.
“With Netcode for Entities, data is only sent to players within range instead of broadcasting to the entire server,” Sleam explains. “It’s also multithreaded, which makes server operations far more efficient.”
Beyond networking, the team also developed a behavior tree system built entirely with ECS for Unity. Prior iterations made it difficult to implement generic features – particularly those related to flow control. The custom ECS for Unity-based behavior tree solved this limitation, providing flexible, reusable tools without compromising performance.
The team designed the system to operate seamlessly in a networked environment, giving the flexibility to run behavior trees on the server, client, or both. This let them offload non-critical behaviors to the client, improving performance while keeping centralized control for core game logic.
To manage the game’s session-based structure, the team leaned on Unity’s multiplayer services ecosystem. Multiplay Hosting enabled dynamic server allocation, which was ideal for the game’s session-based nature. “Automation reduced our DevOps burden and let us focus on building the game itself,” Sleam says. Matchmaker was used to group players based on various factors such as settings and location, helping ensure balanced and low-latency matches.
Unity Lobby powered the party system so players could form and manage groups before joining a game session. Friends was integrated with Lobby to maintain parties across different servers, enabling players to stay connected with minimal implementation effort and without requiring a custom backend.
Together, these tools provided a complete multiplayer backbone – covering hosting, matchmaking, party management, and social systems – while keeping the implementation lightweight, scalable, and optimized for high-performance gameplay.
While the team experienced a steep learning curve during their transition from GameObject-based design to ECS for Unity, productivity improved significantly once they onboarded.
“ECS for Unity reduced a lot of overhead – partly due to its architecture, and partly because we shifted to a top-down design approach,” says Qiao. “Unlike GameObjects, which often led to duplicated logic unless carefully architected, ECS for Unity enforced modular, component-based design. This naturally promoted cleaner, more maintainable systems.”
The team shared that one of the biggest benefits with ECS for Unity is how easy it was to handle game design changes. “In the old system, changes often required touching multiple MonoBehaviour scripts. With ECS for Unity, many changes can be made by simply adding or removing components, since behaviors are driven by systems linked to those components,” says Qiao. “Overall, modifiability and scalability have greatly improved with ECS for Unity, and it’s made our development pipeline much more efficient.”
The team also tackled a major challenge around game architecture. Unlike traditional software, game logic depends not only on code but also on where that code lives. For example, attaching a rotation script to a car wheel simulates movement, but applying the same script to a skybox can drive a day-night cycle. This spatial and hierarchical dependency meant that the team needed a way to architect systems not just in code, but also in terms of placement and hierarchy.
To address this, Mohamed Hamdy, a software architect on the team, devised a creative graph-based approach for ECS for Unity. This method allowed the team to design entities, components, authorings, and systems in a visual, modular way, while also defining their placement and setup. By doing so, small reusable blocks of code could achieve very different purposes depending on where they were applied.
The system was later extended to integrate not only ECS for Unity entities but also MonoBehaviours, GameObjects, behavior trees, and Unity’s Behavior Graph. Using a combination of Lucidchart diagrams and Excel sheets, the team mapped out and validated the entire game’s architecture in a clear and efficient way. Looking forward, they plan to build a dedicated Unity tool to make this architecture method fully visible in the Editor, with the ability to validate it against the actual implementation.
After migrating from their custom server, the team initially adopted a full ECS for Unity physics approach. They chose this method for its efficient data handling and scalability, especially on the server side, but also for certain CPU-side rendering optimizations.
“One key advantage is in handling skinned mesh animations via vertex animation, which ECS for Unity can process far more efficiently than traditional bone-based systems,” says Alwin Joshy, technical artist at Highstreet Market. “However, in VR, both the CPU and GPU are constrained, and to fully benefit from ECS for Unity-based animation, we first needed to reduce scene complexity to free up resources.”
Due to the game’s complex animations, their workflow evolved into a hybrid system combining ECS for Unity with MonoBehaviours through the Entity Component System (ECS).
To visualize multiple characters on the screen, they offloaded some of the processing to GPU. Since it was clear that the CPU would overload from the network and logical aspects of the game loop – they employed the Rukhanka Animation System.
“For physics, we built everything on the main physics world, syncing all physical entities between server and client,” explains Sleam. “It was complex at first, as the server synchronized every physical entity. Then we explored having multiple physics worlds and faced a choice between continuing with a local physics calculator in ECS for Unity or doing local physics in MonoBehaviour.”
MonoBehaviour allows integration with third-party VR tools like Hurricane and Freehand, which enable realistic physics interactions such as pressing buttons or ensuring that hands don’t pass through walls. ECS for Unity, on the other hand, required the team to build these systems from scratch as there were no available ready-made 3rd party tools on the store as in MonoBehaviour.
“In the end, we used MonoBehaviour for client-side VR interactions like hand collisions to ensure responsiveness and immersion,” says Sleam. “Meanwhile, server-side physics handled critical gameplay interactions – such as hitting a monster – for validation.”
This hybrid approach balances immersion with security, running gameplay-critical collision detection on the server to prevent cheating while managing local, less-critical interactions on the client.
While ECS for Unity and Rukhanka open up possibilities for scale – such as supporting thousands of animated characters – one of the team’s biggest challenges in VR has been performance optimization, especially under tight CPU/GPU constraints.
“Unlike traditional games, VR fully taxes both CPU and GPU,” explains Joshy. “Offloading isn’t always an option unless the scene is highly optimized.”
After building the project, they first ran a preliminary performance check using the OVR stat tool on the Meta Quest to identify heavy areas or frame drops. Then, they created development builds and connected the Meta Quest to the Unity Profiler to analyze CPU-GPU data transfer, texture memory usage, rendering hierarchy, and draw timing.
“To improve performance, we’ve recently focused on reducing draw call breaks by manually controlling rendering. Lighting was a major challenge – while we initially baked lightmaps with toon-style compression to reduce size, mixing lightmapped and non-lightmapped objects caused shader variant issues,” says Joshy. “To resolve this, we abandoned lightmaps entirely and adopted a fully environment-lit toon shader. This gave us more consistent performance and better control over rendering.”
The team also used spotlights with stepped falloff and kept their shader variants minimal – just one cel shader for opaque and transparency clips, and possibly grass. They manually controlled draw order: opaque objects at layer 1, transparent objects at 2, and clip objects at 3. This helped reduce draw call breaks by keeping batching consistent.
“To catch hidden issues that split draw calls, we relied heavily on the Unity Frame Debugger to verify batching and draw order,” Joshy continues. “GPU profiling was also one of our main tools for optimizing rendering and reducing draw call overhead.”
As the team scaled development, they encountered rendering challenges, especially in the arena scene where combat takes place.
“Our goal is to maintain 72 fps on devices like the Meta Quest 2, but even with triangle counts under 500,000, we’re hitting performance issues,” says Joshy.
They’re using the SRP Batcher to reduce GPU shader switches, but in standalone VR, GPU constraints are much tighter than on PC. “We’ve found that even scenes with two million triangles render smoothly – if it’s a single mesh with a single material. But our game’s open, vertical environments make that kind of simplification impractical,” says Joshy.
To improve performance, the team focused on minimizing draw calls by:
Custom mesh baking by the art team
Grouping assets into sub-meshes to balance batching with material flexibility
Chunking the world and generating chunk-level LOD rather than per-asset
Streaming chunks using an ECS for Unity-compatible system
Using LOD systems alone helped reduce scenes from around two million triangles to 500,000.
This approach sacrificed some flexibility and increased workload for the artists, but it was necessary given the hardware limits – especially on devices like the Meta Quest 2, where developers couldn’t upgrade the GPU.
“Ultimately, minimizing draw calls from 80 to five is our biggest win,” says Joshy. “We’re restructuring content and workflows around that – even if it limits material variety – because it’s the most viable path to stable VR performance on current hardware.”
As the team develops their VR MMORPG, they continue to focus on what they consider to be the most critical consideration – scaling, both from architecture and graphics perspectives.
“If you’re aiming for a large-scale MMO from day one, you’ll need ECS for Unity to handle high entity counts and concurrent networking. If you don’t have a very detailed vision from the start, scaling incrementally works well too,” says Qiao. “We initially took a “0 to 100” approach, optimizing early for peak scale. In hindsight, we overbuilt infrastructure too soon, consuming resources that could’ve gone toward gameplay and content.”
From a graphics standpoint, the team is cognizant of the pros and cons of VR. “Organic, soft meshes consume significant compute resources and don’t perform well in VR. Our game uses a toon style with organic elements, which limits our graphics budget for other areas like characters or environment design,” says Qiao.
Overall, the team recommends opting for cleaner, low-detail, tech-style environments to maximize performance in your VR game. “With a cleaner scene design and worldbuilding, you’ll be able to have more graphics, and resource and graphics budget for other things like character design and structural design. It’s key to design with performance in mind,” says Qiao.
Start creating games that compete with, and surpass the quality and success of big studio releases with help from powerful tools, support, verified partners, and a vibrant community.
