Project Egregore

Refusing the False Dilemma of Online Worlds

A revolutionary hybrid network architecture that synthesizes the advantages of centralized authority and distributed peer-to-peer intelligence, creating truly emergent collective systems.

<5ms P2P Latency
∞ Scalability
100% Fair Play

The Vision: A New Frontier in Online Experiences

For decades, the landscape of online gaming and interactive digital experiences has been shaped by a fundamental, often unspoken, dilemma: the seemingly irreconcilable trade-off between security and fairness (typically offered by centralized, authoritative server architectures) and low-latency, real-time responsiveness (the hallmark of peer-to-peer systems). The internet promised us vast, interconnected universes; what we often received were mere lobbies. Artificial Intelligence promised us dynamic, living worlds; what we often got were predictable scripts. Project Egregore asserts that this false dichotomy is not an inherent limitation of technology, but rather a consequence of architectural choices. We declare: The time for choosing is over.

🏰

The Centralized Fortress

βœ… Advantages: Maximum security against cheating, guaranteed fairness for all, simplicity of state management.

❌ Compromises: Inevitable latency, limiting central bottleneck, exponential scaling cost.

🌐

The Anarchic Frontier

βœ… Advantages: Minimal latency, cost scalability, distributed resilience.

❌ Compromises: Massive vulnerability to cheating, complexity of consensus, systemic injustice.

The Broken Paradigm

Why Current Solutions Fall Short

The Latency Trap: The Unseen Barrier to Immersion

Latency, often perceived as mere 'lag', is a multifaceted problem that profoundly impacts the player experience. In traditional client-server models, every significant player action must traverse the network to the server, be processed, and then have its outcome relayed back to all relevant clients.

⚑

Traditional Server RTT

50-150ms
πŸš€

Egregore P2P

<5ms

The Synthesis: Egregore Architecture

Three Symbiotic Layers Working in Harmony

πŸ›‘οΈ

Layer 1: Server of Truth

The authoritative backbone powered by SpacetimeDB, ensuring ultimate fairness and security. Acts as the final arbiter for all critical game state decisions.

🌐

Layer 2: P2P Mesh

Direct peer-to-peer communication for real-time interactions. Enables ultra-low latency for immediate feedback and responsive gameplay.

🧠

Layer 3: Immune System

Distributed consensus and reputation system that detects anomalies and maintains network health through collective intelligence.

πŸ›οΈ
SpacetimeDB Server
Ultimate Authority & Truth
Escalation on Anomaly Detection
P2P MESH WITH IMMUNE SYSTEM
πŸ’»
Player A
Trust: 95% | Cap: 80%
πŸ–₯️
Player B
Trust: 75% | Cap: 60%
πŸ’»
Player C
Trust: 90% | Cap: 70%
CHEATER
πŸ”΄
Player D
Trust: 15% | Cap: 40%
πŸ“±
Player E
Trust: 65% | Cap: 30%
πŸ’»
Player F
Trust: 85% | Cap: 85%

Scenario: Cheater Detection & Isolation

  1. Detection: Player D attempts to manipulate game state (speed hack)
  2. Local Consensus: Neighboring nodes (A, B, E) detect anomaly through weighted voting
  3. Soft Correction: Honest nodes apply local corrections, isolating the cheater
  4. Escalation: If anomaly persists, escalate to SpacetimeDB for authoritative correction
  5. Reputation Update: Player D's trust score decreases, reducing their influence in future consensus
P2P Communication
Consensus Voting
Server Escalation

The Engine: Distributed Reactive Physics

Transforming the Network into a Distributed GPU

Project Egregore redefines how game physics are computed, transforming the network itself into a distributed GPU through a novel approach to reactive computation. This paradigm shift moves away from the traditional model of a single, authoritative physics host, distributing the computational burden across the entire network of connected players.

❌

Traditional Model: Physics Host Bottleneck

In most online games, a single server or a dedicated physics host is responsible for calculating all critical physics interactions. When a complex event occurs, this host performs all the necessary calculations in a batch.

Event β†’ Delegation to Host β†’ Batch Calculation β†’ Massive Transmission

Problem: A single node suffers a massive load spike, and the network is flooded with data, leading to potential lag for all players.

βœ…

Egregore Model: Reactive Physics Cascade

Project Egregore adopts a reactive, event-driven approach to physics. Instead of a single host, physics calculations are broken down into granular, independent tasks that are distributed across the P2P network.

Event (e.g., Explosion) β†’ Granular Task Creation β†’ Distribution β†’ Nodes Pull Work On-Demand β†’ Cascade β†’ Results Feed Next Queues β†’ Synthesis β†’ Emergent Final State

Distributed Work Queue System

The practical implementation of reactive physics relies on a Distributed Work Queue System. This system acts as a dynamic marketplace for computational tasks, where nodes pull work on demand.

DISTRIBUTED WORK QUEUES
Velocity Calc
Task: V_001 (Ready)
Task: V_002 (Ready)
Task: V_003 (Ready)
Task: V_004 (Processing)
...
Gravity Apply
Task: G_001 (Ready)
Task: G_002 (Ready)
Task: G_003 (Processing)
Task: G_004 (Ready)
...
Collision Detect
Task: C_001 (Processing)
Task: C_002 (Ready)
Task: C_003 (Ready)
Task: C_004 (Ready)
...
Other Tasks
Task: O_001 (Ready)
Task: O_002 (Ready)
Task: O_003 (Processing)
...
↓
↓
↓
↓
PLAYER CLIENTS (NODES)
Node A (High-End PC)
[Cap: 95%, Load: 20%]
Pulling Tasks:
V_001, V_002, C_004
Processing...
Node B (Mid-Range PC)
[Cap: 70%, Load: 40%]
Pulling Tasks:
G_001, G_002
Processing...
Node C (Laptop)
[Cap: 50%, Load: 80%]
Pulling Tasks:
C_001
Processing...
Node D (Old PC)
[Cap: 30%, Load: 95%]
CPU Limited - No Work
Idle/Overloaded
Ready Task
Processing Task
↓
Node pulling tasks on-demand

Live Demonstration: Distributed Physics Load Balancing

The following interactive demonstration showcases how different client machines, with varying hardware capabilities and current workloads, contribute to the overall physics computation without becoming overloaded:

Client 1 (High-End PC)

CPU Usage:
15%
Physics Load:
0%
Tasks/sec: 0
Smooth 60 FPS

Client 2 (Mid-Range PC)

CPU Usage:
35%
Physics Load:
0%
Tasks/sec: 0
Smooth 60 FPS

Client 3 (Laptop)

CPU Usage:
25%
Physics Load:
0%
Tasks/sec: 0
Smooth 60 FPS

Client 4 (Old PC)

CPU Usage:
85%
Physics Load:
0%
Tasks/sec: 0
Stable 45 FPS

Implementation: From Concept to Code

Technology Stack and Development Roadmap

Translating the visionary architecture of Project Egregore into a tangible reality requires a carefully selected technology stack and a phased development roadmap. Our choices prioritize performance, safety, and the ability to manage complexity inherent in distributed systems.

πŸ¦€

Game Engine: Bevy (Rust)

Bevy is a refreshingly modern, data-driven game engine built in Rust. Its Entity Component System (ECS) architecture provides native parallelism, enabling highly performant and scalable game logic.

πŸ›οΈ

Server of Truth: SpacetimeDB

SpacetimeDB serves as the authoritative, low-latency backend for Project Egregore. Its unique ability to combine a database, application server, and game logic in Rust provides a robust foundation.

🌐

P2P Network: WebRTC & FlatBuffers

The P2P layer is built upon WebRTC for direct, low-latency peer-to-peer communication and FlatBuffers for efficient, zero-copy data serialization.

⚑

Physics Engine: Rapier (Rust)

Rapier is a robust and highly performant 2D and 3D physics engine written in Rust. Its modular design and deterministic nature make it ideal for distributed computation.

Development Roadmap

The development of Project Egregore will proceed in distinct phases, each building upon the previous one, validating core concepts, and progressively adding complexity.

1️⃣

Hybrid Network Proof of Concept (4-6 weeks)

The initial phase focuses on establishing the foundational hybrid network architecture. This PoC will demonstrate the core communication layers and the basic interaction between the authoritative server and the P2P mesh.

2️⃣

Reputation and Consensus System (6-8 weeks)

This phase builds upon the P2P mesh, introducing the Immune System layer. The focus is on implementing the dynamic trust and capability scores and the local consensus mechanisms.

3️⃣

Reactive Distributed Physics (8-12 weeks)

This is the phase where the physics engine is fully integrated into the distributed work queue system, leveraging the P2P mesh and the reputation system for dynamic load balancing.

4️⃣

Distributed AI Integration (10-16 weeks)

The final phase integrates network-enabled NPCs as first-class clients within the Egregore architecture, leveraging the distributed network for AI processing.

Join the Revolution

Be Part of the Future of Online Worlds

Project Egregore represents more than just a technological advancementβ€”it's a paradigm shift that will redefine what's possible in online interactive experiences. We're looking for visionary developers, researchers, and innovators who share our belief that the false dichotomy between security and performance can be transcended.

Connect on LinkedIn Learn More
πŸš€

What We're Building

A revolutionary hybrid network architecture that combines the security of centralized systems with the performance of peer-to-peer networks, creating truly emergent collective intelligence.

🧠

Who We Need

Rust developers, network engineers, game developers, distributed systems experts, and visionaries who believe in pushing the boundaries of what's possible in online experiences.

🌟

The Impact

Join us in creating technology that will democratize game development, enable truly massive multiplayer experiences, and establish new standards for fairness and performance in online worlds.

Ready to Build the Future?

Project Egregore is more than a technical challengeβ€”it's an opportunity to be part of something transformative. If you're passionate about distributed systems, game development, or simply believe that we can do better than the current state of online experiences, we want to hear from you.

Get Involved