I'm tackling the meat of the behind-the-scenes code for my centipede game. This means sending and receiving commands through sockets and making sure exceptions are handled if one or both machines happens to die.
I have made so much progress over the weekend. All told I've probably put a solid 10 hours of programming time in, as well as work on other coursework. I don't know if this is because I have a demonstration date looming, or because I feel like I'm reaching a point in my code where I can see everything coming together and it feels less like a load of separate mini projects and one cohesive whole. Currently I'm running a server on my main PC and the client software (which includes the centipede game I posted up in my previous post) on my netbook. This means coding on two separate devices which I actually enjoy. It's easier to sort the code physically between two devices rather than one device with two separate projects.
I'll try and break down the behavior of my server code so far.
Server: Opens a socket on port 7777
Client: User inputs the IP address of the server and port number 7777 then presses connect. Client connects to server. (See image below)
Server: picks up the incoming connection, prints out the IP address of the new client and launches a ConnectionHandler thread to handle all further interactions with this client.*
Client: Requests the ID of the thread that is controlling it.
Server: Fulfills the client's request for thread ID.
Client: If the game has not started yet, it will continually ask the server if it can start.
Server: As soon as the end user gives the go-ahead, the server acknowledges the client's next request to start with "true" instead of "false".
Client: Picks up the signal to start the game and immidiatly requests the location of which screen edges are walls and which lead on to other systems.
Server: Sends this information in a simple comma separated string.
Client: Pareses the wall information and runs a method to set up the walls correctly.
Client: Asks the server if it can spawn a centipede.
Server: when required, sends the client a message to spawn a centipede, as well as the location where the centipede should be created.
Client: Dutifully spawns the centipede, then waits for it to dissepear off a screen edge. Informs the server when this happens. Step 11 starts again.
*These ConnectionHandlers are all stored in a LinkedList of connections. There is a daemon thread that continually monitors this list for dropped or closed connections. If it finds one, it deletes that entry from the list to free up space.
Client Software
That's it in a nutshell. There's exception handlers in place which gracefully closes the server's connection if the clients is manually closed, or switches the game into offline mode if the server's connection to the client is dropped.
The next step is to create an interface for the server that can graphically represent each of the connected clients and position them in a grid. Once this grid is formed, the server should be able to generate the wall layout for each different client and broadcast this information when the game is started. My next post here will be when I have this working. Perhaps as early as tuesday.
You May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
