Development:Network:Todo
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.
- Encrypted authentication, possibly using a random server token.
- 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.