Difference between revisions of "Development:Network:Todo"

From VsWiki
Jump to: navigation, search
(Add some more weapon todos)
Line 6: Line 6:
 
* Login:
 
* Login:
 
** Encrypted authentication, possibly using a random server token.
 
** Encrypted authentication, possibly using a random server token.
−
*** This means that login data cannot be the first packet sent.
+
*** This means that login data cannot be the first packet sent -- it must first negotiate a key.
 +
** Would SSL be a good idea here.  I think we currently link with a Crypto++ library... but I'm not sure how it is currently used or how to use it.
 
** Make sure authserver-server-client time synchronization works correctly. Maybe every few minutes (or even hours) A,S,C should sync in case a clock gets off somehow.
 
** Make sure authserver-server-client time synchronization works correctly. Maybe every few minutes (or even hours) A,S,C should sync in case a clock gets off somehow.
 
* Exiting:
 
* Exiting:
 
** VSExit(1) is somewhat brutal way of quitting the game.  It often doesn't even nicely inform the server until it closes the connection.
 
** VSExit(1) is somewhat brutal way of quitting the game.  It often doesn't even nicely inform the server until it closes the connection.
 
** Other clients sometimes still see a ghost of the player who left.  I'm not sure if this is fixed yet.
 
** Other clients sometimes still see a ghost of the player who left.  I'm not sure if this is fixed yet.
−
** Games should be saved?
+
** Games should be saved? (see below)
 
*** How much data should actually be saved?  What if you have died?
 
*** How much data should actually be saved?  What if you have died?
 
* Damage:
 
* Damage:
−
** Theoretically implented, but I have yet to see collisions and weapons actually do damage.
+
** Theoretically implented, but I have yet to see collisions and weapons actually do damage client-side.
−
** I don't know yet how dying will work... It would be bad to have to start from scratch every time you crash into something.
+
** Figure out how to gracefully detect dead units (Crashing because the unit is NULL is not the right way to do this).
 +
** Not sure what CMD_SCAN is to be used for... it's used in one place -- that is in NetClient::scanRequest.
 +
** I don't know yet how the game will implement dying...
 +
*** It would be bad to have to start from scratch every time you crash into something.
 +
*** Have the respawn key re-join?
 +
*** How do we implement saving?  Respawn doesn't work without a way to save... or should you keep everything the same as when you died, and then start from a random "spawn point".
 +
**** I believe most FPS games make you lose all upgrades, but this is not an option in Vega Strike, or things will get boring quickly.
 +
**** How do games like Ultima or WoW behave when you die?  Do you lose everything (obviously you can't lose all your experience)?
 
* Weapons:
 
* Weapons:
−
** Energy needs to be sent on CMD_FIREREQUEST (ideally just S->C firerequest), and must charge client-side too.
+
** Energy needs to recharge client-side (interpolate between CMD_SNAPSHOTs) -- this is one (if(Network==NULL))'ed out statement in some updatePhysics-related function in unit_generic.cpp -- Really easy to fix.
−
** Create new message CMD_TARGET when someone targets a new message.  Will be relayed to all clients for autotracking.
+
** Clients with NULL targets constantly send out streams of CMD_TARGET to the server (from withing FireKeyboard::ForceTarget.  We sohuld either disable it client-side (but then people will have to manually re-target when their target dies), or else have the server instead check for any nearby targets, and then broadcast a CMD_TARGET only once it becomes non-NULL.  This way we avoid the flooding.
−
** Also, send out CMD_TARGET when an AI targets.
+
* Jumping, Docking, multiple systems:
−
* Jumping:
 
 
** Server switching???
 
** Server switching???
 
** Having the server load a new system may not be a good idea.  The server should always have all systems it will handle running at once.
 
** Having the server load a new system may not be a good idea.  The server should always have all systems it will handle running at once.

Revision as of 10:01, 4 July 2006

Network TODO

  • Clean up server-client-authserver communication
    • I would really like if the messages sent and received could be done in a more uniform way.
    • Clean up some unused messages.
  • Login:
    • Encrypted authentication, possibly using a random server token.
      • This means that login data cannot be the first packet sent -- it must first negotiate a key.
    • Would SSL be a good idea here. I think we currently link with a Crypto++ library... but I'm not sure how it is currently used or how to use it.
    • Make sure authserver-server-client time synchronization works correctly. Maybe every few minutes (or even hours) A,S,C should sync in case a clock gets off somehow.
  • Exiting:
    • VSExit(1) is somewhat brutal way of quitting the game. It often doesn't even nicely inform the server until it closes the connection.
    • Other clients sometimes still see a ghost of the player who left. I'm not sure if this is fixed yet.
    • Games should be saved? (see below)
      • How much data should actually be saved? What if you have died?
  • Damage:
    • Theoretically implented, but I have yet to see collisions and weapons actually do damage client-side.
    • Figure out how to gracefully detect dead units (Crashing because the unit is NULL is not the right way to do this).
    • Not sure what CMD_SCAN is to be used for... it's used in one place -- that is in NetClient::scanRequest.
    • I don't know yet how the game will implement dying...
      • It would be bad to have to start from scratch every time you crash into something.
      • Have the respawn key re-join?
      • How do we implement saving? Respawn doesn't work without a way to save... or should you keep everything the same as when you died, and then start from a random "spawn point".
        • I believe most FPS games make you lose all upgrades, but this is not an option in Vega Strike, or things will get boring quickly.
        • How do games like Ultima or WoW behave when you die? Do you lose everything (obviously you can't lose all your experience)?
  • Weapons:
    • Energy needs to recharge client-side (interpolate between CMD_SNAPSHOTs) -- this is one (if(Network==NULL))'ed out statement in some updatePhysics-related function in unit_generic.cpp -- Really easy to fix.
    • Clients with NULL targets constantly send out streams of CMD_TARGET to the server (from withing FireKeyboard::ForceTarget. We sohuld either disable it client-side (but then people will have to manually re-target when their target dies), or else have the server instead check for any nearby targets, and then broadcast a CMD_TARGET only once it becomes non-NULL. This way we avoid the flooding.
  • Jumping, Docking, multiple systems:
    • Server switching???
    • Having the server load a new system may not be a good idea. The server should always have all systems it will handle running at once.
    • This also means that the universe must be limited.
Retrieved from "http://wiki.vega-strike.org/mediawiki/index.php?title=Development:Network:Todo&oldid=10802"