Game of Life#

Why the Game of Life?#

Conway’s Game of Life is a cellular automaton on a 2D grid where each cell is either alive or dead. The next generation of the grid is computed from three deceptively simple rules:

  1. A live cell with 2 or 3 live neighbors survives.

  2. A dead cell with exactly 3 live neighbors becomes alive.

  3. Any other cell dies (or stays dead).

That’s it. Yet these rules are enough to reveal blinking oscillators, spaceships gliding across the grid and self-replicating structures.

For a SAF tutorial the Game of Life has one big advantage: it stays product-agnostic while exercising most of the building blocks that a real engineering solution needs.

SAF concepts you will meet#

By the end of the tutorial you will have written and understood:

Solution definition - The shape of your app

The steps that make up your application.

See Solution definition.

Step model - Where each step stores its data and triggers computations

A step holds the inputs, outputs, and methods that make up a computation. It is the main building block of a SAF solution.

See Step models.

Fields - Inputs, Outputs and intermediate data

Data containers that hold the inputs, outputs, and intermediate data of a step. Fields can be typed, validated, and have dependencies on other fields.

See Field states and dependencies.

Blocking transaction methods - Quick actions

Short computations that finish right away. For example, updating a field or very short calculations that return a result immediately.

See Definition.

Non-blocking transaction methods - Background jobs

Longer computations that keep going while the user carries on using the app. Typically, these methods are intended for job executions, long-running simulations, or any process that may take a significant amount of time to complete.

See Long running execution.

Events - Live progress

Messages sent from the running computation to the UI so the user sees generations, percentages or logs appear in real time.

See Events.

Frontend - The user interface

User-facing Dash pages that let the user interact with the backend and visualize results.

See Dash frontend.

Desktop installation - Shipping the app

Packaging the finished solution as a single file you can hand to any user, with no Python or setup on their side.

See Build a distributable desktop installer.

Prerequisites#

Before starting, make sure your workstation meets the requirements listed in the Prerequisites section and that you can run saf --version in a terminal.

You will also get more out of the tutorial if you are comfortable with:

  • Basic Python (classes, decorators, type hints).

  • The idea of a web application with a backend and a frontend.

  • Reading small snippets of Plotly Dash code.

Everything else — SAF concepts, ansys-saf-cli commands, Dash Mantine components—is introduced progressively as you need it.

Learning path#

The tutorial is organized in five phases. Follow them in order — each phase builds on the previous one.

Create the solution from the SAF template, install it, and run the empty application.

Phase 1 — Initialization

Add the pure Python engine that computes Game of Life generations.

Phase 2 — Business logic
Phase 3 — Backend (Phase 3/5)

Wire the business logic into a SAF step model with typed fields, transactions and events.

Phase 3 — Backend

Build the Dash page that drives the backend and animates the grid in real time.

Phase 4 — Frontend
Phase 5 — Package (Phase 5/5)

Ship the finished solution as a standalone desktop installer, for Windows or Linux.

Phase 5 — Package

Tip

Every phase ends with a Key takeaways panel that recaps the SAF concepts you just met. Those panels double as a cheat sheet when you start writing your own solution.