The game

Throughout this course, we’ll build a game in distinct layers, from the bare essentials of business logic to a web front-end with stateful Phoenix Channels.

The course is divided into three sequential parts that parallel those layers. The first part lays the foundation, while the next two parts build a new layer that depends on the preceding one.

How to proceed

If you’re planning to implement the game as you read, you’ll need to follow through each section sequentially in order for the code to work.

If you’re the sort of reader who likes to skip around, though, all is not lost. You can read the first few sections of any lesson–up until where we start to really implement the code–in any order.

Before we get to work in earnest, we’ll get an overview of the whole course in the next chapter, Mapping Our Route.

Plan to proceed

Target audience

Let’s discuss the target audience for this course.

Who is this course for?

On a practical level, this course is for people who have some familiarity with Elixir and Phoenix and want to take that knowledge further. However, there’s a wider list for whom the ideas in this course will resonate.

For people who view OTP with a little trepidation, or for those who haven’t quite mastered OTP behaviours, this course will provide the confidence to use OTP in any application.

For people who have felt the sting of tight coupling between business logic and web frameworks, this course will show them a way out of that pain forever.

Who will take this course

Those who feel constrained by traditional web development will learn new techniques and new ways to structure apps that will spark their imagination. Those wondering what all the fuss is about with Elixir and Phoenix, will get a great taste of what makes people so excited. They just might become a convert!

Who isn’t this course for

Readers looking for an introduction to Elixir or Phoenix should preferably begin with other resources.

We won’t cover the basics of Elixir. We’ll assume the reader knows them before we begin. If you need to get up to speed first don’t worry—we’ll be here when you’re ready.

The same is true for Phoenix. We will take a close look at Channels and Presence but you won’t learn the rest of Phoenix here. You should be able to follow along in this course without that information.

Gain the knowledge

The structure of the course

Let’s see what each part of this course has to offer.

Defining the functional core in Elixir

We’ll begin with the most basic elements of Elixir – data structures, functions, and modules.

In Model Data and Behavior, we’ll use data structures to model our domain entities. We’ll define functions that work with these data structures to establish the business logic of the game. We’ll also define modules to organize these functions and keep the code legible and easy to maintain.

In Working of State Machines, we’ll build a purely functional finite state machine to manage the game over time and enforce the rules. We’ll proceed the same way we did in the previous chapter, with a data structure, multiple clauses of a single function, and a module to hold them all.

Adding OTP for concurrency and fault tolerance

This is where we’ll introduce OTP to provide concurrency, parallelism, and fault tolerance.

In Adding OTP for Concurrency and Fault Tolerance, we’ll build a GenServer module to contain the business logic and the state machine we built in the first part. We’ll learn to spawn a new, long-lived process from this GenServer for each pair of players. This process will hold the state for their game as well as provide an interface to interact with it.

In Process Supervision for Recovery, we’ll explore how to make our game resilient to failures large and small. We’ll build a supervisor to watch over each game process and restart it if it crashes. We’ll also see how to restore a game process’s state after a crash and even after the whole BEAM (Erlang’s virtual machine) crashes or restarts.

Adding a web interface with Phoenix

With all the work we’ve done in the previous two parts, we’ll finally be ready to build a web interface with Phoenix.

In Generate a New Web Interface with Phoenix, we’ll create a new Phoenix project. We’ll learn how OTP applications let us seamlessly integrate our work from the first two parts into this new Phoenix project as a dependency. Then, we’ll explore how we can call into the earlier work directly from different Phoenix components.

In Create Persistent Connections with Phoenix Channels, we’ll focus on the stateful, persistent connections that Phoenix provides called Channels. You’ll learn to use JavaScript functions in a browser to communicate directly over a Channel with a specific game process on the server. We’ll also explore how to use Phoenix Presence to keep track of which players are actually playing an individual game.