Tag: plan

Version 2.1 is now feature complete. While I originally hoped to focus on multiplayer-related enhancements in this release, it turned out a little differently. Roughly speaking the first half of 2018 was spent working on the foundations of the next revision of the renderer (not included in 2.1), and only during the second half I focused on 2.1 related work.

One important multiplayer improvement has been added for 2.1, though: clients can download mods (e.g., PWADs) from the server in case they are needed for joining a multiplayer game.

The stable 2.1.0 will be released before the end of the year. I intend to spend the remaining time on fixing bugs (some already listed in the roadmap).

I’ve spent the past couple of weeks experimenting with an iOS port of Doomsday. This is now at a proof-of-concept level and not playable yet. It isn’t quite the right time to continue much further along this path, but read on for my findings!

The stable version 2.0 has been out for a bit over two weeks now. I hope you’ve been enjoying it! I have been busy working on bug fixes for 2.0.1, which is soon getting into shape for release.

Now that the goals for the 2.0 release have been met, it is time to look ahead to version 2.1. The first point release is planned to primarily feature improvements for multiplayer games. I won’t be exclusively working on that, though, so various minor improvements will also be included. Small things like a persistent console command history and options to start a game profile in a chosen map are already available in the unstable 2.1 builds.

When it comes to the release schedule, it remains futile to speculate about how much time I will have for Doomsday in the future, but my hope is that point releases in the 2.x series will have a roughly six month cadence. While there is no specific release date set for 2.1, I am uncomfortable with the idea of more than 12 months between stable releases. If that much time passes I am willing to postpone the remaining work to a later point release and do a smaller stable release instead. I prefer that there is a steady and predictable flow of stable releases, much like the situation is with the unstable builds.

In any case, if you run unstable builds you will of course get all the latest improvements as soon as they are implemented.

Multiplayer

2.1’s primary objective in terms of user-facing features is multiplayer improvements. This means both bugfixes and new features. I envision the following MP-related improvements in concrete terms (list still subject to change, in no particular order):

Bug fixes. Multiplayer gameplay is suffering from a variety of small glitches, particularly in Hexen. The goal here is to get rid of the more significant ones.

Movement smoothing for enemies. Single-player games use movement smoothing for everything, so MP games should be no different.

New chat UI. Modern games have some established conventions regarding in-game chat, so Doomsday should take inspiration from them. The chat should use Doomsday’s native UI widgets so the font isn’t blurry or too large, text can have colors and rich formatting, there is nice scrolling, text entry is more versatile, and there is autocompletion for usernames and commands. One particular direction this feature could take is integration with the console command prompt, so one can still issue console commands using IRC-like slash prefixes while primarily still chatting.

New scoreboard UI. A better scoreboard would be a nice thing to have for competitive game types. There should also be an option for a small, always-on scoreboard HUD. I will likely end up with a toggle between completely hidden, small HUD, and full-size scoreboard modes.

More GUI options for configuring game via Shell GUI. Most of the gameplay cvars should be configurable via the GUI. The 2.0 Shell already offers a couple of options (such as game type and current map), but there are more options that would be useful to have conveniently available. My strategy with regard to the Shell remains unchanged, though: for hosting games, the Shell should be the tool you use. Duplicating its features in the client GUI would be more or less redundant and wasted effort. However, I can look into integrating the Shell better with the client GUI, so it is quick and easy to get a local server started, for instance, by launching the Shell via the client.

GUI for configuring map cycle. Map cycling is one important MP feature, especially for longer-running servers. By default, a co-op server will not restart the episode once it ends; map cycling should for instance allow configuring entire episodes to be played through and then restarted.

Remote packages. The key feature here is loading PWADs from the server.

OpenGL

The internal objective for 2.1 is to complete or at least take a major step toward migrating the rest of the OpenGL code to version 3.3, making it also OpenGL ES 2 compatible. GLES is a requirement for Android and iOS, and also Raspberry Pi (a good low-powered testing/development platform). As a nice side-effect, this transition will also future-proof much of the code for subsequent migrations (particularly thinking about APIs like Vulkan, or some other low-level graphics API of the future). The crucial advantage that this transition will provide is support for GLSL shaders when rendering world surfaces. This truly opens up the potential for renderer improvements.

However, in the scope of 2.1, it must be noted that this will be an internal change, meaning the renderer features available to you remain roughly the same as in 2.0. Some older GPUs may no longer be supported, although it is also possible that some OpenGL drivers work better with OpenGL 3 instead of the old compatibility profile. It may also be necessary to drop some older graphics settings that are no longer relevant, if it isn’t feasible to reimplement them with new GL code.

Finally, please remember that plans may change so none of this is particularly set in stone. Stay tuned for updates. 🙂

I took a good look at the project roadmap in the Tracker and decided it was time to do some spring cleaning.

I’ve now updated the plan for the 2.x releases so that each version has a specific focus. For instance, the 2.0 release will focus on the Home UI and basic package management, and the 2.1 release will focus on multiplayer improvements.

While the roadmap is just a plan and plans may always change, defining a clear focus area for each version will help in pushing things forward. Not doing this would mean that each release has the risk of ballooning feature creep and features would likely not be fully baked.

Another topical issue to note is that due to the autobuilder upgrade, the stable 1.15 builds have been suspended until the stable build environment is updated to work with the new builder setup. However, I’m placing my focus on finishing features for the 2.0 stable release, so I don’t expect many fixes for 1.15 in the near future.

This week I was largely focusing on non-Doomsday related things. Therefore, this is a good opportunity to take a bird’s-eye view on how we are doing on the road to the big version 2.0. Continue reading Bird’s-eye view