-
Notifications
You must be signed in to change notification settings - Fork 0
Home
This game is split into three packages: Client Application, Server, and AI application
The client application contains all of GUI components from my previous games and is changed to be a display engine in which the player can change settings, connect to the server, and see the status of the game on the server. No game calculations are done on the client side except to get input and to adjust some of the player variables in order to display the correct screen. My client is not limited to accessing information of your own player though. It has the ability to watch other players play in a live view, but can only send actions for its own player.
Design: My central class for my client application is the Application class. This Application class creates all my panels and my client class. My panels need to communicate with each other, so everything that the Application creates has a reference to the Application class. This way, if one panel needs to contact the client, it can call the application reference, then call the client class in the application. My client class is a separate thread that is used to communicate with the server protocol class. All my threads are constant, meaning they are never stopped until the client stops the game, disconnects, or runs out of chips (which is same procedures as disconnection). The protocol is described next. All my panel buttons simply change the command string that I send to the server to request a new action/information.
My server is similar to my application, but with far less panels. The server has a GUI interface to allow for coin adjustment, starting the server, and exiting the server. This was more for player convenience when running the server application. My game class that does all the calculations is moved into my server class and is called to run when needed. Serverprotocol is my runnable class that handles all the interaction with its specific client. Although I have hardcoded the amount of players the server can accept to be 4, my code is mostly written to be adjustable for as many players as the server creator desires (just not implemented yet since I was working on disconnections).
Design: My serverprotocol interaction with the client is similar to the TCP/IP threeway handshake except that it is more of a two way handshake. The client contacts the serverprotocol and sends a String. The serverprotocol receives the String, decides what to do with the String, then sends back another string to indicate what further data it is going to send. After sending the first String, my client waits until it receives the second String, determines what the String is, and follows the procedures to read in further data that the serverprotocol will send. Because of the this two way confirmation, I split my run class into multiple while(true) loops for different phases of the game. The commands are constantly sending because of this loop to ensure that a connection exists and that the player can receive input at anytime in the game. The live streaming works because of this constant loop. If the client doesn't have any action, the default command sent is idle. Idle increments an update counter which will change the command to update after 2000 run throughs, allowing for the screen to update.
Disconnections: A very challenging aspect of my game was handling disconnections. I wanted my game to continue even after a player disconnects. Because of this, I designed multiple variables to adjust the game for disconnections. If a player disconnects in the waiting room, a count is simply adjusted and the Treemap that keeps track of available spaces is opened up. The next player that connects to the server will take the spot of the disconnected player. If a player disconnects midgame, the player is set to a temp player and my game skips the temp player for that round. At the end of the round, people are sent to the waiting room and need to wait until the set number of players connect again. When a client stops the game, the coins in the profile are saved and the client simply disconnects from the server. The server handles the rest of the procedures. One case of disconnections that I don't handle is disconnection when the player is currently being requested to take action (bet, hit, stay). Since disconnections is not a requirement, I will program this in a later date.
My AI is a cut down version of my player application. Most of the code is similar to the player application. The main differences is that the commands sent by the client are hardcoded before each protocol block so that responses such as waiting for players to get ready or continue are instantaneous. The heart of my AI program is the decision making function that decides what it should do when it is betting and choosing whether to hit or stay. The AI program bets a random number between 1 and half the number of its chips. It's decision as to hit or stay is based off of a basic blackjack strategy that looks that the cards it has, looks at the dealer's shown card, and decides. I have attached the strategy table in my images file. Since my game doesn't have splits or double downs, splits are handled as if they were regular values and double downs are based off another table as to whether or not to hit or not (available on wikipedia). Disconnections are similar to the client application but with fewer prompts.
The playerpanel now has a label to indicate what your selected profile name currently is. There menubar is cut down and the create player button is disabled once the game starts. Save game and load game no longer saves the whole game, but rather saves the profiles the client has created and is all client based. Player creation is upgraded into profile management and the player can add the current created player, add new players, select players, and remove players in the manage profiles settings menu. The client also does not connect to a server until the start game button is clicked. In the settings menu, the player can input a server address to connect to so that multiple servers can be running at the same time on different websites and the player can choose which one to connect to. The default address is localhost so if no address is set, the client will attempt to look for a server on the current computer. JOptionPane prompts pop up when needed for user input as well as message notices. Below are several screenshots of the GUI design.