⌨️Technical Architecture

System Overview

The Robot Fighting Championship platform is a complex distributed system combining real-time game simulation, advanced AI decision-making, blockchain integration, and live streaming capabilities.

🏗️ High-Level Architecture

┌─────────────────────────────────────────────────────────────┐
│                     CLIENT (Browser)                        │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐       │
│  │ Game Engine  │  │ AI Renderer  │  │ Wallet UI    │       │
│  │ (WebGL 2D)   │  │ (Real-time)  │  │ (Phantom)    │       │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘       │
└─────────┼──────────────────┼──────────────────┼─────────────┘
          │                  │                  │
          ▼                  ▼                  ▼
┌─────────────────────────────────────────────────────────────┐
│                    APPLICATION LAYER                        │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐       │
│  │ Game Server  │  │ AI Engine    │  │ Betting API  │       │
│  │ (Node.js)    │  │ (Neural Net) │  │ (REST/WS)    │       │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘       │
└─────────┼──────────────────┼──────────────────┼─────────────┘
          │                  │                  │
          ▼                  ▼                  ▼
┌─────────────────────────────────────────────────────────────┐
│                      DATA LAYER                             │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐       │
│  │ Fight DB     │  │ AI Models    │  │ Solana RPC   │       │
│  │ (PostgreSQL) │  │ (Trained)    │  │ (Blockchain) │       │
│  └──────────────┘  └──────────────┘  └──────────────┘       │
└─────────────────────────────────────────────────────────────┘
          │                  │                  │
          └──────────────────┴──────────────────┘
                             ▼
                    ┌──────────────────┐
                    │ Pump.fun Stream  │
                    │ (Live Broadcast) │
                    └──────────────────┘

🎮 Game Engine

Core Components

Physics Engine

  • Custom 2D physics with pixel-perfect collision detection

  • 60 FPS game loop using requestAnimationFrame

  • AABB (Axis-Aligned Bounding Box) collision system

  • Real-time hitbox visualization for debugging

Animation System

  • Sprite-based frame animation (8-22 frames per action)

  • State machine for animation transitions

  • Asset preloading to prevent visual glitches

  • Hardware-accelerated rendering via CSS transforms

State Management

RobotState {
  position: { x, y }
  velocity: { vx, vy }
  health: 0-14
  isAttacking: boolean
  isDamaged: boolean
  isJumping: boolean
  facingDirection: "left" | "right"
  lastAction: timestamp
}

Performance Optimization

  • Sprite sheet compression (32x32 base, 3x scaled)

  • Efficient DOM manipulation (transform-only updates)

  • Minimal reflows and repaints

  • Asset caching with browser IndexedDB

🧠 AI System Architecture

Hybrid Neural Network Design

Our AI system uses a three-tier hybrid architecture:

1. Strategic Layer (High-Level Planning)

  • Model: Fine-tuned GPT-4o-mini transformer model

  • Input: Complete game state (positions, health, momentum)

  • Output: Strategic decisions (aggressive/defensive/tactical)

  • Update Frequency: Every 1.8-2.2 seconds

  • Purpose: Long-term strategy and adaptation

2. Tactical Layer (Mid-Level Execution)

  • Model: Custom feedforward neural network (784-256-128-64-5 architecture)

  • Input: Distance vectors, health ratios, velocity data

  • Output: Tactical actions (approach/retreat/setup/engage)

  • Update Frequency: Every 380ms

  • Purpose: Real-time combat decision-making

3. Execution Layer (Low-Level Control)

  • Model: Deterministic state machine with learned weights

  • Input: Current tactical state + opponent state

  • Output: Raw inputs (A/D/W/F keys)

  • Update Frequency: Every frame (16.6ms)

  • Purpose: Frame-perfect execution of tactics

Neural Network Specifications

Strategic Network (Transformer-based)

Architecture: GPT-4o-mini (fine-tuned)
Parameters: 8.2B
Training Data: 50,000+ combat scenarios
Context Window: 128K tokens
Specialization: Combat strategy & opponent modeling

Tactical Network (Custom CNN)

Input Layer: 784 neurons (game state vector)
Hidden Layer 1: 256 neurons (ReLU activation)
Hidden Layer 2: 128 neurons (ReLU activation)
Hidden Layer 3: 64 neurons (ReLU activation)
Output Layer: 5 neurons (softmax - action probabilities)
Training Method: Supervised learning + self-play

Decision Pipeline

Game State → Preprocessing → Strategic AI → Tactical AI → Execution
     ↓            ↓              ↓              ↓           ↓
  Raw Data → Normalized → High-level → Actions → Commands
             Vectors      Strategy     Queue     (A/D/W/F)

Latency Breakdown:

  • State capture: ~1ms

  • Strategic inference: ~200ms (cached for 2 seconds)

  • Tactical inference: ~8ms

  • Command execution: <1ms

  • Total Decision Latency: ~10ms (excluding strategy cache)

🔗 Blockchain Integration

Solana Smart Contract

Contract Architecture:

pub struct FightBet {
    pub fight_id: Pubkey,
    pub bettor: Pubkey,
    pub amount: u64,
    pub fighter_side: Side, // Left or Right
    pub timestamp: i64,
}

pub struct Fight {
    pub fight_id: Pubkey,
    pub left_fighter: String,
    pub right_fighter: String,
    pub status: FightStatus,
    pub winner: Option<Side>,
    pub total_pool: u64,
}

Wallet Integration

  • Phantom Wallet for Solana transactions

  • Web3.js for blockchain interaction

  • Real-time balance updates via WebSocket

  • Transaction confirmation monitoring

Betting Flow

  1. User connects Phantom wallet

  2. Frontend creates unsigned transaction

  3. Wallet signs transaction

  4. Transaction submitted to Solana RPC

  5. Smart contract validates and records bet

  6. WebSocket notifies frontend of confirmation

  7. User receives bet confirmation

📡 Real-Time Communication

WebSocket Architecture

Server → Client Events:

  • fight:start - Fight begins

  • fight:state_update - Position/health updates (60Hz)

  • fight:hit - Damage event occurred

  • fight:end - Fight concluded with winner

  • bet:placed - New bet recorded

  • bet:payout - Winnings distributed

Client → Server Events:

  • bet:create - Place new bet

  • fight:subscribe - Subscribe to fight updates

  • wallet:connect - Wallet connection event

Stream Integration (Pump.fun)

  • WebRTC for low-latency video streaming

  • Canvas capture API for game screen recording

  • H.264 encoding at 1080p60

  • Sub-second latency for live betting synchronization

🗄️ Data Layer

Database Schema

Fights Table:

CREATE TABLE fights (
    fight_id UUID PRIMARY KEY,
    left_fighter VARCHAR(50) NOT NULL,
    right_fighter VARCHAR(50) NOT NULL,
    winner VARCHAR(10),
    status VARCHAR(20),
    stream_url TEXT,
    created_at TIMESTAMP DEFAULT NOW()
);

Bets Table:

CREATE TABLE bets (
    bet_id UUID PRIMARY KEY,
    fight_id UUID REFERENCES fights(fight_id),
    wallet_address VARCHAR(44) NOT NULL,
    amount BIGINT NOT NULL,
    fighter_side VARCHAR(10) NOT NULL,
    odds DECIMAL(10,2),
    payout BIGINT,
    created_at TIMESTAMP DEFAULT NOW()
);

Caching Strategy

  • Redis for active fight state (in-memory)

  • PostgreSQL for historical data

  • CDN for fighter sprites and assets

  • Client-side caching for AI model weights

🚀 Deployment Architecture

Production Environment

Frontend:

  • Hosted on Vercel (Global CDN)

  • Automatic HTTPS

  • Edge caching for static assets

  • WebSocket proxy for real-time connections

Backend:

  • Node.js server on DigitalOcean/AWS

  • PM2 for process management

  • Nginx reverse proxy

  • SSL termination

  • Load balancing for multiple instances

Database:

  • Managed PostgreSQL (DigitalOcean/RDS)

  • Automated backups

  • Read replicas for scaling

Blockchain:

  • Solana Mainnet RPC endpoints

  • Fallback to multiple RPC providers

  • Transaction retry logic with exponential backoff

🔒 Security Considerations

Smart Contract Security

  • Audited by [Security Firm Name]

  • Reentrancy protection

  • Rate limiting on bets

  • Admin key management via multisig

API Security

  • Rate limiting (100 req/min per IP)

  • CORS configured for known origins

  • Input validation and sanitization

  • SQL injection prevention (parameterized queries)

Wallet Security

  • No private key storage on server

  • All transactions signed client-side

  • Wallet permissions limited to betting only

Previous🤖 Meet The FightersNextAI Training Process

Last updated