0
\$\begingroup\$

So I'm trying to create a simple text input Texas Hold 'Em game that can be played in a Terminal between multiple computer. (Disturbing lack of hold 'em games that don't require Facebook integration or a million ads or micro transactions :c )

With my current knowledge I can create the TCP Server and Connect some clients, but I'm not sure how to proceed from here. How can I communicate between the clients and server turn by turn using text input effectively? My vague idea of what to do is

  1. Accept clients, store FD in Array
  2. Loop through Id's sending them 2 cards each
  3. Create thread with a game info struct, that reads users text input
  4. Wait for thread to finish and return value will be the players move
  5. Update game info, and move repeat step 3-4 for all Clients
  6. Break whenever only 1 player is left, or all bettings phases are over then repeat

This outline makes sense in the server, but I'm not sure how to construct the client to not do anything until it gets prompted by the thread creation in the main server while loop. If anyone has any advice or links to helpful articles or example code I would really appreciate it thanks so much!!

\$\endgroup\$
  • 1
    \$\begingroup\$ Link to helpful article : gafferongames.com/networking-for-game-programmers/udp-vs-tcp \$\endgroup\$ – realUser404 Dec 29 '16 at 10:28
  • 1
    \$\begingroup\$ @realUser404 That article's conclusion only applies to real-time games. Turn-based card games are one of those genres where TCP is usually the better decision, because a few additional ms of latency don't matter, but the reliability and guaranteed message ordering really make your life easier. \$\endgroup\$ – Philipp Dec 29 '16 at 10:43
1
\$\begingroup\$

You might want to look up on finite state machines.

The basic idea is that your client can be in one of many different states in which it behaves differently towards both the user and the server.

  1. Player's turn state
    • Show the player which options they have (raise, fold, check...)
    • Wait for input from the player
    • When the player made a decision what to do, send that decision to the server and go to "Waiting for confirmation" state.
  2. Waiting for confirmation state
    • Don't accept player input
    • Show some progress indicator to the player
    • Listen to the server and wait for a response
    • When the server rejects the action, go back to Player's turn
    • When the server confirms the action, go to Not player's turn state
  3. Not player's turn state
    • Don't accept player input
    • Listen to the server for messages
    • When the server sends a message about an action performed by another player ("player 2 raised by 12". "player 3 folded" ...) or about other events which happen in the game ("turn-card revealed: king of spades"), report that to the player.
    • When the server sends a message that it's the player's turn again, go to Player's turn state.
    • When the server sends a message that the game has concluded, switch to Game Over state.
  4. Game Over state
    • Tell the player who won the game
    • Wait for input if they want to join another game or quit

Each state should be implemented as a series of functions for handling user input, network input and UI drawing. When it's time to call one of these functions, check in which state the client currently is and call the appropriate function.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.