Week 9/2014: MP UI, SDK
Last week I was finishing up the manual network connection dialog and started work on creating an SDK for Doomsday.
The new "Connect to Server" dialog is now pretty much finished. It allows one to enter a network address, queries the server for game information, and displays a list of found games. It also permits one to change the current game when joining, although no provisions are yet taken to ensure compatible resources are in use on both the server and the client.
It should be noted that the "Connect to Server" dialog is not needed for LAN games or public servers visible via the Master Server; those are shown automatically in the Game Selection menus.
The next, and final, step of this task is to update the game menus to use the new UI and remove all the legacy UI code.
The other big thing I've been working on recently is the (gradual) introduction of a Doomsday SDK. This will be a collection of headers and C++ libraries that allows one to write plugins or even entire new applications on top of the Doomsday core set of libraries (libdeng2, libshell, libgui, libappfw). These libraries are now available under the LGPL license.
This is the next step in modularizing the engine and converting it more into a shared library. Eventually all the Doomsday apps (client, server, tools) will be built against the SDK, and the SDK will be available as a separate download.
The new "Connect to Server" dialog is now pretty much finished. It allows one to enter a network address, queries the server for game information, and displays a list of found games. It also permits one to change the current game when joining, although no provisions are yet taken to ensure compatible resources are in use on both the server and the client.
It should be noted that the "Connect to Server" dialog is not needed for LAN games or public servers visible via the Master Server; those are shown automatically in the Game Selection menus.
The next, and final, step of this task is to update the game menus to use the new UI and remove all the legacy UI code.
The other big thing I've been working on recently is the (gradual) introduction of a Doomsday SDK. This will be a collection of headers and C++ libraries that allows one to write plugins or even entire new applications on top of the Doomsday core set of libraries (libdeng2, libshell, libgui, libappfw). These libraries are now available under the LGPL license.
This is the next step in modularizing the engine and converting it more into a shared library. Eventually all the Doomsday apps (client, server, tools) will be built against the SDK, and the SDK will be available as a separate download.
Comments
As you'll know from Week 6, I've recently been working on remodelling the savegame system, with a more object-oriented design, in preparation for larger changes to come. Last week I was finally able to complete the first phase of this work, which I actually began way back in 2007. Thus far this work has been happening mostly behind the scenes, with little in the way of user facing changes. However with this (semi-) milestone now reached, we can now move forward with splitting up the savegame system and beginning to move some of the components into the engine.
Towards the end of the week I began to re-access the high level design of the savegame system, factoring in some of the ideas presented in the engine-controlled saving of the game proposal and determining a plan of action. It turns out that it is not actually necessary for the engine to have control of the (de)serialization process prior to making savegames visible to the engine. This means that we can now make the significant step of relocating management of the savegame user data files.
One of the main benefits to moving saved session management into the engine, ahead of engine controlled game state (de)serialization, is the potential for including this in the taskbar UI.
The first hurdle was to cleanly separate the games' slot-based mechanism into a layer on top of the underlying savegame file management. This resulted in a new component called the "SavedSessionRepository" which has no ties to the game specific logics or slot-based mechanism restrictions. However there was still the issue of the saved session metadata to contend with before this component could be moved engine side.
The easiest option would have been to move the saved session repository into the engine and use a public API/callback -based mechanism for (de)serializing the session metadata. There are numerous problems with such an approach which would have significantly limited the usefulness in moving the repository. Not least because the metadata varies from game to game and in Ring Zero at least, none of the game state interpreters will be available (these are presently implemented on game side, in the common code "library"). Clearly we needed a new approach to handling savegame metadata (which also contains the "game rules"). After looking at a few different solutions I'm currently experimenting with a design based on libdeng2's Record component, as this appears to neatly solve most of the issues, including public visibility and future extensibility.
My plan for next week is to continue working on the savegame system.
This is just my thought on it.
Sorry, had to
Does it mean that a new map editor is coming?
For the record, our long-term plan is to have an in-game map editor, expanding the already existing editing capabilities in the engine (e.g., the "bledit" mode). This is one reason we've been putting a lot of effort into building a better UI framework: it'll allow putting together a good UI for map editing.