-
Sander Sandvik Nessa authoredSander Sandvik Nessa authored
IDATT2104_netcode_project
Introduction
This is part of a voluntary project in the course networkprogramming (IDATT2104) taken during the spring semester og 2025. This project is being taken as a chance to earn a grade greater than C. The aim of this project is to implement netcode for either a client-server, or peer-to-peer architecture in programming language of choice. There are no specifics on how the final result of the project should look, only that it has the aim of showcasing netcode in some way. This project is being written with java on the server side and python on client side.
The server uses the maven structure to download necessary dependencies as well as create a good structure alongside testing. For the client and visuals we have used Pygames library. To make it scaleable, the team decided to make all of the functionality used for netcoding its own library (netcodeLib). This way it could be improved upon and used in later projects if that were to be desireable without having to rewrite huge amounts of code.
Functionality
Under is a list of functionality completed and present in this project as of 26.05.2025
Base game
By booting up the server and client the user is presented with two windows showcasing player 1 and player 2. Here the player has the ability to click on one of the windows to move their character (drawn in red), and see it move in the other players window (drawn in blue). By not having any checkboxes ticked, the game will recieve input from the user and send it to the server, once it has been confirmed with the server will the player box move. It is possible to move the "delay" slider to increase the delay and visually see how much slower or faster the game feels. The player is also able to change the tickrate for their own client. This changes how often information is sent to the server, as well as how often the game is drawn per second.
Prediction
By checking the prediction box, the player can now move around more freely and does not need to wait for a server response. However, when the player recieves information about position from the server, the player model will be snapped back to that position if it isn't already there. When moving with prediction enabled, the player can see a green box which is meant to show what the server is seeing. So when the player is snapped back it will be in the same position as the green box.
Reconciliation
The reconciliation box is a further improvement of the prediction functionality. Therefor it is not possible to only enable reconciliation. An attempt in that will result in the prediction box also being ticked and enabled. Reconciliation is meant to avoid the snap-backs we encounter when only using prediction. The client stores some information about the last inputs as well as their sequence number, so when the server finally responds with the confirmed position it will not necessarily check if the current position matches, but rather if the position of the sequence number matches. If it does then we do not need to snap back in position, but if they do not match we will snap back.
Interpolation
Interpolation is a way to smoothen out the movements observed of player 1, observed by player 2. Without interpolation checked, the movements of player 1 will seem jittery and a bit rough from the perspective of player 2, but if player 2 enables interpolation then the movements of player 1 seen by player 2 will be smoother. This may not be as apparent when the tickrate for the server is as high as 60hz, but lowering it to say 10hz will show a huge difference. The only issue is that if the client tickrate is higher than that of the server, the client will move so much faster than what the server sees making it not ideal for actual gameplay. Changing the tickrate however is purely so that the user of this code can clearly see the difference, as having a higher server tickrate (e.g. 60hz) will still be interpolated, the difference will just not be as visible to the eye.
Future work
The goal of this project is not to make a game, so discussions about making it possible for two players to move their character at the same time on the same pc will not be discussed. This also applies to graphical changes. What we do feel we can touch upon however is the implementation of lag compensation. If the team were to have more work spent on this project we would probably go over to working on implementing lag compensation. Lag compensation is a technique used in games where collisions or other pvp elements occur. For example since the client is seeing themselves in the present but other players in the past then it can get quite frustrating trying to hit that player since where you aim isn't actually where they find themselves to be. So instead of looking at the current time for both players, when you hit another player a message is sent to the server with a timestamp. The server then checks to see if the other player actually was at this position in that timestamp (when delay is taken into account). If the opposing player was there, it will register as a hit. Although this can be frustrating for the opposing player if they on their screen clearly got out or got behind cover this is a good trade off.
In our solution we would have to either implement a way for our boxes to shoot and or implement collision detection. But because of the limited time, we decided to implement the other functionality as stated earlier.
Dependencies
- Pip
- Maven
- Java
- Python