zkayser / poker_ex

Texas Hold 'Em app written in Elixir with Phoenix and OTP

PokerEx

PokerEx is a Texas Hold 'Em game engine with a Phoenix API layer over top of it.

To run the project, fetch your dependencies and run the server:

mix deps.get
mix phx.server

The dev server is set to run on port 8080, but you can configure this in the config/dev.exs.

poker_ex's Issues

Room engine breaks when only one player is left after end of game?

I ran into an issue the other day where I was running a game with two players. Both players went all in, one player of course won, and then the game engine went into an idle state (as it is expected). However, when this happened, there was no update broadcasted over the channel (at least, this is my assumption). This caused some weirdness because the player that got knocked out should have been removed from the table, but was still there in the UI. This is bad because the backend representation and the front-end representation of state are getting out of sync. Need to figure out how to make sure that update messages are being broadcast over the socket whenever a terminal event like this happens.

Add supervisor for Room state machine

Add a supervisor for the Room state machine. It needs to be a simple-one-for-one supervisor so that multiple rooms can be started.

Fix logic in Evaluator

There is some flawed logic in the Evaluator module. Add some tests. One situation I noticed earlier is this: If two players have a flush with one player having in hand an Ace (assume the player cards are all spades and the flush is made with spades) and a two, while the other player has a King and Queen. As it works right now, the player with the Ace high flush should technically win, but using the logic in the Evaluator module has the other player win (600 points for the flush, then the score is calculated on value; thus, the King and Queen (13 + 12 = 25) > Ace (14)).

Implement mailer

Add a mailer to welcome users when signing up and for sending invitations between players to join a game in a private room once implemented.

Start up stored PrivateRoom instances on application start

Currently, when the client makes a request to create a new PrivateRoom instance, the RoomsSupervisor module handles instantiating the underlying Room process. When the application is stopped using PokerEx.Application.stop/1, the state of all PrivateRoom instances is stored to the database.

When the app starts up, however, the PrivateRoom processes that were shutdown are not restarted and placed back under supervision. This should happen on Application startup so users can never try to join a PrivateRoom game that has no underlying Room process.

Refactor socket.js

Right now, almost all of the JS code is haphazardly thrown into socket.js (mainly because I was initially just trying to figure out how to work with channels and the code quickly grew out of control). The channel communications should be broken out into their own files to keep everything more modular and easy to follow. One file needs to be in charge of managing the state of tables at any given moment: Is it active? How many players are there? What order are they betting in? Who do the player controls need to be shown for? Who is the active player?

Improve UI for player controls

The player controls right now were just put in place to get something on screen. They should be replaced with something more modern and response (the controls don't render properly right now on extra-small devices).

Add persistence layer for Users/Players

Using, Ecto, implement an authorization and a persistence layer for all users. Player names, or usernames, should be unique as the client-side functionality currently depends on unique names to update the UI in multiple scenarios.

Upgrade to Elixir 1.6

Title says it all, but I do want to move the :simple_one_for_one child specs that are used to supervise Room processes are changed to use the new DynamicSupervisor module.

Persist private room state after each turn

Game state can be lost and will cost players chips if the server process goes down without warning. Manual shutdowns will store the state; however, that is not the case for unexpected sudden shutdowns of the server itself. To avoid this, persist PrivateRoom state after each turn made. Considerations should be made about what kind of persistence is best for the job.

Animations for dealt cards

Whenever cards are dealt on the table, an animation should run except for on small and extra-small devices. The rendering of the cards as it stands right now looks pretty sloppy.

Fix up `PrivateRoom` api

The current api for the PrivateRoom resource is an absolute mess, mainly because I was hacking my way through Ecto when writing it. There needs to be higher level abstractions for creating rooms with invitees and participants.

Also, there are no tests at the moment for the entire module. The api should be largely rewritten with a focus on easy-to-use high-level abstractions in a test-first approach.

Set timeout value for inactivity

If a player goes offline or otherwise becomes idle when it is his/her turn, the entire system hangs up and cannot be recovered. To get around this, the Room module needs to implement functionality to limit player turns to something like 30 seconds. If the player does not respond, the system should automatically fold or check for the player, depending on the circumstances.

Transition JS code from plain JS to Angular 2, React, or Elm

Not a pressing issue, but using Angular 2 or React on the front-end would clean the code up nicely and also add other benefits.

Add lobby messaging to client

Since the app now accommodates multiple tables at the same time, players that have joined the lobby channel should receive real-time updates on information about each room such as how many players are currently seated at each room, etc.,

Implement multi-tables

Right now, only one table can be joined. Ultimately, I want to make it so that players can go into a lobby and check out the status of ongoing games (stakes, number of players, etc.). Each table (room) should be its own process of the Room state machine.

Done

Implement player render on front end

The markup for the table is in place, but we still need to have the players render when joining the game. The JavaScript code should track which position the player is in relative to the dealer (or blinds) and arrange the other players around him/her appropriately to maintain the correct order of players.

Also, a special class should be added to the active player to identify whose turn it is.