Nerves app structuring

Nicd

I have an app structuring question regarding Nerves. First I’ll generally describe my app on a high level.

I’m making a game where RFID readers will play an integral part. The game consists of many devices (different kinds of Raspberry Pi) acting as a network and synchronising game state together. There are initially three types of devices:

Player device: This is worn by the player and contains an RFID reader. Each player also has an RFID tag in their hand. The player device connects to the others with WiFi. If the RFID reader detects another player’s code, that player has tagged the wearing player and the wearing player’s tag will be disabled from affecting other players (by communicating this to all other players). Then that player must go to read their tag at a respawn station to reactivate their tag.
Respawn device: This is stationary somewhere and will connect via Ethernet most likely. When the respawn station’s RFID reader detects a tag, it should communicate to all the devices that that player’s tag is active again.
“Judge” that coordinates the whole game. This device should also offer a web page probably with Phoenix that can be used to set up and follow the game. Another feature could be permanent storage of game info to PostgreSQL/SQLite for example.

Now my issue is, how should I structure my code? The two first devices are similar enough, but the third would also have Phoenix and maybe other stuff, but it still needs the game coordination code that is common to all three. I know of umbrella applications but I thought they are not the solution if you only want to start part of the applications in some environments, or am I wrong?

4 comments

/nerves #umbrella #structuring

2 2125 4

2017-10-27 14:04:46 UTC

Most Liked

Show Best Posts
Show All (oldest first)
Show All (newest first)

outlog

1 & 2 could(should?) be simple clients that have a socket connection open to 3 (perhaps with GitHub - J0/phoenix_gen_socket_client: Socket client behaviour for phoenix channels · GitHub).. so they could share code and configs would decide if it was respawn for gameX or playerX for gameX..

you will face and be fighting latency issues - player A tags B, and then B tags A - however wifi latency etc. can change the order of those messages. so you will need to timestamp the event messages on the device.. (you might need a device with RTC or add it to the board Breakout Boards, Clocks Products Category on Adafruit Industries - so clocks don’t drift)..

and even then you still need logic on the ‘judge’ if a tag event comes in it should wait x ms to see if another and contrary event comes in - and then decide based on the timestamps if A gets the tag or not.

mnesia doesn’t solve this logic so I would not venture there. start with ets and then you can always lazily persist things to sqlite etc.

also you will face rfid latency.. you might have to use battery assisted tags..

Post #1

outlog

ok, maybe go with this Add simple Erlang Distribution example to `hello_network` by GregMefford · Pull Request #71 · nerves-project/nerves_examples · GitHub
hardcode the ‘judge’ node in a config
and then after the :net_kernel.start([node_name]) you can do the node.connect to judge

and then a single genserver, and the judge can dynamic config that a device should be a ‘respawn’ or ‘player_x’ (kept in genserver state) - and the devices then does remote calls to the judge according to their state and events..

Post #3