roganjoshua

roganjoshua

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

Showing Posts 1 to 10

mindok

mindok

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: The Erlangelist - To spawn, or not to spawn?

cmo

cmo

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.

garrison

garrison

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.

brkn

brkn

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 RoundPlayerHand. Reminds me my ReactJs code ages ago where I drilled down actions through components.

derek-zhou

derek-zhou

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:

JKWA

JKWA

Author of Advanced Functional Programming with Elixir

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

roganjoshua

roganjoshua OP

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.

Asd

Asd

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.

garrison

garrison

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.

JKWA

JKWA

Author of Advanced Functional Programming with Elixir

This might be helpful on your journey.

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

Where Next? Top

Trending in Questions Top

Blokh
Hey guys, I’ve got a huge CSV ( around 10 GB ) that needs to be processed hourly Do you guys have any suggestions what is the best prac...
New
kszambelanczyk
Hello! Could someone please give me a help/sample code, how to delete a file from s3 using waffle/waffle_ecto from Phoenix app. I creat...
New
Onor.io
I have what I’ve heard referred to as a “lookup table” in my database. This is a way of assigning codes to common values. One common lo...
New
Trolleger
What approach to take when sending live updates to “random” users Hi! I have a question, I have a little chat app, and when I create a DM...
New
matt-savvy
Anyone here using Honeybadger? My Honeybadger account is being overwhelmed with noise from some bots. Seeing a lot of Bandit.HTTPError...
New
RemyXRenard
I’m seeing that a list inside a Kino.DataTable will be interpreted as a charlist, even if the Kino.configure() is set to charlists: :as_l...
New
samoloth
Hi, I’ve just set up an application with ash_authentication. There is only magic link strategy for now, so there is no confirmation add o...
New

Other Trending Topics Top

mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
mcass19
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve. They are GUI (Emerge) and State management (S...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
wintermeyer
There are three potential reasons for members of this forum to have a look at https://vutuv.de You are tired or annoyed of LinkedIn. Yo...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews