[Open thread]Multiplayer discussion


The problem is that, assuming we want to use the USBserial class in the firmware and run it on the emulator, the USBserial class would need to handshake with something that pretends to be a USB controller, and then, once USB has been established, handshake again with something that pretends to be a serial port. Whether you need to make a driver out of it depends how you want to output this virtual interface to other programs. I think Felipe was referring to the idea that it would be visible as a similar COM port as a real device.

I have no doubt in Felipe’s coding prowess but that IS a fair bit of work.


This. Otherwise tools would also have to support sockets to talk to the emulator. Using sockets would be the simplest as it’s relatively OS-independent and wouldn’t be a hassle for the end user (compared to having to install a non-signed serialport driver).


Hrm… that would be handy.

What about routing the serial connection to stdin and stdout?
That would allow it to be piped, which would probably be good enough for most purposes.


AFAIK, pipes don’t work with Windows non-console executables. :thinking:


As far as I’m aware they do.

I just did a test on a .Net non-console executable and it worked fine.
I could make a C++ one to be sure if you want (though it might take some time).

I checked and aparently stdout won’t work if you start a non-console program by double clicking on it,
but it works fine if you start it from the command line (or presumably from a batch file).


I am happy to report I have just gotten the game server to compile (and work 100%) on Visual C++ as well. Although my intention is to run the game server on a Ubuntu server, having a localhost server that compiles with exact same code is very handy as I can do all the networking stuff on the local pc


I’ve finally cracked it.
I needed to enable DTR as well (whatever that is).

So my final (C#) code is:

SerialPort serialPort = new SerialPort(portName, 9600, Parity.None, 8, StopBits.One)
	RtsEnable = true,
	DtrEnable = true

(Works for Pokitto and Arduboy.)



I did some coding during the weekend, and I am very happy with the results.

What I have so far is a server that handles:

  • chatting in the lobby
  • setting up (hosting) a game
  • joining games

At the moment, the server will relay 4 concurrent games to 4 players max each.

The idea is, that once you set up the game, join it, and a sufficient number of other players join, the server becomes a “transparent link” between the host Pokitto and the other peers.

This means that you do not have to know / touch the server code. You write your Pokitto game as if it was connected via serial to a number of other devices, and the server takes care of relaying the gamestate to the peers.

(at least that’s in theory, soon I will find out if it actually works :stuck_out_tongue_winking_eye:)

Also almost ready:

  • Pokitto to Ethernet client for Win & Mac (Linux soon)
  • Simulation (!) of connection from PokittoSim to server via SDL_net so that you can develop locally without devices!

Zoom in on picture below to get an idea of how it works!

EDIT: oh yeah, the telnet part is for making the connections and handling the chat. Once game is linked, a binary protocol is used.


Lobby, chatting, multiplay, wow! This sounds like a real console multiplayer environment!


Have you got any working games yet, or is the ‘games joining’ theoretical?

I’ve actually been trying to modify Noughts & Crosses to work over a local serial bridge*, but I’ve been taking my time trying to design a connection system that will be robust instead of trying to duct tape something together, so all of my existing work is theoretical pencil & paper stuff.

I considered taking an “everything happens on the server, the games are just dumb terminals” approach, which would be a lot easier, but I decided that if I use the serial bridge approach then the system ought to be able to work with a ‘dumb’ link cable connecting two Pokittos via the PEX.

Might still be a while before I produce anything, haven’t had much time for programming lately.

* I.e. a computer program that takes two serial streams and forwards the data between them as if they were connected directly


Yep! This will be the real deal:


We are very close to actual games. I will start testing with a multiplayer snake game soon.

The lobby system is essential for the whole thing to work, there are a lot of “states” that the users, sockets, games etc. can be, there can be sudden disconnects etc. I’ve mostly got the server working now in a way that it can detect the commands and clean up if someone disconnects etc.


It would be interesting to see what is the latency.



just tried it

relaying through a cloud server in US

Didn’t measure any statistics but it was surprisingly good.


This is something I picked from the net. Rating of latency values for multiplayer games:

  • green: 0-80 ms
  • yellow: 80-170 ms
  • red: 170-300 ms
  • black: 300+ ms

Depends a lot of the type of the game, of course.


Ladies and gentlemen

I give you

Internet-connected gaming on Pokitto

Even though they are side by side, these two pokittos are connected via internet to a server in USA and back to Finland.

(Note the delay before the game begins is caused by syncing issues*, but the latency is completely playable)

* syncing was done with a brute force exchange of data where host and client negociate which is which. I didn’t put any limit on the data they were sending each other, and therefor the buffers on both side got clogged with alot of data = hence the delay


It’s fascinating to watch how many brute-force attacks and with different strategies are being tried from all around the world.

Luckily the server is not running anything worthwhile, but its just crazy. All sorts of ports are being tried to see if it just happens to be a windows server or running voip services etc.


Is it possible to implement a global high score list with this system? Like having a global list of best track times per track in Pokitto Grand Prix?