Basically, all the communication lies upon sending and treating strings. The client and the server run thread listening to message incoming from NXT Bricks or other computer and send message according to the previous message received and the commands given by the user.
This structure that we came up with is exactly the same that the one we designed at first when we created the architecture of the communication layers. The results of such an architecture went better than expected because we thought the Bluetooth would shorten our range of action: it didn’t and we were able to play on the whole playground. Nevertheless, our next step for this project would be to use the Wi-Fi for the communication between the computers and the brick. The smartphones would be the key here and would ensure the Bluetooth communication with the brick with no range problems. This way, we would obtain a more suitable communication.
Besides, we’d like to extend the game for multiplayer purpose and change the “Server-Client” protocol so as to be able to run the server on a different machine and add as many clients (players) as we want on different machines.
Doing all of this would also give a better and easier interface for the user in order to launch the game and settle everything without being forced to follow a intricate procedure as we explain in the “How to start the game” part.
We would end with this structure applying the new strategy. We would have to develop our own Android application in order to do that but this would upgrade considerably the range of the robots and upgrade the setting up for each game. The Android application would ensure a good communication and implement the streaming part in our own way (instead of using a pre-existing software that we used for the project) and get smoother image this way.
This way, the new structure would allow as many players as the battlefield can support and at least open the game to a lot of new scenarios (leading to game with team, capture the flag mode for example).
 |
This was working properly and the robots were responding quickly but this was not the end, indeed. We wanted to control the robot in a more instinctive way. That’s why we decided to use the Microsoft Xbox 360 wireless controller[1] in order to control the robots (see Picture 26 : Microsoft XBox 360 wireless controller).
The question being would be to ask why using a controller instead of the keyboard. For this, there are several answers but the main one is because we want the game to be immersive. And knowing that our robots only have less than 20 commands available, it was easy to map every command on the controller (thus, it was more comfortable to use according to our own tests and the opinion of other testers). So we mapped the 8 directions on the left stick (and this way, the behavior of the robot was very intuitive), used the colored buttons for defusing purposes, the triggers for changing the speed of the robot and the Start button for planting the bomb.
 |
| Picture 27 Wireless gaming receiver |
In order to make the use of this wireless controller possible, we needed two different things:
· The wireless gaming receiver[2] (which is an adapter for PC in order to connect Xbox 360 wireless controller) (Picture 27 : Wireless gaming receiver)
· XPadder[3] (a software useful for mapping keyboard keys on controller buttons).
So as to explain the mechanisms of XPadder, here’s a picture showing which key was mapped to which button (you’ll have a better idea of how the commands are organized).
 |
Picture 28 XPadder key/button mapping overview |
[1] Xbox 360 Controller : http://en.wikipedia.org/wiki/Xbox_360_Controller
[2] Wireless Gaming Receiver: http://en.wikipedia.org/wiki/Xbox_360_accessories#Wireless_Gaming_Receiver
No comments:
Post a Comment