Maintaining state in a deep map

Questions / Help
, ,
1

Coming from an object-oriented background I am writing a scrabble clone in elixir/phoenix in order to learn elixir and functional programming.

So my instinct is to have a state map like so:

game_state = {
  players: [
    {
      name: "Bob",
      rack: ["A"],
      score: 3
    },
    {
      name: "Alice",
      rack: ["B"],
      score: 10
    }
  ],
  board: [
    %Tile{
      letter: "A",
      row: 0,
      column: -1
    },
    %Tile{
      letter: "T",
      row: 0,
      column: 0 
    }
  ],
  bag: [
    "A",
    "A",
    " "
  ]
}

This is enough to maintain the state of the game.

Doing it this way seems to give flexiblity, storage and atomicity.

Writing interactions with this state feel a bit awkward and I am thinking I am stuck in OO world and I am building an object rather being functional.

I am thinking modules for bag, players and board.

new_game_state = game_state |> Players.add_player("Fred")
Am I going the wrong way with this?

I am doing things like if Enum.member?(player_state, &(&1.name == name)) do which is hauntingly familiar.

Martin

2

Hi @roganjoshua,

There’s a pretty nice discussion about modelling a game (in this case Blackjack) from a functional and process point of view here: https://www.theerlangelist.com/article/spawn_or_not

2 Likes
3

You could make the players state a map where their name or ID is the key. The board could be a map with {row, column} keys. That might make lookups a bit nicer.

5 Likes
4

Building upon this, it’s common in these sorts of apps to want to look up by id and be able to iterate through a (sorted) list of entries. One simple way to do this is to use List.keyfind/4 to find a player in the list by id. That function is a nif so it should be a bit faster than iterating by hand.

Alternatively you could keep a map of id => player and then keep a list [id] of ids like a secondary index. This is more optimized for lookups than the keyfind approach.

5

Am I understanding the problem correctly, it feels awkward to update a struct couple levels deep? Because I had the same exact feeling, and I don’t know the answer either. Different modules feels tightly coupled? I compared my elixir code to what I would have write in ruby here: @berkan.dev on Bluesky

I’ve checked the repo linked in the erlangelist post. There Round.deal calls Hand.deal, and this feels weird to me, in my case it was Round → Player → Hand. Reminds me my ReactJs code ages ago where I drilled down actions through components.

6

You don’t have to colocate the functions that manipulate the struct in the same module that defines the struct. I frequently have one module with several sub-modules, all defined in the same file. The sub-modules have nothing but a struct, and all the business logic reside in the main module.

As for updating a struct couple levels deep, if you don’t like put_in/3 and update_in/3, there are fancier libraries that help with ergonomics. One was recently discussed in this forum:

3 Likes
7

Working with a deck of cards is a good product/sum type problem.

8

Thank you all for your input!

The Sasa link is really invaluable @mindok !!!

As an update, this approach seems reasonable, I will need an id for the player and perhaps the struct Player should include the atom ,although the atom feels structural rather than data.

[
  {
    :player_one,
    %Player{
      name: "Alice"
      rack: ["A"]
      score: 34
    }
  }, {
    :player_two,
    %Player{
      name: "Bob"
      rack: ["H"]
      score: 31
    }
  }]

Now I can do players[:player_one].rack for example and iterate as I think @garrison mentioned.

So this kind of thing can now work…

  def start_game(names) do
    game_state = create_game_state()
    case PlayerManager.create_players(names) do
      {:ok, players} ->
        game_state = put_in(game_state.players, players)
        game_state = fill_rack(game_state, game_state.players, game_state.bag)
        game_state

and

  def fill_rack(game_state, [{key, first_player} | players], bag) do
    {bag, rack} =
      Bag.take_tiles(
        bag,
        first_player.rack,
        GameDefinitions.max_num_tiles_in_rack() -
          length(first_player.rack)
      )

    game_state = put_in(game_state.bag, bag)
    game_state = put_in(game_state.players[key].rack, rack)
    fill_rack(game_state, players, bag)
  end

It is still a journey but I feel I am beginning to refine my approach a lttle.

Not 100% on put_in/3 as @derek-zhou mentioned but I can go and check the code to see what it actually does.

9

I’d suggest using Pathex for this.

put_in and other *_in functions have one big problem: they don’t work with arbitrary structures, because they expect every structure to implement Access behavior. Most of structures don’t implement it. And even if they do, it introduces unnecessary boilerplate and runtime overhead.

Pathex doesn’t have any of these problems, plus it is declarative, performant, extensible, can to nested sets (like mkdir -p crates intermediary folders, pathex creates intermediary structures), works with tuples, and even has smart things like lenses, filters, etc.

I am using Pathex to maintain complex state in GenServers where there is a lot of logic involved and I also use Pathex to traverse deeply nested structures like parsed HTML, verbose services responses (like ElasticSearch), etc.

7 Likes
10

Make sure you also check out the Keyword lists and Maps guide as it has some good info on this topic.

Your example is indeed similar to what I was talking about, but you’re using a keyword list so you can only have atom keys. In practice you would key a list like this by a database id, probably an integer or string, and the keyword lookup wouldn’t work in that case. That’s where you would use List.keyfind/4 instead.

1 Like
11

This might be helpful on your journey.

Optics are likely overkill for your problem, but can be helpful to know the underlying ideas.

12

interesting