---

The Ultimate Guide to Conway's Game of Life in Crystal

Conway's Game of Life is a classic cellular automaton that simulates the evolution of a population of cells on a grid. This guide provides a complete solution in Crystal, explaining how to represent the grid, count neighbors, apply the rules, and generate the next state from scratch.

Have you ever been fascinated by how simple rules can lead to breathtakingly complex and unpredictable patterns? It's a concept that appears in nature, from the formation of snowflakes to the flocking of birds. This same principle is the heart of one of computer science's most famous simulations: Conway's Game of Life. It feels like a complex puzzle, but what if I told you that with a modern, elegant language like Crystal, you can build this entire simulation and understand the core logic of emergent behavior? This guide will take you from the basic rules to a fully functional implementation, demystifying every step along the way.

---

What is Conway's Game of Life?

Conway's Game of Life is not a game in the traditional sense; it's a "zero-player game," meaning its evolution is determined by its initial state, requiring no further input. Created by the British mathematician John Horton Conway in 1970, it operates on a two-dimensional grid of square cells. Each cell can be in one of two possible states: alive or dead (often represented as 1 and 0, respectively).

The simulation proceeds in discrete time steps, called "generations" or "ticks." The state of each cell in the next generation is determined by a set of simple rules based on the state of its eight immediate neighbors (horizontally, vertically, and diagonally).

The Four Fundamental Rules

The entire, complex behavior of the system emerges from these four simple rules applied to every cell simultaneously during each generation:

• Underpopulation: Any live cell with fewer than two live neighbors dies, as if by isolation.
• Survival: Any live cell with two or three live neighbors lives on to the next generation.
• Overpopulation: Any live cell with more than three live neighbors dies, as if by overcrowding.
• Reproduction: Any dead cell with exactly three live neighbors becomes a live cell, as if by reproduction.

The beauty of this system is its Turing completeness, meaning it can simulate a universal Turing machine. This implies that, in theory, the Game of Life can compute anything that any other computer can compute, making it a profound subject of study in computer science and artificial intelligence.

---

Why Use Crystal for This Simulation?

Choosing the right programming language for a simulation like the Game of Life can significantly impact performance and developer experience. While it can be implemented in almost any language, Crystal offers a unique blend of features that make it an excellent choice for this particular problem from the kodikra learning path.

The Power of Crystal

• C-like Performance: Crystal compiles to highly efficient native code. For a simulation that involves iterating over a grid potentially thousands of times, this raw speed is a massive advantage, allowing for larger grids and faster generation updates.
• Ruby-like Syntax: The syntax is clean, expressive, and incredibly readable. This allows developers to focus on the logic of the simulation rather than wrestling with boilerplate code, making the implementation feel intuitive.
• Static Type Checking: Crystal is statically typed, which means the compiler catches type-related errors before the program even runs. This adds a layer of safety and robustness, preventing common runtime errors when dealing with grid coordinates and cell states.
• Built-in Concurrency: While our initial solution will be sequential, Crystal's first-class support for concurrency (fibers and channels) opens up exciting possibilities for optimizing the simulation by processing different parts of the grid in parallel.

For a problem that is computationally intensive yet logically straightforward, Crystal hits the sweet spot between high-level abstraction and low-level performance. You get the development speed of a language like Ruby with performance that rivals C or Go. You can explore more about the language in our complete Crystal guide.

---

How to Implement the Game of Life in Crystal

Let's break down the implementation into logical steps. Our goal is to create a function or method that takes a 2D array representing the current generation's board and returns a new 2D array representing the next generation.

The Core Algorithm Flow

The process for calculating the next generation involves iterating through every single cell on the current board, determining its fate based on the rules, and then building a new board with the results. It's crucial to calculate the next state based *only* on the current state, not a partially updated one. This means we need to build a completely new grid for the next generation.

Here is a high-level view of the algorithm's flow:

    ● Start with an initial board state
    │
    ▼
  ┌─────────────────────────┐
  │ Create an empty new_board │
  │ of the same dimensions  │
  └────────────┬────────────┘
               │
               ▼
  ┌─────────────────────────┐
  │ Loop through each cell  │
  │ (row, col) on the board │
  └────────────┬────────────┘
               │
               ▼
    ┌────────────────────┐
    │ Count live neighbors │
    │ for board[row][col]  │
    └──────────┬─────────┘
               │
               ▼
    ◆ Apply Game of Life Rules ◆
   ╱            │             ╲
  Dies        Lives         Becomes Alive
  ╱             │              ╲
  ▼             ▼               ▼
┌──────────────────────────────────┐
│ Set cell state in *new_board*    │
└──────────────────┬───────────────┘
                   │
                   ▼
  ┌──────────────────────────────────┐
  │ After all cells, return new_board│
  └──────────────────────────────────┘
                   │
                   ▼
               ● End

Step 1: Representing the Board

The most natural way to represent a 2D grid in Crystal is using an array of arrays. We'll use Array(Array(Int32)), where 1 represents a live cell and 0 represents a dead cell.

# A 3x3 board example
initial_board = [
  [0, 1, 0],
  [0, 1, 0],
  [0, 1, 0]
]

Step 2: The Main Function Signature

We'll encapsulate our logic within a class, say GameOfLife, with a class method next_generation. This method will take the current board and return the new one.

class GameOfLife
  def self.next_generation(board : Array(Array(Int32))) : Array(Array(Int32))
    # Implementation will go here
  end
end

Step 3: Counting Neighbors

This is the most critical part of the logic. For any given cell at coordinates (row, col), we need to check its eight neighbors. The main challenge here is handling the edges of the grid to avoid "out of bounds" errors.

We'll iterate through the 3x3 square centered on our cell. We'll check each of the 8 potential neighbor positions, making sure they are within the grid's boundaries before checking their state. We must also remember to skip the center cell itself.

This diagram illustrates the neighbor-checking logic for a cell at (r, c):

      (r, c)
        │
        ▼
  ┌────────────────┐
  │ Initialize count = 0 │
  └────────┬───────┘
           │
           ▼
  ┌─────────────────────────────┐
  │ Loop dr from -1 to 1        │
  │ Loop dc from -1 to 1        │
  └──────────────┬──────────────┘
                 │
                 ▼
      ◆ Is (dr, dc) == (0, 0)? ◆
     ╱            ╲
   Yes (Self)      No (Neighbor)
    │               │
    ▼               ▼
  [Skip]    ┌───────────────────┐
            │ neighbor_r = r + dr │
            │ neighbor_c = c + dc │
            └──────────┬──────────┘
                       │
                       ▼
          ◆ Is neighbor in bounds? ◆
         ╱              ╲
       Yes               No
        │                │
        ▼                ▼
┌──────────────────┐   [Skip]
│ Add board value  │
│ to count         │
└──────────────────┘
        │
        └────────┬────────┘
                 │
                 ▼
     ● Return final count

Step 4: Applying the Rules and Building the New Board

Inside our main loop, after counting the neighbors for a cell, we apply the four rules to determine its state in the next generation. We then place this new state (0 or 1) into our new_board at the same coordinates.

Let's look at the complete, commented Crystal code that brings all these pieces together.

---

The Complete Crystal Solution

This solution, part of the exclusive kodikra.com curriculum, demonstrates a clean and efficient implementation. We define a class GameOfLife containing the core logic.

# This class encapsulates the logic for Conway's Game of Life.
class GameOfLife
  # Calculates the next generation of the board based on the rules.
  #
  # @param board [Array(Array(Int32))] The current state of the board.
  # @return [Array(Array(Int32))] The state of the board in the next generation.
  def self.next_generation(board : Array(Array(Int32))) : Array(Array(Int32))
    # Handle empty board case gracefully.
    return [] of Array(Int32) if board.empty? || board[0].empty?

    rows = board.size
    cols = board[0].size

    # Create a new board to store the next state.
    # We cannot modify the board in-place, as it would affect
    # neighbor calculations for subsequent cells in the same iteration.
    new_board = Array.new(rows) { Array.new(cols, 0) }

    # Iterate over every cell in the current board.
    (0...rows).each do |r|
      (0...cols).each do |c|
        # Get the current state of the cell and count its live neighbors.
        current_state = board[r][c]
        live_neighbors = count_live_neighbors(board, r, c)

        # Apply the rules of the Game of Life.
        if current_state == 1 # If the cell is currently alive
          if live_neighbors == 2 || live_neighbors == 3
            new_board[r][c] = 1 # Rule: Survival
          else
            new_board[r][c] = 0 # Rules: Underpopulation or Overpopulation
          end
        else # If the cell is currently dead
          if live_neighbors == 3
            new_board[r][c] = 1 # Rule: Reproduction
          else
            new_board[r][c] = 0 # Stays dead
          end
        end
      end
    end

    new_board
  end

  # Helper method to count live neighbors for a given cell.
  #
  # @param board [Array(Array(Int32))] The current state of the board.
  # @param row [Int32] The row index of the cell.
  # @param col [Int32] The column index of the cell.
  # @return [Int32] The number of live neighbors.
  private def self.count_live_neighbors(board : Array(Array(Int32)), row : Int32, col : Int32) : Int32
    rows = board.size
    cols = board[0].size
    count = 0

    # Iterate through the 3x3 grid centered at (row, col).
    # dr (delta row) and dc (delta col) are the offsets from the current cell.
    (-1..1).each do |dr|
      (-1..1).each do |dc|
        # Skip the cell itself.
        next if dr == 0 && dc == 0

        # Calculate the coordinates of the neighbor.
        neighbor_row = row + dr
        neighbor_col = col + dc

        # Check if the neighbor is within the grid boundaries.
        if neighbor_row >= 0 && neighbor_row < rows && neighbor_col >= 0 && neighbor_col < cols
          # If it's a valid neighbor, add its state to the count.
          count += board[neighbor_row][neighbor_col]
        end
      end
    end

    count
  end
end

# Example Usage:
# A simple "Blinker" pattern (period 2 oscillator)
blinker_initial = [
  [0, 0, 0, 0, 0],
  [0, 0, 1, 0, 0],
  [0, 0, 1, 0, 0],
  [0, 0, 1, 0, 0],
  [0, 0, 0, 0, 0],
]

puts "Initial State:"
blinker_initial.each { |row| p row }

# Calculate the next generation
blinker_next = GameOfLife.next_generation(blinker_initial)

puts "\nNext Generation:"
blinker_next.each { |row| p row }

Running the Code

To run this code, save it as a file (e.g., game_of_life.cr) and execute it from your terminal using the Crystal compiler.

$ crystal run game_of_life.cr

The expected output will show the initial "blinker" pattern transforming from a vertical line to a horizontal one, demonstrating the rules in action.

Initial State:
[0, 0, 0, 0, 0]
[0, 0, 1, 0, 0]
[0, 0, 1, 0, 0]
[0, 0, 1, 0, 0]
[0, 0, 0, 0, 0]

Next Generation:
[0, 0, 0, 0, 0]
[0, 0, 0, 0, 0]
[0, 1, 1, 1, 0]
[0, 0, 0, 0, 0]
[0, 0, 0, 0, 0]

---

Code Walkthrough: A Deeper Dive

The next_generation Method

This is the public-facing method of our class. Its primary responsibility is to orchestrate the process.

1. Edge Case Handling: The first line, return [] of Array(Int32) if board.empty? || board[0].empty?, is a crucial guard clause. It ensures the program doesn't crash if it receives an empty or malformed board.
2. Board Dimensions: We get the number of rows and cols to use in our loops and boundary checks. This makes the code adaptable to any rectangular grid size.
3. Creating the new_board: This is the most important architectural decision. By creating a separate new_board initialized with all zeros, we ensure that every cell's next state is calculated based on the original, unmodified board. This is known as a "double-buffering" technique in simulation and graphics programming.
4. The Main Loop: The nested each loops, (0...rows).each do |r| and (0...cols).each do |c|, are the standard way to iterate over a 2D grid. They ensure we visit every single cell.
5. Applying Logic: For each cell, we delegate the complex task of counting to our private helper method, count_live_neighbors. Then, a simple if/else block translates the four rules of the game into code, updating the corresponding cell in new_board.

The count_live_neighbors Helper Method

This private method focuses on one task: counting neighbors. This separation of concerns makes the code cleaner and easier to debug.

1. Neighbor Iteration: The nested loops (-1..1).each do |dr| and (-1..1).each do |dc| are a clever way to check all 8 surrounding positions plus the center. The variables dr (delta row) and dc (delta column) represent the offset from the current cell.
2. Skipping the Center: The condition next if dr == 0 && dc == 0 is vital. It prevents the cell from counting itself as a neighbor.
3. Boundary Checks: The if statement if neighbor_row >= 0 && ... is the core of the boundary handling. It ensures we only attempt to access array indices that actually exist, preventing IndexOutOfBoundsError.
4. Counting: If a neighbor is within bounds, we simply add its value (0 or 1) to our count. This works because live cells are 1 and dead cells are 0, so the sum directly gives us the number of live neighbors.

---

Alternative Approaches and Future Optimizations

While our solution is correct and efficient for moderately sized grids, several advanced techniques could be employed for larger-scale simulations.

Handling Grid Boundaries

Our implementation treats the grid as a finite plane with hard edges. An alternative is a "toroidal" or "wrapping" grid, where the top edge connects to the bottom and the left edge connects to the right. This can be achieved using the modulo operator (%) when calculating neighbor coordinates.

# Example of toroidal boundary logic
neighbor_row = (row + dr + rows) % rows
neighbor_col = (col + dc + cols) % cols

Performance Optimization

For truly massive grids, the sequential approach can become a bottleneck. Crystal's concurrency model is a perfect fit for optimization.

• Parallel Processing: One could divide the grid into several chunks (e.g., quadrants) and process each chunk in a separate fiber. This would leverage multi-core processors to calculate the next generation much faster.
• Sparse Grids: Most Game of Life patterns involve vast empty spaces. Instead of an Array(Array(Int32)), one could use a HashSet({Int32, Int32}) to store only the coordinates of live cells. This drastically reduces memory usage and computation time, as you only need to check the live cells and their immediate neighbors.

Pros and Cons of the Current Approach

Pros	Cons
Simplicity & Readability: The 2D array approach is the most intuitive and easiest to understand for beginners.	Memory Inefficiency: For sparse patterns on large grids, storing every dead cell (0) is wasteful.
Predictable Performance: Accessing elements in a dense array is a very fast O(1) operation.	Scalability Issues: Becomes slow for very large grids due to iterating over every cell, including dead ones.
Easy to Implement: The logic for boundary checking and iteration is straightforward.	Finite Grid: Patterns cannot grow beyond the predefined boundaries of the array.

---

Frequently Asked Questions (FAQ)

Why is it called a "zero-player game"?

It's called a zero-player game because its evolution is entirely determined by its initial state. Once you set up the initial configuration of live and dead cells, no further human interaction is needed. The system evolves on its own based on its internal rules, much like a simulation.

What are some famous patterns in the Game of Life?

There are several categories of famous patterns:

• Still Lifes: Patterns that do not change from one generation to the next (e.g., Block, Beehive).
• Oscillators: Patterns that return to their original state after a finite number of generations (e.g., Blinker, Toad, Pulsar).
• Spaceships: Patterns that move across the grid over generations (e.g., Glider, Lightweight Spaceship).

How do you handle the edges of the grid?

There are two primary methods. The first, used in our solution, is a finite grid with "hard edges," where cells outside the boundary are considered permanently dead. The second is a "toroidal array" (or wrapping grid), where the grid wraps around on itself. For example, a cell moving off the right edge would reappear on the left edge.

Why not modify the board in place?

Modifying the board in place would corrupt the simulation. The rules require the next state of all cells to be calculated based on the *current* state of their neighbors. If you update a cell from dead to alive, its neighbors (which are processed later in the loop) would incorrectly see it as alive, violating the principle of simultaneous state transition for the entire generation.

Is Crystal a good language for scientific simulations?

Yes, Crystal is an excellent choice. Its performance is comparable to C and Fortran, which are traditionally used in scientific computing. Its expressive, high-level syntax makes complex algorithms easier to write and maintain, while its static typing provides safety for complex data structures. This combination of speed, safety, and syntax makes it a strong contender for modern simulations and data analysis tasks.

Can the Game of Life be implemented on a GPU?

Absolutely. The Game of Life is a "massively parallel" problem, as the calculation for each cell is independent of the others in the same generation. This makes it a perfect candidate for GPU acceleration, where thousands of cores can calculate the next state of thousands of cells simultaneously, allowing for real-time simulation of gigantic grids.

---

Conclusion

Implementing Conway's Game of Life is a fantastic exercise that touches on fundamental programming concepts: 2D arrays, algorithmic thinking, state management, and handling edge cases. Through this kodikra.com module, we've seen how Crystal's performance and elegant syntax make it a joy to use for such a task. The solution we've built is not only functional but also clean and understandable, providing a solid foundation for further exploration.

You can now take this knowledge and experiment with different initial patterns, implement a toroidal grid, or even try to optimize the solution using Crystal's concurrency features. The world of cellular automata is vast and full of surprising complexity, all stemming from a few simple rules.

To continue your journey, you can explore more challenges in our Crystal learning roadmap or dive deeper into the language with our comprehensive Crystal language guide.

Disclaimer: The code in this article is written for Crystal 1.12.1. While it is expected to be compatible with future versions, language features and standard library APIs may evolve.

---

Published by Kodikra — Your trusted Crystal learning resource.