Integrating the NI2S Simulation Engine into the TCW Node

This week, I took a big step forward in evolving the architecture of The Corporate Wars (TCW):
I integrated the NI2S simulation engine directly into the execution node.

It wasn’t just a simple code merge — it was a deep reconstruction. I had to rethink how to fit the engine into the modern .NET ecosystem while preserving its original essence and the extreme performance it had already achieved.

The Legacy: .NET Framework, AppDomains, and Shadows

The NI2S engine comes from a time when .NET Framework was the standard for backend development.
Its original architecture relied on several elements that are now obsolete or no longer supported:

• AppDomains for dynamic loading and isolation.
• Shadows and reflection to support hot-reloading of modules and content.
• A custom threading model, highly optimized to squeeze every bit of performance from distributed simulations.

These decisions made perfect sense back then, but today they clash with modern infrastructure and deployment models.
Migrating meant more than rewriting code — it required reinterpreting the architecture and translating old concepts into modern equivalents.

The Challenge: Modernizing Without Losing Speed

My first major goal was to move everything to .NET 9 and leverage Dependency Injection (DI) as the core of the new structure.
This gave me:

• Integration with Azure Arc Machines and hybrid environments.
• Centralized configuration, service management, and telemetry.
• A solid foundation for connecting with external systems like PlayFab and Solana.

But there was one non-negotiable requirement: I couldn’t sacrifice performance.
The original threading model was blazing fast, and replacing it with something generic would have been a massive step backward.

My Solution: Clean Layers with Preserved Threading

The key was to separate concerns.
I modernized the external layer while preserving the original execution core.

Here’s how it works in practice:

1. DI handles initialization, configuration, logging, and communication with other services.
2. The NI2S engine runs its internal cycle using its native threading model.
3. The node acts as a clean host, launching, supervising, and controlling the simulation without imposing artificial constraints.

With this design, I get the best of both worlds: modern, modular architecture on the outside, raw speed on the inside.

Immediate Benefits

This approach brought clear benefits right away:

• Simplified deployments → the engine now behaves like any other service inside the node.
• Centralized monitoring → metrics and logs are fully integrated with the rest of TCW.
• Safe evolution → I can update services without touching the engine’s internal logic.
• Distributed compatibility → the preserved threading model runs perfectly on clusters and local nodes.

Next Steps

Now that the integration is stable, my next goals are:

• Connecting the simulation to WebSockets for real-time visualization.
• Integrating distributed persistence via Solana for critical state storage.
• Fine-tuning the multi-scale synchronization using the Update Ring system.

This will result in a node capable of running massive, synchronized simulations, fully connected to the blockchain, with live data streams available to clients.

Conclusion

Migrating a simulation engine like NI2S wasn’t just about moving code around.
It was about respecting its DNA, understanding why it was built that way, and adapting it to a new environment.

With this integration, TCW nodes are ready for the future: a modern, modular architecture that retains the raw performance that has always defined NI2S.