Multiplayer
One Day or Day One features a multiplayer system which allows players to interact with each other in the lobby. Granted that you have internet access, then upon starting the game, you will automatically connect to the multiplayer server. For now, there is no login system; everyone is assigned a random username.
The multiplayer system allows players to chat with each other. These players may be fellow prospective students or even university staff members. Theoretically, our platform could be used to host events led by university staff. These events could include Q&A sessions about engineering etc.
The back end repository is hosted here. If you require access, please contact my university email where my UPI is fwan182.
The multiplayer back end is hosted on Heroku. For the back end, the involved technologies include Kotlin and Spark for the programming language and web app framework respectively. For the front end, websocket-sharp is used to create web sockets. For serializing the game objects, JSON is used.
Communication between the client and server is done via web sockets. When a player joins the lobby, a web socket connection is automatically established to the specified host.
The aforementioned web socket is used to sync the multiplayer state. The primary data being transferred is the serialized player object. This data transfer is two way: the client tells the server about our player, and the server tells us about all the other players. This data transfer is done periodically and is referred to as a "game tick".
To display other players, we currently use the same prefab as our own player. For every other player, a game object is created from the prefab and its location is set accordingly. The player direction is derived from the movement direction between the game ticks.
Player data is captured and transferred periodically. As such, there is a lot of data that goes uncaptured between each game tick e.g. at some point in time, the player is at location X, but on the next game tick they are at location Y, but how did they get from X to Y?
This loss of data can be mitigated by lowering the game tick duration, but comes at the cost of increasing our bandwidth as data is transferred more frequently. Yet, if we set the game tick too high, too much data goes uncaptured; leading to other players jumping or teleporting around our screen.
To solve this, we can interpolate player movement between the game ticks i.e. we guess how the player moved between the game ticks. To interpolate effectively, a player's movement must be limited between game ticks. As such, we've made our game tick every 300 milliseconds.
Players can send chat messages to the server. To avoid spoofing, the client only sends the message string; the sender's username, message id and timestamp are all set on the server. The message ids are automatically generated in ascending order. On each game tick, the server tells the client of the newest message id. If the client is missing the newest message, it asks for the messages it hasn't seen yet. This request is done independently of the game tick.
