With the VB-PC link cable finally becoming a reality, I think it’s time to discuss how we should implement the software and protocols for online play, which I came up with over 5 years ago.

I think three pieces of software have to be written:

1. A library to let programmers easily add multiplayer to their games. Besides low-level things like sending and receiving bytes over the link port, it should also provide some higher-level functions to communicate with #2 (below), in-game chat, game state synchronization across clients, etc. Ideally, the library would present a game running over a VB-VB link cable as a special case of a game running over a VB-PC cable, just with one other player, so that programmers don’t have to write the same code twice and can support both kinds of cables even if they only have one.

2. A program running on the PC to act as a proxy for the VB to communicate either with another instance of itself on a remote computer or with #3 (below). It would let players join an existing game or start a new one – public, private, or peer-to-peer. This program would probably be written in Java. I don’t like Java, but like Guy Perfect has said, it’s the most portable way to make a GUI, or at least it takes less effort than with C or C++.

3. A server program to keep track of running games. The address wouldn’t be hardcoded in #2, but rather there could be multiple such servers, though it would be most convenient if PVB ran one.

Of course, all protocols involved would be documented and not limited to just one implementation. For example, #1 should probably be written in C for ease of use, but at least a minimal assembly language version should be available to retrofit into commercial games.

Questions:

* What’s the best place to implement most higher-level multiplayer functionality? #1 has the advantage of supporting both local and online games on the VB side, but #2 avoids the need to write separate code for each game, and bugs can be fixed by just updating #2 instead of all games using #1.

* There should probably be some PVB integration on both sides: PVB could show games in progress like it shows which users are online in the chat, and there should be an API to download high scores – maybe also upload them, though it’s harder to prevent cheating then. What else?

* How do emulators fit into this? There should be at least a way to test multiplayer code on them, which requires some kind of connection to #2. I assume that the VB-PC cable will present itself as a serial port. On Windows, virtual serial ports can be created with com0com, so #2 only has to support serial ports, but emulating a link port with a socket might be better for other platforms. Reality Boy already emulates the link port with sockets, so this is also more consistent in the sense that virtual VB-VB and VB-PC cables are the same thing from the software’s perspective.

What do you think?

We’ll add a communications class to the VUEngine soon, which allows multiplayer matches. It won’t matter what talks on the other end of the cable, be it two or more VB’s connected locally, or a PC program on the other end that communicates with other VBs over the internet. At least that’s how I picture it, Jorge will do the actual implementation of the class.

I REALLY hope we can get online multiplayer to work! It would be amazing to run an online service where you can play any future multiplayer VB games against each other. We’ll need to negotiate some standards to make that possible. Besides the VUEngine implementation, there should also be one in libgccvb. I think thunderstruck already worked on getting that done.

PVB sync would be nice, so that cartridges can linked to PVB accounts, highscores can be synced, etc. Then there could be a frontend integrated right in PVB.

It would also be really cool to offer a “spectator mode”, where people can watch online matches of others, right on their VBs.

Don’t underestimate the impact of network latency. Games intended for internet use need to be designed for it.