Download HYDRA Game over Internet

HYDRA Network Control and Visualization
Scott Marks and Rick Haberkamp
CNT 4104 – Computer Network Programming
Dr. Janusz Zalewski
October 8, 2008
Marks & Haberkamp
Table of Contents
Table of Contents
2
Section 1: Introduction
3
Section 2: Problem Description
7
Section 3: Solution
10
References
16
Page 2 of 16
Marks & Haberkamp
Section 1: Introduction
General Information
The XGameStation HYDRA Game Development Kit is an advanced version of the simplistic
XGameStation Pico Edition 2.0 console. The HYDRA console, pictured in Figure 1.1, is controlled by
Parallax’s Propeller multiprocessor, which is comprised of eight 32-bit processors. The Propeller can run
programs written in Propeller Assembly language, Spin object-oriented language by Parallax or a
combination of both [2]. Spin is comparable to C++ since it has direct control over the eight Propeller
processors and memory. [3]
Figure 1.1: HYDRA gaming console with a 128 KB game cartridge attached [1]
Embedded Systems Programming Project: Programming an Internet Interface
Concept Overview. This previous project’s goal was to implement an interface that would allow
two HYDRA consoles to communicate over a network via attached computers. A USB cable connected
each HYDRA to a PC and serial communication was achieved using serial-to-USB drivers. The computers
then acted as relays by passing HYDRA game state information across a network or the Internet. Figure
1.2 depicts the setup organization and flow of data communications. There were two aspects to this
Embedded Systems Programming project: the HYDRA game and the PC software.
Page 3 of 16
Marks & Haberkamp
Television
HYDRA Game System
Computer
NES Controller
NES Controller
Television
HYDRA Game System
Network Hub / Internet
Computer
Figure 1.2: Equipment configuration and data flow diagram [3]
HYDRA Game. A simple game of “tag” was created for the HYDRA consoles. As shown in the
Figure 1.3 screenshot, two ghosts, one controlled by each HYDRA player, could move anywhere on the
screen. The object of the game was to avoid being “it” by tagging the other player’s ghost but not be
tagged back by the other player afterward. The game did not include any means of scoring or rule
verification—these components were to be managed by the players.
The game was built using peer-to-peer communication so only one version of the software was
required (not two for a server and client). The game worked by each HYDRA controlling one ghost via it’s
connected controller. The game software would send the x- and y-coordinates of its ghost to the other
HYDRA via the project’s developed network interface. The other HYDRA would receive the coordinates
and display the player’s ghost in the appropriate place on the screen. This process was also completed in
the opposite direction so that both players saw the same screen.
The difficulty in creating this game software was the need to develop a method of
communication. This was completed over serial-to-USB by passing individual bytes of information. Each
byte utilized one bit that designated it to be an x- or y-coordinate. We arbitrarily picked the least
significant bit to be the coordinate bit—zero to represent the x-coordinate and one to represent the yPage 4 of 16
Marks & Haberkamp
coordinate. If a packet of information was lost somewhere along the line of communication, the ghost
would simply be updated on the reception of the next packet containing the dropped coordinate byte.
This was a simple solution that provided error checking and was easy to implement.
Figure 1.3: HYDRA game screenshot [3]
PC Software. Originally, this computer software was built in Java since we were both significantly
more familiar with Java than any other language. During testing, which utilized a HYDRA chat example
provided in the HYDRA Development Kit, it was learned that Java uses Unicode instead of ASCII. This
created many problems with communication and was ultimately scrapped. With the project deadline
quickly approaching, we switched to Visual Basic .NET to program the PC software. This was decided
because of the ease at which VB.NET handles sockets, threading and serial communication, which were
all essential to this program.
Unlike the HYDRA game software, this HydraNet program required a designated server and
client. In order to give the users the most flexibility and to save on programming unneeded code, we
created one application that had the ability to act as either role per the user’s instructions. Each player
was then asked set up questions such as IP address and COM port. The user could exit the program by
either typing “exit” at the “Enter a command:” prompt or by using normal Microsoft Windows closing
techniques. A screenshot of both iterations of the software can be seen in Figure 1.4.
Page 5 of 16
Marks & Haberkamp
Figure 1.4: HydraNet server (top) and client (bottom) running on the same PC [3]
Results. Overall, the Embedded Systems Programming project was a success. Both the HYDRA
game and PC interface programs worked effectively and without error. For further information about
this previous project’s background, implementation and source code please see “Programming an
Internet Interface for the HYDRA Game Development Kit” [3].
Page 6 of 16
Marks & Haberkamp
Section 2: Problem Description
Definition of Problem
The goal of this project is to create a multiplayer game to run over a network using a single
HYDRA console for game state computation and multiple computers running the HYDRA game
visualization and controls. The equipment configuration and data flow is shown in Figure 2.1. This
method has several advantages over the project completed in the Embedded Systems Programming
course. Among the most obvious advantages are:
1. Support for two or more players
2. Only a single HYDRA is needed
3. No televisions are required to observe the game state at any given time
4. No extra (non-standard) controllers are necessary
5. The game can be played anywhere there is a PC with an Internet connection
Computer / Client
Computer / Client
Computer / Client
Network Hub / Internet
Computer / Server
HYDRA Game System
Figure 2.1: Equipment configuration and data flow diagram
Page 7 of 16
Marks & Haberkamp
Prospective Solution
Our basic network layer organization, shown in Figure 2.2, will be comprised of five main layers.
The HYDRA will have the game application (layer 0) along with the data transmission and USB driver
(layer 1). The PC connected to the HYDRA will have the server transport software (layer 2). The
computers operated by the players will have the client transport software (layer 3) and the game
simulator application (layer 4). Each PC connected to the server will be required to individually run the
client software and game simulator application, which will probably be combined into one program.
Application / Game Simulator
(PC)
Application / Game Simulator
(PC)
Application / Game Simulator
(PC)
Client Transport Layer Software
(PC)
Client Transport Layer Software
(PC)
Client Transport Layer Software
(PC)
Server Transport Layer Software
(PC)
Transmitter / USB Driver
(HYDRA)
Application / Game
(HYDRA)
Figure 2.2: Basic network layer organization
Prospective Implementation
The single HYDRA game console will assume a server-type role for the multiplayer game and will
essentially have the following three tasks:
1. Handle all communication received from clients connected through the Internet
2. Change game state appropriately
3. Send out game state information to all clients
The HYDRA will be directly connected to a PC (Figure 2.1) in order to give it access to an Internet
connection and allow other computers to connect as clients. All PC-to-PC communication will take place
over the Internet through a standalone application. The programming language of choice is C# since this
language has many uses in the real world, we have little experience programming with it, there are
Page 8 of 16
Marks & Haberkamp
numerous similarities between C# and Java, and porting the previous project’s VB.NET application
should be easier than porting to another language such as C++. However, if unexpected problems arise
with this language we will probably switch to C++ or Java.
Remote Game Development
In order to allow a remote developer to connect to the server and upload new games to the
HYDRA console, we will have to include Parallax’s Propellent DLL library in our server. This library is
provided by Parallax specifically for communicating with a Propeller multiprocessor from a PC over a
serial port. The Propellent library includes support that will allow us to: establish a connection to the
Propeller chip on the HYDRA, compile the source files, upload compiled files to it, reset the HYDRA
console and then finalize the changes before unloading the Propellent library [4]. Without this library,
uploading game files from the Internet to the HYDRA would be nearly impossible to complete in a
semester-long project.
Anticipated Hurdles
The primary challenge of this project is how to differentiate between each player’s controller
(keyboard) inputs in the HYDRA. Previously, it was trivial to discern between x- and y-coordinates for
one player’s ghost. This project must utilize a significantly more advanced method. Since there are no
socket-type methods of serial over USB communication written in Parallax Spin, we will have to research
on proper algorithms for this type of data relay. If this problem cannot be overcome, we may have to
resort to calculating each player’s position on their computer and sending this information to the
HYDRA. This will still be more complex than the previous project but should be simpler to implement
than passing controller inputs.
Other issues that may arise during this project are also related to message passing and data
handling. To summarize these concerns, they are listed below in question form:
1. How will the HYDRA cope with the volume of incoming player input data?
2. How will the HYDRA differentiate between each player and between different inputs?
3. How will the HYDRA effectively output all player positions?
4. Will the computer server software easily handle multiple clients with significant data
transfer?
Page 9 of 16
Marks & Haberkamp
Section 3: Solution
Server Program Description
The server application, as diagrammed in Figure 3.1, will be expected to handle communication
between itself and each of the clients, as well as communication between itself and the HYDRA. Upon
running the server, the socket server will be initialized and two threads will be created to establish
communication to and from the HYDRA. An additional thread will be created that will wait until an exit
command is issued from the server's console. Next, the server will enter a loop that will listen for clients.
Upon a client connection it will determine if the client is a player or developer, and then create an
appropriate thread for each client connection.
Initialize socket
server
Create HYDRA
send/receive
threads
Create thread to
check for exit
command
While true
true
Listen for clients
Create client
player thread
true
If client is a
player
false
Create client
developer thread
Figure 3.1: Server program flowchart
Page 10 of 16
Marks & Haberkamp
Server Program’s Developer Thread Description
This thread will be created by the server application, and will handle communication between
the server and a developer client. After a developer client has connected, it will receive instructions
from the client that tell it which files should be uploaded to the HYDRA. The thread will then upload the
appropriate files to the HYDRA, along with any support files that may be required, and handle additional
logic required to run the new files on the HYDRA.
Player Client Program Description
In a player client, as shown in Figure 3.2, the application will be expected to handle
communication to and from the server, as well as output the game state to the screen for viewing. Upon
running the client application, a GUI will be created for the user that will display the game state as well
as a few buttons. The user will then input the server's IP and port number, the socket client will be
initialized and communication to the server will be established. The client will send a boolean variable to
the server in order to instruct it that the client connecting is using normal player credentials. Three
threads will then be created upon establishing the connection with the server: one for sending inputs to
the server, one for receiving the game state from the server and one to display the current game state
on the screen.
Developer Client Program Description
In a developer client, which is flowcharted in Figure 3.3, the application will be expected to only
handle communication to and from the server. Upon running the client application the GUI will be
created, which is different than the one a player client will use. The user will then input the server's IP
and port number, the socket client will be initialized, and communication to the server will be
established. The client will send a boolean variable to the server in order to instruct it that the client will
be connecting using developer credentials. Next, the user will be able to select game files to upload to
the HYDRA and then upload those files upon a button press. After this, the client will wait for a
confirmation from the server.
Page 11 of 16
Marks & Haberkamp
Create GUI
Input server IP and
port
Send client type
(player)
Button
press:
player on/
reset
Create thread to
send inputs
Create thread to
receive game state
Create thread to
draw game state
Button
press:
player off
Figure 3.2: Player client program flowchart
Create GUI
Input server IP and
port
Initialize socket
client
Select game files
to upload
Upload selected
files
Wait for
confirmation
Send client type
(player)
Figure 3.3: Developer client program flowchart
HYDRA Game Description
The game will expand slightly on the game produced in the Embedded Systems project. There
will be several distinct differences. First, the number of sprites on the screen will go from two to as
Page 12 of 16
Marks & Haberkamp
many as 4-8. The maximum number of players will be determined by hardware limits that have yet to be
determined. The actual number of sprits on the screen will also vary depending on the number of
players currently connected to the game. Second, the player sprits will change from ghosts to varying
shapes, numbers or letters. This is required to differentiate between multiple players on the screen.
Finally, the HYDRA will implement an all new send and receive algorithms to transmit multiple bytes of
data in packets of information.
Player Information and Inputs Packet
We will use four-byte packets, as shown in Figure 3.4, to effectively communicate player
information and inputs between the server application and HYDRA console. Each packet will begin with
a start byte of all zeros. Our second byte will be used to output the current player count and the
appropriate player number to the HYDRA. This byte is split into two four-bit components, the first four
bits are used for the player count and the last four are used to distinguish which player number the
packet contains instructions for. The next byte is used to communicate the player's inputs to the HYDRA.
It is split into eight individual bits, each acting as a flag that will be 0 unless it is set to 1 to show that an
instruction has been inputted for that action. The bits will be as follows: Player On/Reset, Player Off,
UNUSED, Fire, Left, Right, Up, Down. Lastly, the ending byte will be a series of eight bits, all set to 1.
0000 0000
Start
XXXX XXXX
Player Count and Number
XXXX XXXX
Player Input
1111 1111
End
Figure 3.4: Player information packet
Algorithm to Read Player Information Packet
An algorithm needed to be created to handle the HYDRA’s reception of the packets from the
server application. It is written to handle a packet that is made of four bytes, as described above, that
are padded with a starting and an ending byte. The algorithm, which is listed below, will loop through
continually until a starting byte is encountered (or if the start flag has been set to 1). Upon receiving a
starting byte, the next byte will be checked to make sure it is not a starting or ending byte, and will save
a valid entry into a variable for player_count_and_number.
Page 13 of 16
Marks & Haberkamp
If the second byte received is instead an ending byte, it will loop back to the beginning and wait
for another starting byte (the packet will be lost, but it will be assumed to have been unusable anyways).
If the second byte were to be a starting byte, the flag will be set to let the first block know that a starting
byte has been encountered already, and it will loop back to the beginning, bypass the first statement,
and continue to receive the second byte in the next packet.
If the second byte was valid, the algorithm will then check the third byte. If it is valid, it will save
the byte into a variable for player_inputs. Otherwise, it will follow the same logic of looping back and
setting the flag if the third byte received was a starting byte.
If the third byte was valid, the algorithm will then check to ensure that the fourth byte received
is an ending byte. If it is a valid ending byte, the algorithm will change the player state to appropriately
match the instructions found in the second (player_count_and_number) and third (player_inputs) bytes.
Otherwise, it will loop back, setting the start flag if it was a start byte that was encountered, and wait for
another starting byte.
1. bool start=0; int rec;
2. while(true){
3.
//START
4.
rec=serial.get;
5.
if(rec!=0 || !start) continue;
6.
start=0;
7.
int player, input;
8.
//PLAYER
9.
rec=serial.get;
10.
if(rec==0 || rec==1){
11.
if(rec==0) start=1;
12.
continue;
13.
}else player=rec;
14.
//INPUT
15.
rec=serial.get;
16.
if(rec==0 || rec==1){
17.
if(rec==0) start=1;
18.
continue;
19.
}else input=rec;
20.
//END
21.
rec=serial.get;
22.
if(rec!=1){
23.
if(rec==0) start=1;
24.
continue;
Page 14 of 16
Marks & Haberkamp
25.
}
26.
//CHANGE PLAYER STATE
27. }
Page 15 of 16
Marks & Haberkamp
References
[1] “HYDRA Game Development Kit.” XGameStation: Video Game System Development. 2008. Nurve
Networks, LLC. 19 Feb 2008. <http://www.xgamestation.com/view_product.php?id=33>.
[2] LaMothe, André. Game Programming for the Propeller Powered HYDRA. 2006. Nurve Networks, LLC.
[3] Marks, S., Haberkamp, R. “Programming an Internet Interface for the HYDRA Game Development
Kit.” CEN 3213 – Embedded Systems Programming, FGCU. 28 April 2008.
[4] “Propellent Library.” Propellent (Library and Executable). 2008. Parallax, Inc. 8 Oct 2008.
<http://www.parallax.com/tabid/442/Default.aspx>.
Page 16 of 16