Week 8/2013: Autodiscovering servers on LAN
Last week I started work with the client's next-gen UI framework and revised Doomsday's low-level network code, the part of the engine that handles network connections, looks for servers, and passes data between machines on the network.
Heading to 1.10
After switching to use the OS X Installer on the Mac, I still needed to iron out some kinks in our OS X distribution scripts. The installer package is now signed, too, which is required for Mountain Lion. I still haven't tried if the autoupdater works in the latest unstable builds, though.
The Doomsday 2 work is proceeding ever higher in the engine architecture, this time in the form of a refactoring related to engine subsystems. In my "ui-framework" branch, I've now begun dividing client and server code into object-oriented subsystems (de::System). The goal is to clarify the structure of the executables, enforce decoupling between subsystems, and enhance runtime flexibility.
My UI work is now a bit late in the game for 1.10, but some initial refactoring should make it. I'm revising the way the window and the OpenGL drawing surface relate to the engine and game UI: I'm inserting the new libdeng2 Widget framework in between, so that initially there will be a widget called LegacyWidget that holds the entire UI. For 1.11, parts of the UI will then be replaced/revised with completely new widgets, obsoleting the corresponding parts in LegacyWidget.
Low-level Networking
The transition to even better network/MP code will progress in layers: there is a lot of MP/net code in the engine and games, and revising all of it at once is not feasible. I've started by replacing the lowest layers with libdeng2/libshell-based network communications.
One of the great new features of the libdeng2-based network code is that the client is now able to immediately and automatically detect servers running on the local network. They appear on the MP Join screen in the "Custom Search" list. I did not spend any time improving the MP UI design itself, as the time for that comes later in the "ui-framework" branch.
Another benefit of the libdeng2 network code is that it allows fine-grained monitoring of actual network bandwidth, making it finally possible for servers to moderate the amount of data they send based on the client's connection. (Although this will not make it into 1.10...)
The "weight" of the old code can be felt as it has been written in an ad-hoc, non-object-oriented fashion. Some non-optimal wrapper-type code needs to temporarily exist between the new network code and the old code — I find this annoying, but unavoidable. As more and more MP/net code is revised the old cruft will become obsolete and be removed.
Speaking of old cruft, I have removed LegacyNetwork from libdeng2, which basically was a thin C-friendly layer over the libdeng2 Socket classes. It allowed us to switch away from SDL_net as the underlying network messaging API. Now that the low-level network code is directly using libdeng2, it is no longer needed.
My plan is to start the candidate phase for 1.10 during next week. Until then I'll focus on the next-gen UI framework.
Heading to 1.10
After switching to use the OS X Installer on the Mac, I still needed to iron out some kinks in our OS X distribution scripts. The installer package is now signed, too, which is required for Mountain Lion. I still haven't tried if the autoupdater works in the latest unstable builds, though.
The Doomsday 2 work is proceeding ever higher in the engine architecture, this time in the form of a refactoring related to engine subsystems. In my "ui-framework" branch, I've now begun dividing client and server code into object-oriented subsystems (de::System). The goal is to clarify the structure of the executables, enforce decoupling between subsystems, and enhance runtime flexibility.
My UI work is now a bit late in the game for 1.10, but some initial refactoring should make it. I'm revising the way the window and the OpenGL drawing surface relate to the engine and game UI: I'm inserting the new libdeng2 Widget framework in between, so that initially there will be a widget called LegacyWidget that holds the entire UI. For 1.11, parts of the UI will then be replaced/revised with completely new widgets, obsoleting the corresponding parts in LegacyWidget.
Low-level Networking
The transition to even better network/MP code will progress in layers: there is a lot of MP/net code in the engine and games, and revising all of it at once is not feasible. I've started by replacing the lowest layers with libdeng2/libshell-based network communications.
One of the great new features of the libdeng2-based network code is that the client is now able to immediately and automatically detect servers running on the local network. They appear on the MP Join screen in the "Custom Search" list. I did not spend any time improving the MP UI design itself, as the time for that comes later in the "ui-framework" branch.
Another benefit of the libdeng2 network code is that it allows fine-grained monitoring of actual network bandwidth, making it finally possible for servers to moderate the amount of data they send based on the client's connection. (Although this will not make it into 1.10...)
The "weight" of the old code can be felt as it has been written in an ad-hoc, non-object-oriented fashion. Some non-optimal wrapper-type code needs to temporarily exist between the new network code and the old code — I find this annoying, but unavoidable. As more and more MP/net code is revised the old cruft will become obsolete and be removed.
Speaking of old cruft, I have removed LegacyNetwork from libdeng2, which basically was a thin C-friendly layer over the libdeng2 Socket classes. It allowed us to switch away from SDL_net as the underlying network messaging API. Now that the low-level network code is directly using libdeng2, it is no longer needed.
My plan is to start the candidate phase for 1.10 during next week. Until then I'll focus on the next-gen UI framework.