Wrapping Up 2014
2014 saw a change in our development practices: a move from rigid scheduling to a more flexible approach. Progress slowed down during the year.
The Numbers
This year was clearly different from the three previous ones in that the second half was quieter than the first.
What caused the slowdown? The primary factor was that in the second half of the year, there was less time to spend on the project. I took a ~6 week hiatus to relax, rekindle motivation, and learn some C++11 techniques. It remains to be seen what effect the less rigid release schedule will have on long-term progress; I suspect this is a trade-off between quality and speed, so that overall we will be moving slower as we address bugs along the way.
(More statistics and graphs about the source code are available at Open HUB.)
The Milestones
These were the major developments of the year:
The Outlook
One of the pain points with the 3-month release cycle was that overall quality started trending downwards as bug fixes were not properly scheduled into the process. Dealing with bugs can be slow and sometimes exhausting, but the fixes have to be done at some point. A more flexible schedule also matches the nature of the project as a leisure time hobby; we have very frequent unstable builds of reasonable quality, so it is less of a problem that stable releases are further apart. As long as we don’t slip to multi-year gaps between stable releases, we should be fine.
The Tracker has proven to be a vital tool for managing the project. However, we should remember the Roadmap is flexible and nothing is set in stone when things are scheduled. It is very important to keep updating the plans as work progresses, as circumstances often change over time and the roadmap must reflect that.
The revised UI is in a good shape. The framework now has enough functionality to allow us to start implementing more advanced UI features, such as game session configuration and various in-game editors. I’m hoping that during 2015 it will be possible to use Doomsday as a standalone app, without Snowberry. (Likely without full add-on/package management UI, though.)
Graphics and rendering will continue to move more into the focus. A pattern seems to be developing, where new GL2 cannot be properly integrated to the rendering because the main renderer still runs the old OpenGL 1.x code (no shaders, no vertex buffers, etc.).
Multiplayer improvements are overdue. This would be a perfect job for a third developer, though; as it is, both I and DaniJ continue to be fully booked on other, more important tasks (on our personal priority rankings).
Critical bug fixes need to be made before 1.15 can be released, so all available time will be spent on those. Releasing 1.15 is clearly the first priority for 2015.
Happy New Year!
The Numbers
This year was clearly different from the three previous ones in that the second half was quieter than the first.
- Overall, there were 34% fewer Git commits compared to 2013.
- Size of the code base size grew to 720 KLOC (about +5%). However, the rate of growth slowed down in sync with the decreasing number of commits.
- C++ continued its growth with an increase to 61% (from 47%); C is at 27% (from 41%).
What caused the slowdown? The primary factor was that in the second half of the year, there was less time to spend on the project. I took a ~6 week hiatus to relax, rekindle motivation, and learn some C++11 techniques. It remains to be seen what effect the less rigid release schedule will have on long-term progress; I suspect this is a trade-off between quality and speed, so that overall we will be moving slower as we address bugs along the way.
(More statistics and graphs about the source code are available at Open HUB.)
The Milestones
These were the major developments of the year:
- In January, added support for NVIDIA CSAA. libappfw added as a separate library. Alerts and granular log entry filtering. Internal Doomsday Script improvements. OS X native font rendering. Dynamic home screen layout.
- In February, a new multiplayer UI was created for listing available games and joining them. Oculus Rift support code refactored and moved the UI framework library. UI widget state persistency mechanism.
- In March, a first-launch tutorial was added. Most of old UI code removed as obsolete. Game saving was refactored into an engine-controlled system, and a ZIP-based save file format was taken into use. Saves also appear in the game selection menus. A simple bloom filter was added to the renderer as a post-processing effect.
- In April, 1.14 was being finalized and some important bugs in Doomsday’s file system were fixed. We agreed to relax the 3-month release cycle to leave more time for fixing bugs.
- In May, bugs in 1.14 were being patched. libdoomsday was added for Doomsday code shared by the client and server apps (DED, console vars/cmds, FS1 file handling). DED storage was partially refactored using Doomsday 2 components, allowing the use of Doomsday Script in the future. Upgraded to SDL 2.0 (for joystick support). Weekly devblog posts were discontinued.
- In June, fixes for Unicode file paths.
- In July, introduced the new Doomsday 2 package format. Upgraded to Qt 5. HiDPI support was enabled in the OS X build.
- In August, internal data for thinkers and many small improvements. Oculus Rift support was upgraded for DK2. A “beta” of the new model renderer was introduced.
- In October, the BSP builder was cleaned up and its performance was improved.
- In November, DaniJ added customizable episode definitions and support for MAPINFO lumps.
- In December, UI improvements and deleting save files from the game selection menu.
The Outlook
One of the pain points with the 3-month release cycle was that overall quality started trending downwards as bug fixes were not properly scheduled into the process. Dealing with bugs can be slow and sometimes exhausting, but the fixes have to be done at some point. A more flexible schedule also matches the nature of the project as a leisure time hobby; we have very frequent unstable builds of reasonable quality, so it is less of a problem that stable releases are further apart. As long as we don’t slip to multi-year gaps between stable releases, we should be fine.
The Tracker has proven to be a vital tool for managing the project. However, we should remember the Roadmap is flexible and nothing is set in stone when things are scheduled. It is very important to keep updating the plans as work progresses, as circumstances often change over time and the roadmap must reflect that.
The revised UI is in a good shape. The framework now has enough functionality to allow us to start implementing more advanced UI features, such as game session configuration and various in-game editors. I’m hoping that during 2015 it will be possible to use Doomsday as a standalone app, without Snowberry. (Likely without full add-on/package management UI, though.)
Graphics and rendering will continue to move more into the focus. A pattern seems to be developing, where new GL2 cannot be properly integrated to the rendering because the main renderer still runs the old OpenGL 1.x code (no shaders, no vertex buffers, etc.).
Multiplayer improvements are overdue. This would be a perfect job for a third developer, though; as it is, both I and DaniJ continue to be fully booked on other, more important tasks (on our personal priority rankings).
Critical bug fixes need to be made before 1.15 can be released, so all available time will be spent on those. Releasing 1.15 is clearly the first priority for 2015.
Happy New Year!
- Deng Team
Comments
Keep up the amazing work! As always I continue to lurk but remain very much interested in every development of this project. You guys are awesome and I can't wait to see what 2015 brings!
The best case scenario is that individual dev's for each plugin will lead to each game receiving the maximum of attention the worst case scenario is that they will lose accuracy and possibly end up with something more like a total conversion of a game to another game.
I think there has been a small resurgence in interest many classic 2.5dfps this last year, due to the unexpected releases of a number of their source codes (Blake Stone Planet Strike, the Catacomb Series, Hovertank, In Pursuit of Greed, Strife Veteran edition); it is a shame that Dday 2.x wasn't ready to leverage that (i.e turn those sparks into something more).
Dday 2.x's 'big moment' of publicity will be when it supports its first reasonably big non-Doom engine based game (i.e not Strife or a Console Doom game), though currently I don’t think Dday’s public image is particularly good, which I think limit’s the options Deng Team have to make that happen.
Obviously though, like Deathmonkey7, I am interested in every development of Doomsday and look forward to every release. Keep up the great work toward the big 2.x!
I was aware of Doom source ports before I found Doomsday, but the thing that always repelled me was the rather hackish nature of projects, i.e. sites that looked like they were written over a decade ago, being expected to compile your own code or download some binaries from five versions ago off someone's Rapidshare link. Of course some are better in these regards than others (Chocolate Doom is really good), but none are as polished as Doomsday. It all looks and feels so nice and professional with its user interface. I love how I can press a button to toggle the task bar and change settings and see the effect right away, I don't have to edit config files in a text editor (looking at you, eDuke). And there is a proper release system, not downloading the latest source control snapshot and hoping more bugs were fixed than introduced.
I also love that Doomsday supports so many games with its plugin architecture. When I bought Shadow Warrior from GOG I was pretty disappointed that there was no current source port that would work on OS X. There are two older ports, but they haven't been getting any attention or non-Windows ports, which is not surprising considering that Shadow Warrior is less popular than Duke 3D. However, with Doomsday even if one game is getting less attention it will still profit from general engine improvements rather than slipping into oblivion again.
A few days ago I have played multiplayer for the first time, my brother and I have been playing through the first episode of Doom together and it was his first time playing an older shooter. His first questions were "how do you sprint" or "how do you aim down sights" or "how do you reload". You guys are doing a fantastic job keeping these old games fresh without compromising their original design, making them accessible for new gamers. I am really looking forward to Doomsday 2.0 when the engine will be able to be a home for all 2.5D shooters.
Obviously, the gulf has been greatly exaggerated over time, but Dday doesn't offer the demo support of PRBoom+, the modding features and content of ZDoom, the FPS performance of GZDoom, the accuracy of Chocolate Doom, the multiplayer of Zandronum etc etc. A part of that is because Dday is splitting it’s resources.
Dday does offer superior visuals to just about any other Doom port (which shows how far ahead of the other ports it was on visuals at one point, as there haven’t been many big changes to Dday’s visuals since 1.8.x), but the other ports have caught up enough in visuals, that the above mentioned features appear to outweigh Dday’s visual edge, to the Doom community.
This is despite that Dday offering a superior demo format (well, currently disabled), a much more flexible modding system (some of other Doom port’s modding features are a mess), more advanced MP code under the hood, perhaps isn't leveraging it's visual edge etc etc
Doom and by extension Heretic, HeXen, Strife etc are a little different from most classic 2.5d fps, simply due to them being games serviced my multiple dedicated ports. Hence, at this point in time, the Doom community is more interested in the features surrounding the game (i.e modding, visual etc). The only way Dday will make inroads into the Doom community again (and by extension it's potential coders), is by picking an area and pumping it up (i.e demo’s, modding, accuracy, visuals etc); something the Doom community can see, that affects the games themselves.
DarkXL comparatively has in the past generated massive amount of hype simply by beginning to support the base games (i.e Dark Forces, Blood etc) because there was no port for those games previously (though as is my understanding, I don't think DarkXL has got complete support for any game yet).
Obviously, I love Doom and I love playing it on Doomsday myself (I use Doomsday for almost every Doom wad I can), but I also love other 2.5d FPS (though maybe not to quite the same degree as Doom) and wonder that if Dday builds a community through branching out into other games, that it may, in the long term, end up benefitting Dday’s Doom support (i.e some of those people that come to Dday through its support for a non-Doom game, may in turn help Dday’s Doom effort and the engine itself).
From an end user perspective, one doesn't need to be overly concerned about the long term future of open source projects. So long as the project is worthwhile and continues to be useful, then chances are it will never "die" irrespective of whether the project's founder(s) or primary contributors remain involved.