JPL

Having spent a lot of time looking at old FPS engines and more recently some time looking at ScummVM and SCUMM specifically, I think the biggest differences are that adventure games have way simpler technical demands that lend themselves to a common "everything engine". Scumm was definitely upgraded over the years (1987-1997) to do many new things, and even fully rewritten once, but there weren't any real "paradigm shifts" in hardware capabilities that changed everything the way Wolf3D -> Doom -> Quake -> onward did. The latter technical leaps meant massive changes to data formats, simulation, rendering, networking, the works. As plenty of projects have shown you can definitely "emulate" Doom in Quake and even kinda vice versa, but FPS are so dependent on things like how the lower level controls and collision feel, how levels are constructed, and how game logic is defined. At the point that you're writing entirely different code paths to cover those differences, you might as well have different engines with a few shared libraries, which is what we have anyway across all the different source ports. I don't get the impression that duplication of effort is a major problem there. It's understandable to wonder about though!

Check this post, I made optional addon PK3 for the MIDI packs and Romero's levels: https://itch.io/post/4237949 These are offered without any support; if something goes wrong someone else here can probably help you figure it out. I don't want to make these part of Wadsmoosh itself because they work fine as PK3s and doing otherwise would create the need for configuration and customization. The files are hosted on my non-HTTPS website, but they're just ZIPs with data in them. If your browser complains then use Firefox and tell it to "download anyway". Feel free to mirror them here or wherever.

If you want to keep tabs on the very latest work done, see this view of the different branches in github: https://github.com/luciusDXL/TheForceEngine/branches Last commit was a couple weeks ago. Also worth noting that some work might be going on in non-public branches or depots. This is really normal with spare time open source projects, people get pulled away by real life stuff, energy for the project wanes and waxes, etc. I say let folks take a break when they need to. Lucius made incredible progress over the last year, I'm happy to wait.

For folks following this project, it does look like great progress has been made since the last update, in this branch of the project's git repo: https://github.com/luciusDXL/TheForceEngine/commits/release Basically lots of game sim being implemented, as Lucius described in the last update: https://theforceengine.github.io/2021/04/12/GameLoop.html

Thanks for the explanation Lucius! I'm familiar with that style of gradually filling in a disassembly. Your commenting style is very good and makes it very easy to understand what's going on in that excerpt, I strive for that with my own work. Looking forward to playing the results, keep up the great work.

Very cool! For possible future project news posts, I'm curious to know what your process for reverse engineering is. Do you use a disassembler, monitor the running game in DOSBox, something else, or a mix of techniques? I've never done this kind of programming before and it's where lots of "reimplement old game" open source projects seem to hit a hard wall after getting the formats figured out and the world rendering.

I do zero competitive stuff and thus don't have the same stake in this that others do, but I do think a lot about game pacifism, game tourism, and "nonviolent" mechanics so here's my take. I think the word "pacifism" is too laden with non-Doom sociopolitical meaning to try to revise its definition in the context of Doom. I would rather just create a new category called something different, eg "No Direct Damage". Partly out of my designer instinct for simplicity, my notion of it would be that *everything* except player-fired hitscan or projectile damage to living monsters is okay. To me that is the true shift in player headspace + tactics and it's not worth it to force players to think about game engine internals like which entity an exploding barrel considers to be its damage instigator. Just don't shoot monsters or hit them with splash. No Direct Damage. Let the current definition of Pacifism stand as it has for decades. I definitely appreciate all the interesting discussion around this though!

Update: I decided to finish up the readme and release this project for real, it's now available here: https://jp.itch.io/deluxe-master-levels

Hi again. This project is now hosted on itch.io, with a semi-fancy page and stuff: https://jp.itch.io/deluxe-master-levels Until it's ready for full public release I've locked it behind a password, "dewm", but anyone here who's interested should feel free to have a look. Changes since last build: Added masters_readme.html, which includes instructions on how to run the compilation and an essay-format writeup on the project, its slice of Doom history, and individual levels. Still a work in progress, pretty much the last thing I have to finish. The parts of the doc that are still being worked on are clearly marked. On Xaser's advice, renamed the final level of Inferno to "Waters of Lethe". Renamed internal map filenames to their original WAD filenames - only affects map name as displayed in automap.

I'm playing through the Top 100 Most Memorable Maps list in reverse order, and just got to #93, "Underworld Citadel" (E3M7), and fell down the rabbit hole that is the whole separate secret area. It looked very different and kinda distinctly 1990s-ish to me so I did some digging and sure enough it's from E1M1 and E2M4 of The Beginning of the End, Tvventy's first WAD from 1997. Just wanted to register my intense appreciation for this kind of callback here. Excellent work on this set, folks.

(deleted, missed the second page's reply to a question)

Hmm, yeah I knew this would have to account for the potential range of port features somehow but I'd hoped that stuff as specific render style wouldn't have to be stored. Is the point of a UDMF-like format here just that keys like RenderStyle can be optional? Anyways yeah if the answer is "It'd be a lot of work, and people don't care enough about demos / are fine with demos as they currently work, for it to be worth the effort", that's fine, it was just an idea I had.

I'll defer to the testimony of actual port authors, but speaking just as a programmer I'd have to really think carefully about how to do it in my own engine. And I think certain architectural assumptions about how to handle time and simulation stepping make it relatively easy, hard, or nigh-impossible. From everything I know of Doom's architecture it wouldn't be easy. For example, how do you "rewind" an actor that existed for a while but is now destroyed (as in, not just fatally damaged, but actually despawned and garbage-collected)? You can determine the future state of an actor much more easily than you can determine what happened to it previously from a given tick. It's different for eg a time-based puzzle game where you deliberately write everything so time can move backwards, but Doom obviously ain't that.

Yeah, these are 100% valid concerns and questions. That's why I'm wondering how much work the initial research would be, ie to determine what the real squeeze would be. (I'm not quite comfortable enough with C that I could just bang this out myself, unfortunately.) I do think there's a chicken-egg dynamic where more people (beyond speedrunners) might use demos if they were more widely compatible and accessible, ie as simple as pressing the Share button on a PS4 controller, but that's speculation. As for the more experimental uses, I think it'd need a killer app, something someone really wants to make that they couldn't do as easily any other way.

Thanks for the responses! A couple more thoughts: The first steps towards proving something like this out would probably be to take a vanilla-compatible source port that is reasonably easy to work with, like Chocolate Doom, and hack in just the LMP playback + export support described above. Then hack in playback support for the generated data. See how much work it is to make that process stable. Check the I/O and disk space concerns. If it seems promising, start thinking about how to actually standardize the format and what features it would need to work with the full range of possible codebases. This might be a can of worms, but I'm thinking about things like the Heretic teleport "glitter", that spawn tons of actors that essentially don't affect the playsim at all, and ZDoom-derived mods that spawn tons of particle fx actors. These would bulk up the data a lot without much point. So maybe you could flag certain actor classes as "let the playsim handle these", only their spawn is recorded by the demo data and the game is responsible for updating them as in a traditional format demo. Potentially messy implications but it seems like it could be a good option to have.