For the second half of this modules coursework, we had to adapt a given game to be networked and follow a more traditional games architecture. The given game was “Pong”, simply made in OpenTK with a very basic AI. The first job for me was to improve the AI and make it more realistic. I adjusted the movement parameters to make the response time more realistic, and adjusted the way the AI paddle tracks to ball to ensure that it could be beaten. Once this was done, I began to investigate the implementation of the games networking.
There were two main areas that required a network. A score board that pulled scores from a server, but could also add new scores. This was designed to use the server we created for the first half of the module, were a “Name” would still be the players name, but the “Location” would be a “Score”. Once the method of communication was identified- I would use the established whoIs protocol, I began adapting my client to the situation and implemented it within the game engine. It was then just a case of making requests when required as well as storing new scores when a high score was achieved.
Above is an example of the screen the user would see should the server not be live.
Above is an example of the high scores when the server is live.
The architecture of the game revolved around a central scene manager class that had some core functions that were required by a number of classes, as well as handling the switching between different scenes.
Above is the code for retrieving the high scores from the server. It makes a basic request for data of a given “Name” this then returns a string which contains all the High score data. This works well as rather than passing a single string to the server and then relying on it to sort the data – something the spec prevented as our program should work with any whoIs server, the program sorted the data prior to sending an updated high score string. When it receives a response from the WhoIs server, it sends this data to a method called “LoadHighScores” that handles the data. This is shown below.
The other half of the coursework was to turn the single player pong game, into a networked version. Now previously all networking had been using TCP. However, UDP is much faster for games and given the context of the project the “Best effort” protocol of UDP was sufficient. Once this was decided, I created a local server on that the instigating player would have running on a background thread. The networking would work with one player being the host and the other being a slave. It was therefore required that I identify what data I would need to send to the slave. This had to be the minimum amount of data so that they could still have a valid playing experience.
The message to send to the “Slave” was formed and passed to the server, that way when the client makes a request every tick, there is a new message waiting for them. “Resets” denotes a point. And a lack of response from the server tells the slave that the game is over. The slave would then send back a single int value to dictate the direction their paddle is moving in on the current tick, and therefore the clients paddle could be mapped on the server.
In regards to connecting the the server, the host would begin a game and the client would type in their IP address to connect. I could of implemented a search for active servers request, but given the context of the demo environment and the fact I could not ensure that someone else in the room would be running a similar server, I kept to this safe implementation.
As a final added extra I added a simple local multiplayer, that allowed two people to play from the same computer.
This coursework was great, taking the networking concepts I had learned previously and adapting them to a “Gaming” scenario. It also provided me a excellent opportunity to experiment with UDP and really gain an appreciation for the speed and performance benefits it offers games. I did well with this coursework, achieving full marks.