Why not making a LAN game?

It’s too difficult for me. :joy: My major is chemistry and I learned programming by myself. Maybe I can use LabVIEW very well or sometime use Arduino to program the instrument. To be honest, I don’t really write a game. I can give suggestions to whom writing new capabilities and make new hardware design.

I found a virtual pet handheld device last month. And it has a function, let pets in different devices fight together. A two-wire line has been used to connect them. So maybe we can add message exchange function in new game? :thinking:

That’s kind of the problem, it’s too difficult for a lot of people. :P

It’s doable, but it’s quite a bit of effort.

I have no clue what a ‘major’ is but I’m also mostly self-taught.

I hadn’t heard of this. It’s quite strange.
It reminds me of a circuit diagram.I like the old-fashioned UI though.

As I said before, you need a computer of some kind in between two Arduboys to allow them to communicate.
USB requires one host device and one non-host device, and the Arduboy can’t be a host.


Figuring out what the ‘messages’ should say is difficult.
Getting something simple working isn’t too hard,
but there’s lots of things that complicate it:

  • Trying to prevent cheating
  • Making the protocol future-proof
  • Detecting when a device has disconnected accidentally requires some kind of mechanism
  • Making sure data doesn’t get lost if someone disconnects and rejoins
  • Possibly detecting communication errors (depends how stable serial is)

You also have to decide if you want to allow a network between two or more computers, so the Arduboys don’t have to be at the same location. And if, in this scenario, you also allow multiple Arduboys on any of the computers.

Arduboy <--> Computer <--> Network <--> Computer <--> Arduboy
             Arduboy <--> Computer <--> Arduboy

One of them need to be a server, the other a client.

The client can send messages to the server by adding characters after IP or DNS:



From the serer side you can catch the string after the DNS or IP.

The server interpret that the client is going forward, left and shoot.

The server can respond with a http plain text:

The client need to do what the server tell it to do, the client send the keys that you pres to the server, the server tell the client the map, map location, player location, angle, shoot and other data, for a simple aproach.

You find 1000 examples of servers in C#, as client VS2003 and up have integrated http client.

I made a 2 player game which uses the serial port. It requires a host PC or raspberry pi running a python script to relay communication between the two Arduboys.


That’s what I meant by:

Of course, you more or less have to get it working locally before you can get it working over a network.

And passing the packets over a network adds yet more potential headaches to the equation.

Now that’s one possibility I hadn’t considered.
And again, yet more headaches to deal with.

You probably wouldn’t want to be using HTTP at all.

Generally video games use UDP or TCP for transporting data.
UDP would be good (if the potentially dropped packets and data sequencing can be handled somehow),
and TCP would be slower but probably still ok,
but HTTP is a layer too far - it’s TCP with added overhead.

SCTP would probably be the best transport option because it fixes many of TCP’s issues and has sequencing and dropped packet handling. assuming the larger practical datagram size wouldn’t be an issue.
Unfortunately I’m not aware of any SCTP implementations.
(See also: this transport layer comparison table.)

Having to parse plaintext info rather than using raw binary data would also waste time, though admittedly I expect most people’s computers would make short work of string parsing.

Ummm… LabVIEW is developed for those who can not write code “line by line”. It’s a beginner-friendly program tool and I haven’t used C++ or C# anymore since I learnt this. :joy: The program execution efficiency is not high, but the writing is simple.
I have written a controller for an automatic instrument. The computer sends instructions through RS485 serial. Maybe we could use a special arduboy as the server which contains several serial ports. Or maybe, we could use the one-line serial port just like DS18B20 to exchange “messages”.

I give the http example because is a very very simple implementation for beginners ( several lines of code in Visual Studio C# ), from here everyone can go deeper to study the issue, to communicate between arduboys is not needed to use professional communication protocols, arduboy refresh the screen at between 30 and 60FPS sometime less, a http implementation do the joob very well.

In today era of devices if you are not doing something complex you don’t need to worry about overhead of the http, a raspberry zero will be able to server at least 1000 simple requests /second.

Today are dedicated cheap modules you can use to communicate with an UART interface thru internet, two arduboy’s using these modules can see each other like they are connected directly thru UART ( with a little lag, but… ), I am not sure if they support point to multi point connection.

These days I purchased this device.

Unfortunately I do not have to much time to play with it, but as soon as I have a script or application to run on to fit in this situation I will publish it.

Are you expecting people to open up the Arduboy and solder to the internal pads to access additional I/O? Most people wouldn’t want to do this just for multi-unit gaming.

The only access to an unmodified real Arduboy is through USB and only with the Arduboy acting as a device, not a host.

Actually, there’s also the possibility of using sound from the speaker or light from the RGB, TX or RX LEDs or the display but that would only be one way, from the Arduboy. You might also be able to receive using light but the two Arduboys would have to be very close and facing each other, so not very practical for this purpose. (OK, maybe you could use an optical fibre or other type of light pipe to separate the two units with optical communication.)

It would have been neat if you could use the speaker as a mic and do wireless communication through high frequency sound but I don’t believe it is possible

Unfortunately, neither of the speaker pins has analog input capability.

Yeah it’s a shame that they are on digital only pins. I think the analog capable pins are used for the input buttons? In theory would it have been possible to swap these pins around? (if you were designing a new Arduboy board with the same components). If so, wouldn’t it have been possible to do some more interesting sound effects with the buzzer too?

We wanted the speaker to be on pins that had timers associated with them. When I recommended (Arduino) pins 5 and 13 it was because they had a complimentary pair (OC4A), for easily generating a higher volume, as well as a second timer (OC3A on pin 5) for generating separate timer signals on each pin.

In retrospect, it might have been better to use pins 9 and 10 for the speaker and move the RGB LED to pins 5 and 13. We chose 9, 10 and 11 for the RGB LED because they’re all on the same port but that probably shouldn’t have been a consideration. However, using this new arrangement could cause some conflicts between using timer 4 for the speaker and the RGB LED in analog mode at the same time.

Only my thought:

Use ADC for keypad, they do not need a higher resolution than 60 check’s/second, you put directions to one input and A-B to another using resistor divisors, this way you save four pins and you avoid the situation where the ADC is between transitions, you do a three stage average to see what keys are press.

You put a service routine to start conversions, and at the other end you translate voltages to bits asserted/de-asserted.

You will lose about 1-2% performance due to service routine execution and increase the power consumption by ~1-2mA if you let the ADC in free running, but, hey, you gain four pins to do anything you want.

You can start the ADC conversion at beginning of every frame refresh, and collect the keys ( process the ADC values and translate ) at the beginning of the next frame, this way you decrease the power consumption due to ADC IDLE state and decrease the execution time.

The ADC keyboard is reliable enough that is used even in industrial equipment.

For LED’s you put two of them in series between VCC and GND, in the middle you connect a pin, when the pin is input, no led is powered, if you set it as 0 or 1 and oscillate it display refresh rate and 50% input/output you power one of them, if you set the pin as output and oscillate it at display refresh rate you power both.

3.3V is not enough to power two LED’s in series, you free another pin :slight_smile:

Maybe on a further project :slight_smile:

The Arduboy wasn’t intended to be expanded, so there was no lack of pins. Doing this just adds extra resistors and, as you said, slows things down.

Got it.

That’s unfortunate.
C++ and C# are both very good programming languages.

It would probably be possible to use a Raspberry Pi as a bridge.

Ultimately all the ‘middleman’ device would need is:

  • USB hosting capabilities
  • Reasonably good CPU capable of handling the requests (e.g. maybe an ARM CPU)

UDP is also quite simple:

Though admittedly, as I said before, sequencing and other things may complicate matters.

Yes is quite simple until packets are not received in order that are transmitted and other packets are not received at all. :+1:t2:

Maybe a Zigbee wireless serial transceiver module is more stable? I don’t know. I just found this https://item.taobao.com/item.htm?spm=a230r.
It seems easier than other wireless communication modes. And it just costs about $4.7