"DSDoom"

[Marisa the Magician]

Wait... you guys added custom screen shading? Damn that's what I gave up trying to implement...

[deathsong13]

Wait... you guys added custom screen shading? Damn that's what I gave up trying to implement...

We haven't started that feature, what with all the Python. What problems did you run into?

[Chris]

Reason is that the "save anytime" system is kind of cheap Put down some health on the boss without losing health -> save -> repeat over and over (load when losing too much health) and that becomes a piece of cake

Depends how easy it is in the first place. Save-scumming can be cheap, yes, but isn't that up to the player to do? They're the ones playing, and if they get more enjoyment with save-scumming, why purposely make them have a less enjoyable time? If something is too hard to do in a single straight run, and a player needs to be able to save regularly to not lose too much progress, shouldn't that be up to them?

I know because I used to do this, and this is WAY too easy, now I save only at the beginning of every level, and it actually brings some challenge without being cheap ^^ So here are my 2 cents. And it would actually enhance some projects. If not forcing the player to not save, I would at least like to see an option to turn quick save off (I still have the habits of hitting F5 sometimes, I have to refuse saving and that breaks my pace )

Sounds like a self-control problem. Just because you habitually do something you don't want to do doesn't mean you should prevent someone else from doing what they want (or need) to do. Besides, actually saving isn't a problem. If you 'accidentally' saved when you didn't want to, then you can simply ignore or delete that save the next time you're in the load screen (where the flow of the game is already broken).

What would be nice, though, is putting quicksave and quickload keybindings in the customize controls menu (I didn't notice them there when I checked). That way players can disable them if they want, or easily remap them to something more appropriate for them.

[Marisa the Magician]

Wait... you guys added custom screen shading? Damn that's what I gave up trying to implement...

We haven't started that feature, what with all the Python. What problems did you run into?

The source code being a major pain in the butt to work with is pretty much the only problem I ran into. :V

[Sinael]

[*] Hit locations (head shots, leg shots, etc.) natively supported rather than hacked in with custom damage types.
[*] "Paperdoll" sprites (maybe voxels?) that would allow you to say, define a base dude and then seventeen hairstyles and outfits which could be randomized at runtime.

THIS is what I am interested in.

[Josh771]

I think it shouldn't be too hard for any of us to agree that procedural content is becoming increasingly popular and revealing new ways to increase replayability and complexity.

Bingo. In fact, one thing I would love to do, eventually, is to add support for procedurally-generated BSP.

Actually, if you're interested in adding procedural content, there is something I may be more interested in even than procedurally generated BSP: procedurally generated actors. Being totally unfamiliar with ZDoom's source code, I may just be naming the impossible. But, if by chance I'm not, it would be a fantastic aid to ZDoomers that want to introduce new behaviors to several actors without the tedium of going from definition to definition and applying changes by hand.

A seamless integration of decorate and ACS in some sense. Actually, as far as I know, adding new states and redefining states may be just about the only thing scripts have no access to. If there were a way to manipulate these at a base level (for all actors of a type) and on a per-TID basis, that would be incredible.

[Loki]

The source code being a major pain in the butt to work with is pretty much the only problem I ran into. :V

That may be one of the bigger understatements I've heard lately. I sometimes work on a 5-year-old fork of a decade+-old open-source C HTTP server at my job, in which the new code is mostly in C++ but has annoyingly inconsistent C idioms everywhere, and even that was easier to manage than ZDoom's source tree. When you're using malloc() and free() (or, in ZDoom's case, a custom wrapper called M_Malloc()) to manage the memory of C++ types, you've probably taken a wrong turn somewhere. Not to mention that pretty much any code that has to deal with rendering, especially in OpenGL, is going to be pretty hideous by necessity if nothing else.

Aaaanyway, /rant. At least ZDoom doesn't also need to be a highly-available fault-tolerant web service, I suppose.

Actually, if you're interested in adding procedural content, there is something I may be more interested in even than procedurally generated BSP: procedurally generated actors.

That's another thing we've definitely thought about, especially since we're interested in having paperdoll sprites and/or voxels. Given what I know about the ZDoom source, I have a feeling that might even be easier than procedural level generation: to the credit of Randy and co., Actors are pretty flexible, and hooking into the same system that DECORATE uses might prove to be relatively straightforward. Not to build you up too much, though, as I haven't actually tried yet