Monday, May 17, 2010

GAME PROGRESS

I picked a demo game project called "Collision with a Heightmap" from Microsoft's XNA website.  Here's the link:  http://creators.xna.com/en-US/sample/collision3dheightmap

I plan to modify the game to have multiple balls (network players) on the screen, where each ball is controlled by a different player.  When 2 balls collide, they explode!  It seems like a good starting place for our game.  After we get the multiplayer networking stuff working, we can just replace the ball with a player's character and then animate it's running motion as it moves around. 

I finished adding my non-blocking UDP Client code to a demo.  I need to update the UDP Server to match, and then begin testing.  The idea behind adding the UDP Client code to the game is for the game to periodically send my player's position to the game server.  The server will collect everybody's position and send it back to each networked game.  As each game get's other player's position information it can move the position of the other players ball in it's own screen.

Here's a picture of the game screen:


Russ DeWitt

A GUI NON-BLOCKING CHAT PROGRAM

Here's a GUI version of the non-blocking UDP Client program.  Click this link to download the Visual C# project.

UdpClientGui_NonBlocking.ZIP

Enjoy!
Russ DeWitt




 

A FANCIER CHAT PROGRAM

Here is a fancier version of the UDP client programs that uses "non-blocking" programming. 

The earlier version that I posted is very simple.  Here's how the simple verison works:

STEP1:  WAIT for the user to input a message.  When the user finally hits the Enter key, then transmit the message to the server and go to step 2.
STEP2:  WAIT for the server to send back a message.  When a message is received from the server, print it and then go to step1.

The problem with that approach is that while the program is waiting in STEP1 it will never check for a message from the server.  If the user never hits the Enter key, the program will never go to step2 and will never check for a message from the server.   And while the program is waiting in STEP2 it will never let the user enter a new message.  If the server never sends a message the program will be stuck in step 2 and will never go to step1.

A better approach would be to not WAIT at each step.  In STEP1, just check to see if the user hit a key.  If he didn't, then go to step 2.  In step 2, check to see if a message was received from the server.  If no message was received, go to step1.  That's called a "non-blocking" approach because the program doesn't get stuck in any particular place.

Click this link to download the Visual C# project for the 'non-blocking' version of the UDP Client program.

 UdpClientConsole_NonBlocking.ZIP

A SIMPLE CHAT PROGRAM

Here are my simple console based UDP client and server programs.  Click these links to download the Visual C# projects.

UdpClientConsole.zip
UdpServerConsole.zip

This is just a simple example of how to make one program talk to another program.  In this example, the UDP Server program on one computer "listens" for messages from the UDP Client program on another computer.  When you type a message in the UDP Client program and hit return, the message is sent to the UDP Server program.  The job of the UDP Server program is to just send any text message that it gets back to the Client program that sent it, but in upper case letters.  Try it out.

Russ DeWitt