Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Week 9/2014: MP UI, SDK

edited 2014 Mar 6 in Developers
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.


  • Last week I returned to working on savegame refactoring, completing the first phase as outlined by Feature #1732 - Libcommon savegame system.

    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.
  • Here is my though on the save game thing. if you plan to implement in the new ui "witch i think is a fantastic idea." then why not have it show the wads/resourcepacks used when saving the game. i would have it if there is too many to fit onto screen have it that it's a scrollable popout that way it can sole the who my save game dose not work when they forgot to add a resourcepack on that they had on previously.

    This is just my thought on it.
  • The current plan is to fold the savegame UI into skyjake's revised Game Selection menus, so it should all integrate quite nicely :) Although we're not quite at that stage just yet, however. I expect it will work somewhat similarly to the multiplayer games tab, where a button can be clicked to detail extended information about the savegame in a popup.
  • that would be great if that happens when things start coming together. everything is progressing smoothly.
  • hmmm sdk

    Does it mean that a new map editor is coming?
  • XCOPY wrote:
    hmmm sdk — Does it mean that a new map editor is coming?
    What we mean by SDK here is 100% aimed toward software development: game/other plugins, tools, or other apps based on the Doomsday libraries.

    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.
  • that will be awesome when the in-game map editor is finished. we can truly get awesome map co-primitively made in-game. but thats far off.
Sign In or Register to comment.