On Week 12
<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the category: Blog.</i>
<strong>skyjake:</strong>
<ul>
<li>I managed to solve a couple of issues with multiplayer during the week: the missing status bar, player death/respawn, and incorrect player mobj flags. Much remains still broken, for example collisions with other objects, the red screen filter when taking damage (should be a client-side effect only), and movement smoothing. There's also a strange issue with the player changing weapons on its own when joining a game.
<li>I've also been fixing compiler warnings so that we would have more green boxes in the build reports. The situation should be pretty good in the next build, as far as Windows and Mac OS X are concerned.
<li>Next week I'm trying to solve more of the multiplayer problems, most likely starting with the collision thing as it seems the most severe at the moment. I've yet to test how level changes, intermissions and deathmatch are working.
</ul>
<strong>danij:</strong>
<ul>
<li>This week I've continued work in ringzero, on the texture and material abstractions in Doomsday. I've introduced a handful of new concepts and fixed many of the outstanding issues, particularly the prepare/cache specification divergences. The revised interface is intended to minimize the amount of texture and/or material variants needed for any given scene. Additionally the new structure relocates material animation interpolation from the general case into the variant. This will allow us to fix the longstanding problem of material animation which is unequivocally driven by the core game timer (consequently stopping when "paused", restarting on map change, etc, etc...).</li>
<li>Next week my plan is to complete the current batch of work to the material subsystem and get back to the introduction of texture atlases.</li>
</ul>
<strong>skyjake:</strong>
<ul>
<li>I managed to solve a couple of issues with multiplayer during the week: the missing status bar, player death/respawn, and incorrect player mobj flags. Much remains still broken, for example collisions with other objects, the red screen filter when taking damage (should be a client-side effect only), and movement smoothing. There's also a strange issue with the player changing weapons on its own when joining a game.
<li>I've also been fixing compiler warnings so that we would have more green boxes in the build reports. The situation should be pretty good in the next build, as far as Windows and Mac OS X are concerned.
<li>Next week I'm trying to solve more of the multiplayer problems, most likely starting with the collision thing as it seems the most severe at the moment. I've yet to test how level changes, intermissions and deathmatch are working.
</ul>
<strong>danij:</strong>
<ul>
<li>This week I've continued work in ringzero, on the texture and material abstractions in Doomsday. I've introduced a handful of new concepts and fixed many of the outstanding issues, particularly the prepare/cache specification divergences. The revised interface is intended to minimize the amount of texture and/or material variants needed for any given scene. Additionally the new structure relocates material animation interpolation from the general case into the variant. This will allow us to fix the longstanding problem of material animation which is unequivocally driven by the core game timer (consequently stopping when "paused", restarting on map change, etc, etc...).</li>
<li>Next week my plan is to complete the current batch of work to the material subsystem and get back to the introduction of texture atlases.</li>
</ul>
Comments
How much of this will be visible to the user? I'm thinking about the documentation aspect. I think a suitable process for documenting engine features would be the following:
1. A proposal page is created that outlines the idea and its motivations and implications.
2. As the feature is developed, the proposal page is updated with more detailed information.
3. When the feature is complete, the proposal page is converted into a "manual page", by shifting the user-facing information to the beginning, and the technical things to another page, or to the end of the page.
I agree that we need to improve documentation of our internal systems. In my opinion project technical documentation (e.g., engine class library, naming conventions etc) should be completely separate from user-facing information. If we try to combine them, we won't please anyone; users want concise, abstracted information devoid of overly technical language.
I'm happy with the above process though I expect that in practice the user-facing information will have to be written afresh in any case.
I'm just looking for ways to avoid a "big bang" approach where a huge one-time effort is needed for producing the documentation (i.e., writing the user documentation after everything is complete). If the documentation evolves/grows gradually, the effort should be more manageable.