You can attend with your PC by using the Pokitto Simulator Linux binary which I have made, but please preferably use the P+ proto if you have one.
Please select all days you feel are suitable. One testing day is finally selected based on this poll. The time in the poll should be automatically adjusted to be in your time zone. This is not a binding poll.
I can also try to make a windows binary for testing with PC if there is demand. I have not build the Windows binary of the multiplayer library for a long time, so I cannot guarantee it still works.
The one game session lasts only few minutes, so we can do several of them with different players. There is a 5 player limit per session. I assume the whole testing session takes about 1 hour if there are enough people attending.
The aim of this very simple game is to collect food for points. There is superfood which gives you superpowers for a while. The jellyfish will steal your points. The one with most points when the time runs out is the winner.
For more technical point of view, we will be testing a delay-based multiplayer system. That has been built on Pokitto’s proprietary ReliableUDP -protocol, so that each packet need to be sent just once by the client. The data contains only the key events (left, right, up, down). So each remote client works essentially like a remote joystick for the local game engine. The frames are synchronized so that the game needs frame data from all the other clients to be able to run the frame. To prevent frequent locks caused by the network lag, the frames are sent in advance (so “delayed”) so that there exists a small local buffer of future key events already for each remote client. The delay (i.e. size of buffer) is 7 frames. As the game runs at 30 fps, the total delay of 7 frames is about 260 ms. That is the perceived input lag in the game.
To be able to run synchronized while getting only the key events from the remote clients, the game engine must be deterministic. That means that e.g. the random number generator always gives the same values in certain frame for each client. Also the ticks or the local clock cannot be used for critical timing, but everything is measured in “frames”.
The obvious advantage of using this kind of multiplayer system is that you do not need to use any network code for implementing multiplaying in your game (!). You can just code it like in the local multiplay system (like a shared screen game with multiple joystics). There is a special RemoteButton class that will provide you the remote key events.
