Name      : Network Client v1.00
            Network Server v1.00
Created by: Dan Royer circa 07/1999-08/1999
Contact   :
  Email   : aggravated@bigfoot.com
  ICQ     : 4491034
  Web     : http://members.home.com/droyer
            http://www.flipcode.com
--------------------------------------------------------------------------------
Notes
--------------------------------------------------------------------------------
0. What's in this ZIP (or rather, what's not.)
  The code includes the cComm, cClient, cPlayer, cNetworkClient, cNetworkServer
  classes as mentioned in the articles on www.flipcode.com.  It also includes
  working scalable bezier patch code.  For those of you not in the know, bezier
  patches are what's used to create curved surfaces in Quake III, LithTech 2.0
  and all the other big engines today.  I'm currently using them to draw the
  background grid but I have plans to make some cool surface deformity animations
  when a missile explodes.
  A few classes are only accessible via the lib files.  This is because the source
  is not related to network programming and is part of my 3D engine which I have
  no intention of releasing at this time.


1. Why this code ain't so hot
  I originally intended to have the apps multithreaded for reasons that quickly
  proved to be bad.  Thus the odd names, the strange layout and the occaisional
  seemingly pointless and disassociated comment.  Nothing out of the ordinary for
  a big project, quite out of place for something this small.
  Another good case is cVehicle.  I intended to have different vehicle types and
  a powerup that let you switch between them bu it hasn't happened yet.
  I have unconfirmed reports that if you are not running at least DirectX 6
  then the program will crash.  I'm not too sure why, I have checks for invalid
  versions, etc...

  My goal was to  clean all this up before release, if I didn't then I apologize.


2. Where there's room for improvement
  Every refrence of "Bad C++" May or may not be Bad C++, it's just a phrase I
  can search for when I'm looking to kill bugs and improve things.  So if you
  see it, don't panic, just know that what follows is something that could
  definitely be improved upon.

  I only have one computer so checking to see if this thing runs well on a large
  scale was not possible.  I can say right now that I don't think it will, mainly
  because it's TCP/IP and would require an EXCELLENT lag-free connection.

  I'm sure it wouldn't take much work to make an in-game server (instead of a
  dedicated server).  It would require a bit of rewriting to get UDP working, I
  plan to have that working in the next version.

  You'll notice as the game runs that the "snap" messages come further and further
  apart.  This is apparently a problem with Winsock TCP/IP and not much can be done
  about it.  I hear that if you wait long enough all TCP/IP communication will simply
  lock up and you'll have to reboot.

  Speaking of TCP/IP, the reason everything is "jumpy" is because of the lag involved.
  Switching to UDP will cure that right up.

  The server tells EVERY client about EVERY OTHER CLIENT MOVE.  It should only tell
  the client about ships that are within a certain distance of the screen borders
  (unless you add a radar, then you'll have to tell the clients about everyone up
  to the radar range).  The clients are told about every missile because it only
  has to happen once, at spawn time.

  The snapshot should be a single block of data that contains everything.  Spawns,
  deaths, who's moving or shooting, who logged in or out, etc...  The fewer the
  message blocks, the less worry of lag between blocks and the less problems you'll
  have in UDP mode.  Remember, UDP does NOT guarantee that data will arrive in the
  same order it was sent.  Theoretically you should be able to reduce the blocks to:
    server: 1 block for login approval & game world state
              (since all update just modify the current state)
            1 block per game tick (state update)
    client: 1 block for login request
            1 block for movement update/keep alive

  The more I think about it the more I realize it would have been much smarter to
  set the first int of every message equal to the total size of the message.  That
  way several messages could be sent with a single queue and it would save everyone
  a lot of trouble.

  The rest of the server dialog box could be implemented.  All you need is to set
  up a clock tick that would update the current page based on whatever the server
  data access methods return.

  A new system for logging server messages is desperately needed.  MessageBoxes are
  BAD for the server.


3. What I'm gonna do about it
  I fully intend to keep working on this little space shooter thing, though I
  don't know how long I'll keep new versions as open source.


4. I really enjoyed this project (or) "Ha ha h-that's not funny."
  As with all programs there's that one little bug that stumps you for a couple of
  days and absolutely drives you up the wall.  In my case it was a transformation
  error that screwed up visual effects and took nine days to track down because it
  was one of the least likely possibilities.  There was even a time when I became
  convinced it was a rendering problem, then proved the matrixes were right so I
  was sure it was a networking error.  Grrr.  Other than that, this project was
  slick & easy going the whole way.  I got a little lazy when I started putting
  method bodies in header files, I'll be sure to clean that up later.


5. Find a bug?  Got a question?  Wanna chew me out an' diss my homeys?
  Write me!  Please put FLIPCODE NETWORK GAME in the title.


--------------------------------------------------------------------------------
Legal
--------------------------------------------------------------------------------
Rights:
  Dan Royer wrote all the material contained in this ZIP and reserves all rights,
  titles, etc. associated with said ZIP.


Liability :
  Dan Royer is not liable for any damage resulting from use of Network Client or
  Network Server.  Dan Royer might be liable for permanant brain damage resulting
  from trying to understand some of the nonsense he's written but any court in the
  land would accept the argument that you were probably insane to begin with.


Distribution:
  All files in this ZIP may be redistributed in any media provided it is done free
  of charge and without alterating the ZIP.  Yeah right, like anybody would pay for this.

