---

Master Red Vs Blue Darwin Style in Cairo: Complete Learning Path

The "Red Vs Blue Darwin Style" simulation is a foundational concept in Cairo for building complex, autonomous on-chain systems. It involves creating a digital ecosystem where two teams of agents, governed by a simple set of rules or "DNA," compete, evolve, and exhibit emergent behavior directly on the Starknet blockchain.

Have you ever dreamed of creating a world from scratch? Not just a game with predefined outcomes, but a living, breathing digital ecosystem where life evolves on its own, driven by competition and survival. It sounds like science fiction, but with the power of Cairo and Starknet, this concept of autonomous worlds is rapidly becoming a reality. Many developers get stuck on the complexity of managing thousands of interacting components on-chain, worrying about gas costs and state management. This guide demystifies the process, providing you with the core principles and practical code to build your own on-chain simulation from the ground up.

---

What is the "Red Vs Blue Darwin Style" Simulation?

At its core, "Red Vs Blue Darwin Style" is an on-chain, agent-based simulation. Think of it as a digital petri dish built with a smart contract. Inside this dish, we have a grid-based world inhabited by simple creatures belonging to one of two teams: Red or Blue. This isn't just a static game; it's a model of evolution inspired by Darwinian principles, where survival is determined by a creature's ability to navigate its environment and interact with others based on a predefined set of instructions—its digital DNA.

Each creature is an autonomous agent. It has a position, a direction it's facing, and a simple "brain" in the form of a program counter that points to the next instruction in its DNA. This DNA is a short list of commands like move_forward, turn_left, or attack. The simulation progresses in discrete turns or "ticks." In each tick, the smart contract iterates through every creature, executes its current instruction, and updates the state of the world accordingly. The result is a dynamic, unpredictable system where complex patterns and strategies—known as emergent behavior—arise from very simple rules.

This concept is a powerful learning tool within the exclusive Cairo curriculum on kodikra.com because it forces you to tackle fundamental challenges of on-chain development: efficient state management, gas optimization for complex loops, and understanding the constraints of a deterministic environment like a blockchain.

The Core Components

• The World (Grid): A 2D grid representing the environment. In Cairo, this is often implemented using a Felt252Dict to map coordinates (x, y) to the creature occupying that cell.
• The Creatures (Agents): The inhabitants of the world. Each is defined by a struct containing its essential properties: team (Red or Blue), position, direction, and a program counter (PC).
• The DNA (Instruction Set): A simple set of commands that creatures can execute. This is typically an enum in Cairo, representing actions like moving, turning, sensing the environment, and interacting with other creatures.
• The Engine (Game Loop): The logic within the smart contract that advances the simulation one step at a time. It's responsible for iterating over all creatures, interpreting their DNA, and updating the world state.

---

Why is This Concept Crucial for Cairo Developers?

Mastering this simulation pattern is more than just an academic exercise; it's a gateway to understanding the architecture of next-generation decentralized applications, particularly in the realm of Fully On-Chain Games (FOCG) and Autonomous Worlds (AW). The Starknet ecosystem, with its focus on computational scaling via STARK proofs, is the perfect laboratory for such ambitious projects.

By building a Red Vs Blue simulation, you gain hands-on experience with several critical skills:

1. Complex State Management: You learn how to design data structures that can efficiently store and update the state of thousands of agents without incurring prohibitive gas costs. This involves making smart choices between Felt252Dict, LegacyMap, and other storage patterns.
2. Gas Optimization: Every operation on-chain costs gas. A simulation with many agents and complex loops can become very expensive. This module forces you to think critically about algorithmic efficiency, minimizing storage writes, and structuring your code for optimal performance.
3. Deterministic Logic: Blockchains are deterministic. You'll learn how to create complex, seemingly random behavior from a set of simple, deterministic rules. This is a key skill for building any on-chain application that requires predictable outcomes.
4. Smart Contract Architecture: You'll design a contract with a clear separation of concerns: data storage (the world state), core logic (the game engine), and external functions (to start, stop, and view the simulation). This modular approach is essential for building robust and maintainable smart contracts.

Ultimately, the principles learned here are directly transferable to building more sophisticated systems, from complex DeFi strategy simulators to the persistent, user-governed universes envisioned by the Autonomous Worlds movement.

---

How Does the Simulation Logic Work in Cairo?

Let's break down the technical implementation of the simulation engine. The magic happens in the interplay between the data structures that define the world and the functions that evolve it over time.

1. Defining the Creature and its DNA

First, we need to define what a creature is and what it can do. We use a struct to hold a creature's state and an enum for its possible actions (its DNA).

// Using Cairo 1.x+ syntax

#[derive(Copy, Drop, Serde, starknet::Store)]
struct Creature {
    team: Team,
    direction: Direction,
    pc: u8, // Program Counter
}

#[derive(Copy, Drop, Serde, starknet::Store, PartialEq)]
enum Team {
    Red,
    Blue,
}

#[derive(Copy, Drop, Serde, starknet::Store)]
enum Direction {
    Up,
    Right,
    Down,
    Left,
}

#[derive(Copy, Drop, Serde)]
enum Instruction {
    Move,       // Move forward one step
    TurnL,      // Turn left 90 degrees
    TurnR,      // Turn right 90 degrees
    IfEnemy,    // If an enemy is in front, skip next instruction
    Attack,     // Attack the cell in front
    Hop,        // Jump forward two steps
}

The Creature struct is compact, storing only the essential information. The pc (program counter) is a crucial element; it tracks which instruction in its DNA sequence the creature should execute next.

2. Representing the World Grid

The world is a 2D grid. The most flexible way to represent a potentially sparse grid in Cairo is with a dictionary-like storage variable, mapping coordinates to a creature. We'll also need to store the dimensions of our world.

#[starknet::contract]
mod DarwinGame {
    // ... import structs and enums ...

    #[storage]
    struct Storage {
        world_width: u32,
        world_height: u32,
        // Maps a coordinate (x, y) to a creature
        grid: LegacyMap::<(u32, u32), Creature>,
        // Stores the DNA for each team
        red_dna: LegacyMap::,
        blue_dna: LegacyMap::,
        creature_count: u32,
    }

    // ... contract logic follows ...
}

Here, grid maps a tuple of coordinates (u32, u32) to a Creature struct. We also store the DNA for the Red and Blue teams separately, mapping a program counter index (u8) to an Instruction.

3. The Game Loop: Driving the Evolution

The game loop is the heart of the contract. It's the function that advances the simulation by one "tick." A naive approach would be to iterate through every cell in the grid. However, this is incredibly inefficient if the grid is large and sparsely populated. A better approach is to iterate only over the cells that contain creatures.

Since we cannot directly iterate over a LegacyMap or Felt252Dict in a contract, we must maintain a separate list or index of creature positions. For simplicity in this explanation, we'll conceptualize the loop as iterating through coordinates, but a real-world implementation would require a more optimized approach to track agent locations.

Here is an ASCII diagram illustrating the flow of a single simulation tick.

    ● Start Tick
    │
    ▼
  ┌──────────────────┐
  │  Fetch All Agent │
  │    Coordinates   │
  └────────┬─────────┘
           │
           ▼
  For each Agent (x, y)
           │
           ├─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
           │
           ▼
     ┌──────────────────┐
     │ Read Creature    │
     │ State from Grid  │
     └────────┬─────────┘
              │
              ▼
     ┌──────────────────┐
     │ Get DNA & PC to  │
     │ find Instruction │
     └────────┬─────────┘
              │
              ▼
        ◆ Execute ◆
      (Move, Turn, etc.)
              │
              ▼
     ┌──────────────────┐
     │ Calculate New    │
     │ State & Position │
     └────────┬─────────┘
              │
              ▼
     ┌──────────────────┐
     │ Update Grid with │
     │    New State     │
     └────────┬─────────┘
              │
           ├─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
           │
           ▼
    ● End Tick

The logic for executing a single instruction involves reading the creature's state, determining the action, calculating the outcome, and writing the new state back to storage. This write operation is the most gas-intensive part, so minimizing state changes is key to an efficient simulation.

4. Creature Decision Making: A Simple Example

Let's look at how a creature makes a decision. The IfEnemy instruction is a simple conditional. It checks the cell directly in front of the creature. If that cell is occupied by a creature from the opposing team, the creature's program counter (PC) is advanced by two, effectively skipping the next instruction. Otherwise, it advances by one as usual.

This simple conditional allows for complex strategies to emerge. For example, a common DNA pattern is [IfEnemy, Attack, Move]. This translates to: "If an enemy is in front of me, attack it. Otherwise, move forward."

Here is a diagram of that decision-making flow:

    ● Creature's Turn
    │
    ▼
  ┌─────────────────┐
  │ Read Instruction│
  │  (e.g. IfEnemy) │
  └────────┬────────┘
           │
           ▼
  ◆ Check Cell in Front ◆
   ╱                   ╲
 Enemy Here?         Empty/Ally?
  │                       │
  ▼                       ▼
┌─────────────────┐     ┌─────────────────┐
│ Increment PC by 2 │     │ Increment PC by 1 │
│ (Skip next instr) │     │ (Normal flow)   │
└─────────────────┘     └─────────────────┘
  ╲                       ╱
   └─────────┬─────────┘
             │
             ▼
        ● End Turn

This simple logic, when applied to hundreds of creatures simultaneously, leads to fascinating and unpredictable large-scale behavior, such as flanking maneuvers, defensive lines, and chaotic skirmishes.

---

Where Are These Concepts Applied in the Real World?

While "Red Vs Blue" is a simplified model, the principles it teaches are at the forefront of blockchain innovation. The skills you develop are directly applicable to several cutting-edge domains:

• Fully On-Chain Games (FOCG): Games like Dark Forest and Influence are pioneers in this space. They create persistent, decentralized universes where all game logic and state reside on the blockchain. The agent-based logic from our simulation is fundamental to creating the NPCs, resource systems, and environmental dynamics in these worlds.
• Autonomous Worlds (AW): This is the grander vision where the on-chain environment is not just a game but a digital physics engine with its own immutable laws. Developers can deploy their own systems and agents into this world, and the "Red Vs Blue" model serves as a "Hello, World!" for creating life within it.
• DeFi and Economic Simulations: Agent-based models can be used to simulate complex economic scenarios. Imagine creating agents that represent different types of traders (arbitrageurs, liquidity providers, long-term holders) and running simulations to test the resilience and behavior of a new DeFi protocol under various market conditions.
• Decentralized AI: The concept of simple agents following a set of rules is a stepping stone towards more complex on-chain AI. Future iterations could involve agents with machine learning models stored on-chain or via storage proofs, allowing them to learn and adapt their strategies over time.

---

Risks and Best Practices

Building on-chain simulations is powerful but comes with its own set of challenges. Being aware of these pitfalls is crucial for success. Here’s a summary of the pros, cons, and key considerations.

Aspect	Pros / Best Practices	Cons / Risks
Gas Costs	Excellent for learning gas optimization. Forces you to write efficient code, batch state updates, and minimize storage access.	Can become extremely expensive to run on-chain if not optimized. A single tick with thousands of agents could exceed block gas limits.
State Complexity	Provides a practical lesson in managing complex, interconnected state within the constraints of smart contract storage.	If not designed carefully, the state can become bloated and unmanageable, making the contract difficult to debug and upgrade.
Determinism	The deterministic nature of the blockchain ensures that simulations are reproducible and verifiable, which is great for fairness in games.	Generating true randomness is a challenge. On-chain randomness must be handled carefully using commit-reveal schemes or oracles to prevent manipulation.
Scalability	Starknet's architecture is designed for computational scale, making it one of the few platforms where such simulations are feasible.	Even on Starknet, there are limits. The number of agents and the complexity of their DNA are constrained by computation and storage costs.

---

Your Learning Path on kodikra.com

This module is a cornerstone of the advanced curriculum at kodikra.com. It's designed to take your theoretical knowledge of Cairo and apply it to a dynamic, challenging project that mirrors the work being done at the frontier of Web3.

Module Exercise:

The learning path for this concept is focused on a single, comprehensive project that guides you through building the entire simulation from scratch. You will implement the world grid, the creature logic, the game engine, and the external functions needed to interact with your autonomous world.

• Learn Red Vs Blue Darwin Style step by step: In this hands-on module, you will write, test, and deploy a fully functional on-chain Darwinian simulation. You'll define the creature DNA, build the game loop, and watch as emergent behavior unfolds from the simple rules you've created.

Completing this module will not only solidify your Cairo skills but also give you a profound understanding of the potential and challenges of building persistent, autonomous systems on the blockchain. You can continue your journey by exploring our full Cairo Learning Roadmap.

---

Frequently Asked Questions (FAQ)

What exactly is "emergent behavior" in this context?

Emergent behavior refers to complex, system-level patterns that arise from the interactions of many simple, individual components. In the Red Vs Blue simulation, you don't explicitly program creatures to form a defensive line or to flank the enemy. However, these complex strategies can "emerge" naturally from the simple DNA rules (e.g., "turn towards the nearest enemy and move forward") when many creatures follow them simultaneously.

How is randomness handled for initial creature placement on-chain?

True on-chain randomness is a hard problem because all transactions must be deterministic. A common approach is to use a pseudo-random number generator (PRNG) that is seeded with a value that is difficult for any single user to predict, such as a combination of the block timestamp, block hash (on some chains), and the deployer's address. For a fairer game, a commit-reveal scheme or an oracle-based randomness solution like the Starknet VRF (Verifiable Random Function) would be used.

Is a simulation like this expensive to run on Starknet?

It can be, but Starknet is uniquely suited to handle it. The cost depends on the number of creatures and the complexity of the game loop. Because Starknet offloads the heavy computation off-chain and only posts a proof of that computation on-chain, the cost is significantly lower than it would be on a monolithic chain like Ethereum. Gas optimization is still paramount, focusing on minimizing storage writes (SSTORE operations).

Can the instruction set for the creatures be expanded?

Absolutely. The beauty of this model is its extensibility. You could add new instructions like IfAlly (check for a friendly creature), Build (create a barrier), Heal (repair a friendly creature), or even instructions for communication. Each new instruction adds another layer of complexity and potential for more sophisticated emergent strategies.

What are the main challenges when building on-chain simulations?

The three main challenges are: 1) Gas Costs: Keeping the computation and storage updates for each tick within reasonable gas limits. 2) State Management: Designing data structures that allow for efficient access and updates to thousands of agents. 3) Chain Constraints: Working within the limitations of the blockchain, such as block gas limits, contract size limits, and the deterministic environment.

How does this differ from a traditional, off-chain video game?

The key difference is persistence and decentralization. In a traditional game, the game world exists on a central server controlled by the developer. When the server is turned off, the world ceases to exist. An on-chain simulation runs on a decentralized network of nodes, making it persistent and unstoppable. Its rules are transparent and enforced by code, creating a truly autonomous world that can outlive its creators.

What is the role of the "program counter" (PC) in a creature's struct?

The program counter is a pointer. It's an integer that indicates which instruction in the creature's DNA sequence it should execute on its turn. After executing an instruction, the PC is typically incremented to point to the next one, looping back to the beginning when it reaches the end of the DNA. Conditional instructions, like IfEnemy, can modify the PC to make the creature "jump" over instructions, enabling basic decision-making.

---

Conclusion: Your First Step into Autonomous Worlds

The "Red Vs Blue Darwin Style" simulation is far more than a simple programming exercise. It is a microcosm of the grand vision for autonomous worlds and fully on-chain gaming. By mastering this module, you are equipping yourself with the fundamental skills needed to build the next generation of decentralized applications—systems that are not just run by users, but are owned, shaped, and evolved by them.

You've learned the core components, from the agent's DNA to the on-chain game engine. You understand the critical importance of gas optimization and state management, and you see the direct line from this simple simulation to the complex, persistent worlds being built today. Now, it's time to write the code and bring your own digital ecosystem to life.

Disclaimer: All code examples and concepts are based on Cairo 1.x and the current state of the Starknet ecosystem. The language and its tooling are evolving rapidly, so always refer to the official documentation for the latest syntax and best practices.

Back to the complete Cairo Guide

---

Published by Kodikra — Your trusted Cairo learning resource.