Work on Multiplayer
<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the categories: Engine, Practices.</i>
<blockquote>We really want client weapon changes dependent on server ack? Pass weapon #id in the fire request; kick server-side if invalid?? -d</blockquote>
As a general rule of thumb, the client gets pretty much free reign over the player state (movement, firing, etc.). The server will be notified of everything, though (after the fact), so that the state changes can be verified and shared with the other clients. The intent is of course to hide the network latency from the player.
Now, at the moment we are far from this goal. My plan is to first get everything more or less up and running without serious flaws, and then start tidying things up (like simplifying the delta communication/acks). Player actions (and other time-critical things) will be revisited at this point.
When it comes to validity checks, I would vote for less-than-rigorous checking at this stage. As we don't yet have the game/world state fully under control (it's more or less a collection of kludges and hacks over the singleplayer mode) there is a real danger of false positives and consequently us shooting ourselves into our collective feet.
To prepare for the eventual Unified Networking, we need to start putting a lot more time into running the game in networked mode. I do not want the netgame code paths breaking again when refactorings (ringzero and upcoming ones in the future) are merged into the master. We need to gradually start treating the client mode as the primary gameplay mode.
<blockquote>We really want client weapon changes dependent on server ack? Pass weapon #id in the fire request; kick server-side if invalid?? -d</blockquote>
As a general rule of thumb, the client gets pretty much free reign over the player state (movement, firing, etc.). The server will be notified of everything, though (after the fact), so that the state changes can be verified and shared with the other clients. The intent is of course to hide the network latency from the player.
Now, at the moment we are far from this goal. My plan is to first get everything more or less up and running without serious flaws, and then start tidying things up (like simplifying the delta communication/acks). Player actions (and other time-critical things) will be revisited at this point.
When it comes to validity checks, I would vote for less-than-rigorous checking at this stage. As we don't yet have the game/world state fully under control (it's more or less a collection of kludges and hacks over the singleplayer mode) there is a real danger of false positives and consequently us shooting ourselves into our collective feet.
To prepare for the eventual Unified Networking, we need to start putting a lot more time into running the game in networked mode. I do not want the netgame code paths breaking again when refactorings (ringzero and upcoming ones in the future) are merged into the master. We need to gradually start treating the client mode as the primary gameplay mode.
Comments
As I recall the main issue with weapon changes is that server side logic (in player think) is presently dependent on client-side logic, namely, psprite raise/lower. In a nutshell - weapon change is dependent upon the time it takes for the client to raise and then communicate that back to the server. This is further complicated by the need for per-user configuration options; we can't have the server doing weapon changes unless each client communicates their weapon change configuration back to the server - which is something we don't really want in any case.
In addition there is the plethora of client-side cvars for hud/psprite behavior; most of which are completely ignorant to our client/server model and only actually work as intended in single player. I did begin sorting these out in the old "gamerules" branch but that was abandoned after we decided it was dependent on unified networking.
On the whole, I would like to be in a situation where we can administer small-scale refactorings into a well-behaving, fully functional codebase. Before we are in that state in the master, I'm going to emphasize fixing existing code instead of writing new code.