Planning Ahead
<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the categories: Beta 6, Beta 7, Engine, Games, Practices, Releases.</i>
I've been spending some time debugging our current multiplayer code and it doesn't look very good. One of the biggest issues is that we should get rid of the engine's clientside player logic, which is basically a stripped-down version of the game's player logic. This includes functionality such as handling player controls and calculating movement. In order to fix things once and for all we must drop the engine's version of this logic. Unnecessary redundancy is always an invitation for problems.
However, doing this right requires implementing the full Unified Networking we've been discussing in the past. As such it can't really be part of Beta 6. I propose the following plan:
<ul>
<li>We release Beta 6 as it is now, with broken multiplayer. Even though I don't really like this, there are plenty of other things to beta test. We just have to communicate clearly that multiplayer is not supposed to work in this release.</li>
<li>We start work on Beta 7, but (unlike in the past) focus the work very narrowly ONLY on the Unified Networking feature. In other words, the only thing that Beta 7 does is remove the single-player codepaths and treat single-player games as multiplayer games (with just one local player and a new mode that specifies it's not co-op or deathmatch but a plain old singleplayer game). As a fortunate side effect, this will also fix actual networked multiplayer games, as both run on the same code. We can also introduce debugging aids such as simulated network latency in purely local communications between the local server and the local players, so we can catch issues that are caused by latency.</li>
</ul>
I think that given our track record with making releases, we require more discipline into what is being worked on. Forcing a narrow focus for this crucial refactoring of the netcode would benefit us in future development, as we would have a more solid base on which to work.?Committing to a single, well-defined goal like Unified Networking also makes it quite easy to determine when the next release should be made. And it shouldn't take years for us to get there.
I think this discipline needs to be reflected in the code base as well. We could start using the following rules:
<ul>
<li>The SVN trunk is only for official work on the committed goals of the next release (i.e., Unified Networking). Trivial bug fixes (like typos, etc.) can of course be committed, too, but no features related to other things than the committed goals.</li>
<li>Other work needs to be isolated in branches, where it can then be merged to the trunk when the time is right. For example, say there's a cool feature XYZ I want to develop and I go ahead and implement it in a separate branch. However, since the goals for Beta 7 aren't done yet, the cool feature must stay in its branch until Beta 7 is complete. Then we can decide whether the merge can happen before or after the release of Beta 7 (depending on the level of risk involved in the merge).</li>
</ul>
Comments?
I've been spending some time debugging our current multiplayer code and it doesn't look very good. One of the biggest issues is that we should get rid of the engine's clientside player logic, which is basically a stripped-down version of the game's player logic. This includes functionality such as handling player controls and calculating movement. In order to fix things once and for all we must drop the engine's version of this logic. Unnecessary redundancy is always an invitation for problems.
However, doing this right requires implementing the full Unified Networking we've been discussing in the past. As such it can't really be part of Beta 6. I propose the following plan:
<ul>
<li>We release Beta 6 as it is now, with broken multiplayer. Even though I don't really like this, there are plenty of other things to beta test. We just have to communicate clearly that multiplayer is not supposed to work in this release.</li>
<li>We start work on Beta 7, but (unlike in the past) focus the work very narrowly ONLY on the Unified Networking feature. In other words, the only thing that Beta 7 does is remove the single-player codepaths and treat single-player games as multiplayer games (with just one local player and a new mode that specifies it's not co-op or deathmatch but a plain old singleplayer game). As a fortunate side effect, this will also fix actual networked multiplayer games, as both run on the same code. We can also introduce debugging aids such as simulated network latency in purely local communications between the local server and the local players, so we can catch issues that are caused by latency.</li>
</ul>
I think that given our track record with making releases, we require more discipline into what is being worked on. Forcing a narrow focus for this crucial refactoring of the netcode would benefit us in future development, as we would have a more solid base on which to work.?Committing to a single, well-defined goal like Unified Networking also makes it quite easy to determine when the next release should be made. And it shouldn't take years for us to get there.
I think this discipline needs to be reflected in the code base as well. We could start using the following rules:
<ul>
<li>The SVN trunk is only for official work on the committed goals of the next release (i.e., Unified Networking). Trivial bug fixes (like typos, etc.) can of course be committed, too, but no features related to other things than the committed goals.</li>
<li>Other work needs to be isolated in branches, where it can then be merged to the trunk when the time is right. For example, say there's a cool feature XYZ I want to develop and I go ahead and implement it in a separate branch. However, since the goals for Beta 7 aren't done yet, the cool feature must stay in its branch until Beta 7 is complete. Then we can decide whether the merge can happen before or after the release of Beta 7 (depending on the level of risk involved in the merge).</li>
</ul>
Comments?
Comments
The only reason I ended up working down so many different paths in Beta 6 was simply because nothing else was being done and I figured some progress is better than none at all. However, I do think that the majority of the work I have produced for Beta 6 was within the projected goals for that release.
I currently have about four or five local branches for things like the Doomsday control panel/game menu merger, audio plugin system rewrite and a decal system so it will be good to get this into svn.
I don't think there's much point in defining a fixed deadline for Beta 7. Due to practical issues (such as Real Life) we can't commit to any fixed date for getting things done. I think our only real option is to stay focused on the goals of the release, so that it will get done in the shortest time possible. By choosing reachable goals for the releases we can ensure that the development doesn't drag on endlessly.
With regard to the unified networking I would like to suggest that we consider the prospect of the server sending the map geometry data to clients at this time. My initial thoughts are:
1) Map loading and BSP generation would be server-side only.
2) The server will send a cut down version of the map to clients. This should be designed in a way that allows for dynamic changes to the map geometry in future, though this need not be more than simple plane height changes for Beta7.
3) All triangulation for drawing purposes is done completely client-side.
Also, we should complete the work which revises polyobjs, using mobjs as their origin and making use of the existing code for translation, rotation etc.
<blockquote>With regard to the unified networking I would like to suggest that we consider the prospect of the server sending the map geometry data to clients at this time.</blockquote> That sounds like a good idea, but not really related to unified networking AFAICS. I suggest you write a proposal in the wiki about this ("Server-supplied map geometry" (?)).
How do you define the "cut down version"? What is cut down?
Ditto on what is required for the polyobjs.
Will do.