Building an event-sourced game with Phoenix Liveview: Introduction
This article is part of the series Building an event-sourced game in Elixir with Phoenix Liveview. The full list of articles is:
- Building an event-sourced game with Phoenix Liveview: Introduction
- Building an event-sourced game with Phoenix Liveview: Architecture
- Building an event-sourced game with Phoenix Liveview: An event sourced model
- Building an event-sourced game with Phoenix Liveview: Handling errors
- Building an event-sourced game with Phoenix Liveview: Expressing domain concepts in the code
- Building an event-sourced game with Phoenix Liveview: Making game states explicit
- Building an event-sourced game with Phoenix Liveview: Game Server
- Building an event-sourced game with Phoenix Liveview: Acting on the game from the views
- Building an event-sourced game with Phoenix Liveview: Building the view’s states from the events and reacting to changes
- Building an event-sourced game with Phoenix Liveview: Decrementing the timer
- Building an event-sourced game with Phoenix Liveview: Unit testing patterns
I’ve been playing with Elixir for a while now. I’ve created a Twitter bot, but I wanted to explore further what Elixir and Phoenix could help build for real-time collaboration between people. I was also curious about building a domain model with a functional programming language.
During the first French lockdown, I had the idea of a project that could be a good experiment: a game. As we had some fun playing Doctor Pilule, a French board game, I decided to build a digital version helping us to play with friends and family remotely.
Doctor Pilule
The game is quite simple. Players are split into several teams, and each round, one player tries to make her other team members guess as many words as possible. The trick is that all players are given two uncommon handicaps, one spoken (ex: start all sentences by "I might sound crazy but...") and one driving actions (ex: you think you are the Eiffel tower).
The first team to reach 20 guessed words wins.
Why this game?
First, as I said, it’s fun to play, and we needed some fun this year. It also comes with some interesting challenges to deal with, which are making for a good experiment:
it’s real-time
it needs to deal with a timer
all players don’t see the same thing at the same time (ex: the word to be guessed)
it’s better if you play it with video
game’s logic is complex enough to tinker with building a model with functional programming way without being overwhelming
And then?
I felt I could build something relatively quickly, helped by Phoenix Liveview and be able to play with friends after a few weeks.
Of course, it didn’t work out as expected.
As with many side projects, the fun part is not in delivering something but in learning. I spent a lot of time playing around, trying stuff, and being stuck and stubborn about solving problems not providing real value in the end—things we should probably avoid while at work; however, not so bad in a side project.
I still didn’t reach the video part and still have things I’d like to play with. Nevertheless, I managed to build the game logic, display relevant information to players in real-time, event-sourced the system, and learn a few things along the way. This blog post series is about some of these learnings.
