What Lies Ahead?

Lay the foundation with Elixir

Let’s have a look at what we will learn in each part of the course.

In the first part, we begin by defining the data structures and logic of the game in pure Elixir. We won’t use a database to store the game state and will define our domain elements with native Elixir data structures instead of ORMObject-relational mapping models.

We will bring in a finite state machine to manage state transitions, like switching from one player’s turn to the other and moving from a game in progress to one player winning.

Building logic first

Building the game engine solely in Elixir solves a long-standing problem in web development—the tendency for the framework code to completely entangle application logic so the two can’t be easily separated. Without that separation, it’s hard to reuse application logic in other contexts. As we build Islands, we won’t even begin to work with the Phoenix framework until our game logic is complete.

In the second part, we layer on OTP for concurrency and fault tolerance. We hold the data structures we’ve defined in the GenServer as a state. Then we build a supervisor to monitor the GenServer and restart it with a known, good state in the event of a crash.

By the time we’re done with the first and second part, we’ll have a fast, fault-tolerant game engine that spins up a new GenServer for a game almost instantly. We’ll be able to reuse it with any interface we want—the web, a native mobile app, plain text, or whatever else we can think of. If we look at it the right way, the GenServer for each game is really a microservice, or a nano service living right inside the virtual machine.