Unified Networking
<i>This post was originally made by <b>danij</b> on the dengDevs blog. It was posted under the categories: Beta 7, Games.</i>
With 1.9.0-beta6.1 now released I think we are ready to get started on the next big job, namely, Unified Networking. Lets formulate a plan of attack.
I have already begun cleaning up our game state management, wrapping all state variables into a series of structures, separating top-level game state (game mode, skill level, etc...), game logic rules and player-profile stuff. I'm now in the process of auditing the game state cvars, renaming with a "server-" prefix those which should be server-side and where necessary reimplementing accordingly.
The next step presumably is to change the game-side global variable <tt>deathmatch</tt> as this denotes the "type" of the current game, if true it is a deathmatch game otherwise it is a co-operative game. However, we need to decide from the outset how we are going to treat singleplayer games.
In my opinion, there should be no distinction between a "singleplayer" game and a cooperative game, with the current game logic differences between them generalized with a "game rules" system. Ultimately, the plan should be to generalize to a point where there is no game "type" only differing rule sets.
Other ports handle some of this stuff by way of a mechanism called "DMFLAGS" which generalizes game logic paths into a set of flags which are set together, server-side. Whilst I think this is a good start it only goes some way to generalizing game types.
I would like to propose a new "game rule" system which encapsulates all game logic rules, including things like our current server-side cvars for whether items respawn, the mapcycle and the various "modifiers" for health, damage etc. Both client and server would have three rule sets: a default game rule set which is configured directly via cvars, a session-only rule set which does not affect the default rule set with values provided via the legacy command-line options such as <tt>-altdeath</tt> and <tt>turbo</tt> and the currently active rule set.
Client-side, the current rule set would be supplied by the server, ideally in advance of the client connecting so they use the information to determine whether they want to join that server.
Server-side, the current rule set is derived from the default rule set patched with the session-only rule set.
When changing the values of the default rule set no change should occur to the current game either on the client or the server. Server-side, the session-only ruleset can be changed at any time and a ccmd is available which allows the current rule set to be updated (again, taking the defaults and patching them with the session-only overrides), which are then re-sent to the clients.
I have also been thinking about a system which allows for multiple rulesets to be created and managed at runtime and written to config files. Selection of the default rule set would come from this palette of available rule sets.
With 1.9.0-beta6.1 now released I think we are ready to get started on the next big job, namely, Unified Networking. Lets formulate a plan of attack.
I have already begun cleaning up our game state management, wrapping all state variables into a series of structures, separating top-level game state (game mode, skill level, etc...), game logic rules and player-profile stuff. I'm now in the process of auditing the game state cvars, renaming with a "server-" prefix those which should be server-side and where necessary reimplementing accordingly.
The next step presumably is to change the game-side global variable <tt>deathmatch</tt> as this denotes the "type" of the current game, if true it is a deathmatch game otherwise it is a co-operative game. However, we need to decide from the outset how we are going to treat singleplayer games.
In my opinion, there should be no distinction between a "singleplayer" game and a cooperative game, with the current game logic differences between them generalized with a "game rules" system. Ultimately, the plan should be to generalize to a point where there is no game "type" only differing rule sets.
Other ports handle some of this stuff by way of a mechanism called "DMFLAGS" which generalizes game logic paths into a set of flags which are set together, server-side. Whilst I think this is a good start it only goes some way to generalizing game types.
I would like to propose a new "game rule" system which encapsulates all game logic rules, including things like our current server-side cvars for whether items respawn, the mapcycle and the various "modifiers" for health, damage etc. Both client and server would have three rule sets: a default game rule set which is configured directly via cvars, a session-only rule set which does not affect the default rule set with values provided via the legacy command-line options such as <tt>-altdeath</tt> and <tt>turbo</tt> and the currently active rule set.
Client-side, the current rule set would be supplied by the server, ideally in advance of the client connecting so they use the information to determine whether they want to join that server.
Server-side, the current rule set is derived from the default rule set patched with the session-only rule set.
When changing the values of the default rule set no change should occur to the current game either on the client or the server. Server-side, the session-only ruleset can be changed at any time and a ccmd is available which allows the current rule set to be updated (again, taking the defaults and patching them with the session-only overrides), which are then re-sent to the clients.
I have also been thinking about a system which allows for multiple rulesets to be created and managed at runtime and written to config files. Selection of the default rule set would come from this palette of available rule sets.
Comments
I think it sounds like to a good idea to create some kind of a rules system to manage all the relevant variables. I'm thinking a pretty much isolated module would be suitable? If we were using C++, the ruleset would likely be a class. We should do an object-oriented design anyway.
Maybe a plugin? So that the rules can be customized?
After I come back, I plan to start by introducing the background dedicated server process. I'm thinking that if you then use the "-dedicated" option the only effect should be that the graphical UI process isn't started, but instead a text console UI process.
DaniJ, remember to document your plans/design for the rules thing as a DEW Proposal, so that everyone will be up to speed on how it's supposed to work.
<blockquote><p>After I come back, I plan to start by introducing the background dedicated server process. I?m thinking that if you then use the ?-dedicated? option the only effect should be that the graphical UI process isn?t started, but instead a text console UI process.</p></blockquote>Sounds good.
<blockquote><p>DaniJ, remember to document your plans/design for the rules thing as a DEW Proposal, so that everyone will be up to speed on how it?s supposed to work.</p></blockquote>Will do.
EDIT: I've elaborated on the <a href="http://www.dengine.net/dew/index.php?title=Game_rules_module#Game_rules_module" rel="nofollow">"game rules module" proposal at the wiki</a>