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.
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.
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. 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.
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.)
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.
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
There are probably a bunch of better ways you could do communication if you were redesigning the Arduboy or making hardware mods but I was trying to see what could be done with two standard Arduboys without needing to change the hardware.