Requirements

• It should be a web-based game, with the same rules are Codenames.
• It should use Elixir, Phoenix and maybe LiveView (importantly, it should be server-side-rendered as much as possible with minimal Javascript). While tech stacks mostly don't belong in requirements, I'm doing this to learn a specific stack, so there.
• It should work in real-time. In other words, the state of the game needs to be kept in sync and auto-updated for everyone at the same time.
• It's OK to keep everything in memory, even if it's lost on restarts. No persistence, no databases.
• No logins, authentication - anyone can connect and play immediately without an account.

Setup

asdf plugin add erlang
asdf plugin add elixir
asdf plugin add nodejs

mix archive.install hex phx_new
mix phx.new secretwords --no-ecto --live

Writing Elixir code

def join(color, user_id) do
  @game.teams[color].add(user_id)
  @game.ensure_leaders()
end

def join(game, color, user_id) do
  updated_teams = %{game.teams | color => MapSet.put(game.teams[color], user_id)}

  game
  |> Map.put(:teams, updated_teams)
  |> ensure_leaders()
end

• update the list of team members by calling `MapSet.put`,
• update the `teams` map with  the resulting list of team members,
• finally update the game itself with the new `teams`.

• There is no `self` or anything similar - we're purely operating on arguments and we just accept `game` struct (not "object") as one of our arguments.
• We also return an updated `GameState` struct, though it's a different one (as in, it's stored at a different memory location) than the one we accepted. Since everything is immutable and we want to make changes, we create new structs.
• In rails we can assume e.g. `@game.teams[color]` is a `Set` and we can just call its `add` method, which is pretty convenient. In Elixir, we can use `MapSet`, however, since there are no classes or objects, we call `MapSet.put` explicitly, so it's a bit more verbose. I'm on the fence about the relative importance of being succinct vs. explicit here.
• In both cases we call `ensure_leaders()`, which just makes sure that some rule constraints are satisfied after every update.
• The pipe operator `|>` might seem strange at first, but you get used to it very quickly.

def log_activity(game, messages) when is_list(messages) do
  %{game | activity: messages ++ game.activity}
end

def log_activity(game, message) do
  %{game | activity: [message | game.activity]}
end

def log_activity(self, messages) do
  if isinstance(messages, list):
    self.activity += messages
  else:
    self.activity.append(messages)
end

Persistence

Broadcasting changes

• `PubSub.broadcast!` whenever a change is made,
• `PubSub.subscribe` inside the LiveView `mount` function to force re-rendering when anything is broadcast.

Plugs

Testing

@sessions 4
feature "four players can start", %{sessions: [player1, player2, player3, player4]} do
  game_path = Routes.live_path(@endpoint, SecretwordsWeb.GameLive, 'game_id')

  player1
  |> visit(game_path)
  |> assert(...)

  player2
  |> visit(game_path)
  |> assert(...)

  player3
  |> visit(game_path)
  |> assert(...)

  player4
  |> visit(game_path)
  |> assert(...)
end

Tailwind

Deployment