[Discuss] Universal Multi-Player Link Cable

[crait]

Alright, there have been a few threads that have died out, so I’m hoping this won’t.

Let’s discuss what’s the bare minimum to develop a multi-player link cable. From my understanding, we just need 3 wires, but I’m still a noob when it comes to this stuff.

Outside of those wires, we’ll need some kind of function in the Pokitto library to send and receive data. It would be nice to have a simply library that could wrap those functions as well as offer a hand-shaking solution.

To recap, we need to get these things to get multiplayer games:
• Cable
• Data exchange library
• Cool Example Game

I’m willing to help work on some of this stuff, but I’d need some more guidance and input from everyone else.

[Pharap]

IR tranceiver was the second most popular ‘hat’ in the poll back along.

Hat of many things

ok lets put this to a vote please consider that ech item you choose will increase cost to pick as much as you want but just be aware of it these where the ones talked about so far, any more are always welcome buttons IR transever rumble moter gpio passthrough wifi/BLE gyro/accelerometer/magnetometer GPS 0voters Choose up to 7 options Vote now!Show results also this, there a few ways to implement it everything on gpio will give you fast access but you may need to deal with some dec…

So it’ll probably be IR. Dunno what IR libraries are available or how good the timing is on IR. It was good enough for tamagotchi way backwhen though.

---

If it were a cable, what sort of protocol were you thinking?
It would need a clock line and some error correction (maybe a parity bit or something).

---

To be honest though, unless someone (or a group of people) want to work on this individually, at the moment I think this sort of thing would be a better goal for a few months down the line. I think getting the tutorials and shop up are more important at the minute, as well as solving the EEPROM vs SD issue.

I’m still happy to speculate though.

Also if you want to look at what it’s like to use the PEX, I’ll be working on the drafts of the tutorials for it.
Really though, since you’re already an experience programmer, you just have to look at the docs here:

https://docs.mbed.com/docs/mbed-os-api/en/mbed-os-5.5/api/namespacembed.html

DigitalOut is a 1/0 output pin, DigitalIn and DigitalOut are obvious, as should be AnalogIn and AnalogOut.
I haven’t gone through the rest myself, but things like CircularBuffer, I2C and SPI you probably recognise.

[adekto]

guys just take I2C its easiest and already there
you just have to figure out who is slave and who is host

i would still use a dedicated chip on a IR hat just to make it easy

also there might be “backwards?” compatibility with the old gamebuino

[crait]

Uh… I understand some code already exists, but I am wanting to package it nicely for Pokitto games with some wrapper library that is game-specific.

[crait]

So it’ll probably be IR.

To be frank, I don’t care about IR at this point. It would be cool built in, but mulitplayer games with a cable will likely work best and be more accessible.

To be honest though, unless someone (or a group of people) want to work on this individually, at the moment I think this sort of thing would be a better goal for a few months down the line.

I will be needing to do this work anyway for my TCG game, so I figure the earlier I get the conversation going, the better.

[Pharap]

also there might be “backwards?” compatibility with the old gamebuino

The internet seems to suggest there wasn’t IR multiplayer on the gamebuino (unless I’m looking at the wrong links).
I found a video of people doing 3-cable multiplayer though.

I found a forum indicating that IR might not be reliable enough to implement I2C sadly, since as they said:

“IR remote signaling and I2C are really not interchangeable things. An IR transmitter (the Remote Control) is a “spray and pray” device. It sends a signal out into the ether hoping there is a receiver within range that can receive an act upon those signals. There is no confirmation, there is no feedback, there is no guarantee of reliable delivery.”

I don’t think I’m qualified enough to know whether it is or isn’t though since I haven’t yet used either.
All the communication protocols I’m used to are internet and cross-program protocols.
I hear “spray and pray” and I think of UDP :P.

Although now I think about it, I recall @jonne mentioning that he wanted to be using bluetooth low energy in future (and I see that you were there considering it too).
In fact you said “its meant for close range wearables and similar” so maybe BLE multiplayer is a good idea?

Aparently throughput for BLE is on the order of kbps (according to here), so you might not be doing anything fantastic, but I think that should be enough to send simple state updates.

Just a though.

---

To be frank, I don’t care about IR at this point. It would be cool built in, but mulitplayer games with a cable will likely work best and be more accessible.

The comment about IR is fair (though it’ll probably remain a hat rather than built in), but like I said, a cable requires a protocol. Do you have any in mind?

The library I linked to was only enough to do basic PIN stuff and a bit of SPI/I2C.

I will be needing to do this work anyway for my TCG game, so I figure the earlier I get the conversation going, the better.

Fair enough.

[adekto]

well just for the record i still want to do a wifi hat (since in curently wifi is cheaper then bluethooth due to the esp8266)
but the point remains that I2C saves us there creating it more universal

still im not sure what exactly you want as a library ontop of it what features you looking for since you can already send and recive packets of data

also anyone want to help with this?
or this?

[Pharap]

well just for the record i still want to do a wifi hat

Of course, I’m just trying to focus on the ‘how to do local multiplayer’ issue for now though, Wifi is a whole other issue.

also anyone want to help with this?
or this?

Hrm, I see someone mentioned UART in the first link (which I think is the same as what is normally called ‘Serial’ on Arduino) could be a viable cabled option for @crait.
There would still have to be an ‘application level’ protocol though.
Something to say how many bytes to transmit and wha’ts being transmitted. (And maybe a checksum to be safe?)

[adekto]

i think i2C is good for that since it acknowledges any received data, its been a while since i last looked at it

anyway softwareI2C is in the pokittoLib/POKITTO_HW
so why not just try it out
i still dont know what data you want to send

probebly starting with a string of the game with a version number so you know both devices know what there talking about

[mwm]

Are you thinking about I2C to talk to an IR dongle or some such, or as the protocol to use between two Pokitto? If the latter, you might want to think about USART instead of I²C. Personally, I think serial is easier to deal with than I2C, but if you’re going to wrap it in a game library only the implementer cares.

USART has two major advantages: First, USART is easily mapped to other media relatively inexpensively. Want to talk to an emulator on your desktop? Connect your USART pins to a USB/serial chip. Want to go wireless or play with the game on an Android phone? SPP BT dongles are about $3 each for the more capable ones. I’m already planning on doing adding one of those to my Pokitto to use it as a robot control device. Second, it looks like you get about an order of magnitude more distance with similar cabling using USART. Haven’t really played with it, so I can’t say for sure, but going from “sitting at the table” to “sitting around the room” seems like a nice upgrade.

I²C has the advantage that it’s a bus, not point to point. So if you want more than two players, you can just connect them all together. This means you have to assign addresses, even in the 2-player case, which isn’t required for serial.

When you’re talking about the code being “already there”, this should be the Serial library in the reference Pharap posted. There’s also a USART driver in the NXP ROM along with the I²C driver, so not a lot of memory required to implement it.

[crait]

Are you thinking about I2C to talk to an IR dongle or some such, or as the protocol to use between two Pokitto? If the latter, you might want to think about USART instead of I²C. Personally, I think serial is easier to deal with than I2C, but if you’re going to wrap it in a game library only the implementer cares.

Is this directed at me? As the title implies, this discussion is supposed to be limited to a link cable, AKA a WIRED connection and not a wireless connection.

[mwm]

No, to those discussing the concept in general. There was some mention of an IR link, which would imply an IR dongle of some kind which might well use I2C. In that case, the suggestion of serial is sort of pointless. But if the discussion was about using I2C over that cable, then USART might be a better alternative depending on the goals.

[NullMember]

I think nobody want IR over i2c. Basically old gamebuino using i2c for multiplayer wired connection and for backward compatibility people want to use i2c. That’s what I understand. Am i wrong?

[adekto]

i2c is best for link cable, its less wires, it can address more then 2 devices (think of party games or racing games)

SPP BT dongles are about $3 each for the more capable ones. I’m already planning on doing adding one of those to my Pokitto to use it as a robot control device.

for the other peripherals, like wifi, bluetooth or IR the problem is that the pokitto has to handle these timings, setups and other specifics, the idea there if its over i2c or spi dousnt matter to much just that its all the same, but the just talk over the same system like the library just sends over “king D8 d7” and then the wifi/BLE/IR sends it to the other device just like its a link cable
this is why i sugested the hats could take control a text interface to config there settings like setting up the wifi pasword or calibrating the IR modules or linking the BLE with another one

[mwm]

i2c is best for link cable, its less wires

I don’t think that’s the case. For I2c, you need SDA, SCL and ground For a serial link, you need RX, TX and ground. Serial can have other wires, but these days they tend to be for specialized uses, not simple comms. Either one may need a power line if one of the two ends isn’t getting power from another source.

[quote=“adekto, post:14, topic:619”]
for the other peripherals, like wifi, bluetooth or IR the problem is that the pokitto has to handle these timings, setups and other specifics, the idea there if its over i2c or spi dousnt matter to much just that its all the same[/quote]

The same is true if those devices communicate via serial link. Is it possible that what you thought I was talking SPI? It does require more wires (4 signal + ground) and is intended for communication between devices on a PCB. But that makes it a really bad choice for talking over a link cable.

If you’re thinking about a bit of hardware that plugs into the PEX header and provides communications, then it’s to early to worry about the protocol. You really want to figure out what hardware you’re going to use, and then use a protocol the most suitable hardware uses. Talking to the actual comm device is going to require code specific to that device. If that runs on the Pokitto, then it needs a library specific to the comm device. If you put an µcu in the link device to talk to the comm hardware, it can provide an API specific for this. I think that’s over-engineering the problem, though. But if you think it’d be fun to do - that’s what this is all about, so go for it!

I’m thinking more of something you can toss together with minimal hardware. A scratch setup would connect a pair of pokittos with breadboard jumper cables. You could DIY a cable from a pair of male DIP plugs and a USB cable (the signals use the USB signal lines, the others are wired to ground). Serial is designed for two relatively intelligent devices to talk to each other, which is what you have with that kind of cable,

I think the best protocol will depend on the architecture of the game. I2C has a master controlling a slave with a half-duplex link. A modern serial link is a symmetric, full duplex link. So if your game runs on one Pokitto, and primarily treats the other as a second (third, etc) controller/display, then I2C will be better for you - the link matches the design. In the extreme case, the in-game library could be a Pokittolib-like object, and the second (third, etc.) Pokitto runs a standard app that implements the other end of that object, and is usable with any game that uses the library. The advantage here is that your game is a lot simpler, it’s just one game with multiple controllers. The downside is that you’re not really taking advantage of having multiple cpus.

If you want your game to be a symmetric distributed system, serial would work better. Each Pokitto runs it’s won copy of the game, and deals with what it’s user does and sees. When that causes an event that affects the other player, it spits out a message to the other end - no need to wait to be asked if it’s the slave, or poll the slave if it’s the master. The game can monitor the serial line in whatever fashion best suits it - either letting it generate interrupts, polling it at regular intervals, or some third option. The upside here is that each player gets the full power of a Pokitto to run their game. The downside is that you’ve got a distributed system, which comes with a lot of headaches (believe me, I build distributed systems for a living; and know whereof I speak. Building robots and embedded remote control systems is just a hobby :-).

Of course, either protocol can be made to support either architecture. Picking a protocol that matches the architecture just means it takes less code to get it done.

[adekto]

this still isnt going help
if its a lib and someone makes a hat with that specific bluethooth module and someone else made one with another that has another protocol you have to put faith in that any multiplayer game is going to update the code for it

wile the thing i prepose with a standard “driverless” interface would give us a solution later down the line even wen the game was made before these modules exist

and its not that much harder then writing the interface for any of the others and an attiny is cheap to add to any hat

also it conserved flash on the pokitto since it dounst need any other “drivers” for every posible device

i would even argue you could add extra functions like plug and play

[adekto]

going back to the actual hardware cable
what did you have in mind

to get from i2c to ground pin on the layout you could use a 8pin ribbon cable and a male to male pins to flip the plug type

but it think you need to modify the cable to cross a wire or 2

[MLXXXp]

Is it possible that what you thought I was talking SPI? It does require more wires (4 signal + ground) and is intended for communication between devices on a PCB. But that makes it a really bad choice for talking over a link cable.

The same goes for I2C (which stands for Inter-Integrated Circuit). Like SPI, I2C is also only intended for communication between components on the the same circuit board or between closely spaced boards in the same unit. The only reason that I2C works better for longer distances than SPI is that I2C data rates are generally lower than SPI. I2C has a maximum clock speed of 3.2mbit/s. SPI can be clocked at 10s of MHz.

[crait]

Basically old gamebuino using i2c for multiplayer wired connection and for backward compatibility people want to use i2c.

I don’t think we should hold the Pokitto back if there are better options out there just because the Gamebuino did something a specific way in the past. From my understanding, there were not that many Gamebuino games that even used link capabilities.

[crait]

you want your game to be a symmetric distributed system, serial would work better. Each Pokitto runs it’s won copy of the game, and deals with what it’s user does and sees. When that causes an event that affects the other player, it spits out a message to the other end - no need to wait to be asked if it’s the slave, or poll the slave if it’s the master. The game can monitor the serial line in whatever fashion best suits it - either letting it generate interrupts, polling it at regular intervals, or some third option. The upside here is that each player gets the full power of a Pokitto to run their game. The downside is that you’ve got a distributed system, which comes with a lot of headaches (believe me, I build distributed systems for a living; and know whereof I speak. Building robots and embedded remote control systems is just a hobby :-).

This path seems better, in my opinion. What are some of the roadblocks you can imagine seeing with this route?