"DSDoom"

[deathsong13]

REPO LINK: https://github.com/stefanbeeman/gzdoom

Some friends and I are currently working on several changes in the GZDoom source code. I can't promise that these will pan out but I wanted to see what you guys would think of:

• Embedded Python interpreter allowing for much more powerful scripting.
• Adjustments to the renderer, including the ability to apply arbitrary shaders to cameras and improved voxel support.
• Hit locations (head shots, leg shots, etc.) natively supported rather than hacked in with custom damage types.
• Completely configurable UI/UX via libRocket (http://librocket.com)
• "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.
• MAPINFO option that allows you to limit the ability of the player to save, either forcing "checkpointing" or "roguelike" modes.

Also, sorry for being absent for like ten years. I was learning to code in a monastery.

EDIT: Someone has suggested I base this on Zandronum instead of trunk to get all that Skulltag netcode. Never a big Skulltag fan so I'd appreciate some thoughts on that before I go too much farther.

[Tapwave]

Er, do you have anything to actually show to us? Because if you don't, you're posting in the wrong section.

But anyway:

• Kate has already worked on a python-for-zdoom thingy, PyDoom if I recall correctly, you might want to ask her.
• Camera Shading and Voxel Support could potentially pass as code suggestions if you have the material finished. Same for the MAPINFO ideas.

[Chris]

• Camera Shading and Voxel Support could potentially pass as code suggestions if you have the material finished. Same for the MAPINFO ideas.

I think the idea of limiting player saves has been emphatically rejected multiple times. Checkpoints is such an antiquated idea, and was only necessary when consoles had limited saving capacity (checkpoint saves are actually just an extension of passwords, where the password literally represented the game state and couldn't reproduce it exactly). Having autosaves at specific points within a level is fine IMO, but preventing players from making their own saves outside of them is a Bad Idea.

[Jblade]

Having autosaves at specific points within a level is fine IMO, but preventing players from making their own saves outside of them is a Bad Idea.

Leave that up to the author to decide - like deathsong said it would be ideal for a roguelike or an ironman level or something like that.

[HexaDoken]

Leave that up to the author to decide

What about leaving that up to the PLAYER to decide? If somebody wants to play with permadeath, they are perfectly able to. It does not take that much willpower to not use the save functions. If somebody doesn't want that, it is my opinion that they should very well be damn able to.

EDIT: Someone has suggested I base this on Zandronum instead of trunk to get all that Skulltag netcode. Never a big Skulltag fan so I'd appreciate some thoughts on that before I go too much farther.

If you don't mind spending extra time to adapt the netcode to additional functions as well as losing roughly two major revisions of functionality, then yeah, why not.

[deathsong13]

Er, do you have anything to actually show to us? Because if you don't, you're posting in the wrong section.

I have some Python support done - you can check it out here: https://github.com/stefanbeeman/gzdoom/tree/cython

Kate has already worked on a python-for-zdoom thingy, PyDoom if I recall correctly, you might want to ask her.

I asked Kate about this, and she said:

I eventually gave up on the project, because it really was not worth all of the effort to create what is essentially a swiss cheese engine.

Camera Shading and Voxel Support could potentially pass as code suggestions if you have the material finished. Same for the MAPINFO ideas.

I'd be more than happy to contribute this stuff to (G)ZDoom, once it's more mature.

I think the idea of limiting player saves has been emphatically rejected multiple times. Checkpoints is such an antiquated idea, and was only necessary when consoles had limited saving capacity (checkpoint saves are actually just an extension of passwords, where the password literally represented the game state and couldn't reproduce it exactly).

As far as I'm aware, many modern shooters eschew arbitrary saves in favor of checkpoints, as they're less disruptive to gameplay. I don't personally like this, but the point is to put that decision in the hands of the individual modder.

It does not take that much willpower to not use the save functions. If somebody doesn't want that, it is my opinion that they should very well be damn able to.

If my project is intended to be a Roguelike, saving would be cheating. Disabling the menu option and flagging the save options as cheats seems like a harmless enough change.

[Josh771]

I think the idea of limiting player saves has been emphatically rejected multiple times. Checkpoints is such an antiquated idea, and was only necessary when consoles had limited saving capacity (checkpoint saves are actually just an extension of passwords, where the password literally represented the game state and couldn't reproduce it exactly). Having autosaves at specific points within a level is fine IMO, but preventing players from making their own saves outside of them is a Bad Idea.

I had to hop in on this subject just because the thought of checkpoints as some obsolete necessary evil of the past baffles me. Checkpoints have often thwarted me in games that required me to pull off a veritable marathon of skill; these kinds of setups are a deliberate tool for the developer to use. Often even games that allow arbitrary saves can interject a scene which must be carried out in its entirety (boss fights, final sequences, timed events, etc) and which do not allow the player to save as a way of increasing the difficulty of that particular scene -- you can call this artificial difficulty if you like, but I find myself feeling much more accomplished after completing just such a scene.

Procedural environments were a necessary evil for the original Rogue. It's not as though memory was so abundant and cheap back in the day, so persistent dungeon levels were out of the question. But the introduction of advanced mapping tools and gobs of RAM and disk space does by no means make procedurally generated environments obsolete; rather, the two are viable options for the savvy game developer. 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.

Just a little rant. I say the feature would be very welcome, quite appropriate even for my Rogue the Doomlike project. I think I'm not the only ZDoomer who's wanted the permadeath / save-restrictive option. Count me interested, if this takes off.

[Hetdegon]

I'd also like to limit savegames in my current project. So you get a checkpoint before boss battles, but not during them so they can't be cheesed into defeat.
But paperdoll sprites would save a lot of memory in my project, specially for random civilians, and arbitrary camera shaders would give me a ton of visual control. I'd really love to see those becoming a thing.
Python would be excellent as well. I am more partial to Lua, but support for better math in scripts (or, more convenient to write, rather) would be simply delightful.

[HexaDoken]

As someone with a wacky time schedule that sometimes forces me to absolutely suddenly and abruptly quit a game, and as someone who has a bad enough luck for this to always happen right when I'm in the middle of something, I am naturally a person who is opposed to the idea of not being able to save anywhere anytime.

I too am against saving TOO often and usually go for extended periods of time without saving(especially during boss battles, unless they are particularly long and boring), however, I still like to be able to save anywhere anytime just in case something will explode and I'll need to leave asap.

As for "cheating", it will not actually be much trouble to make a duplicate of the save file. Unless it is not created at all. Which means that your roguelike will have to be beaten in a single sitting. Unless it's one or two hours, not fun.

Though, I may have a certain bias in this discussion since I'm a long time opposer of the concent of perma-death in roguelikes.

[deathsong13]

As someone with a wacky time schedule that sometimes forces me to absolutely suddenly and abruptly quit a game, and as someone who has a bad enough luck for this to always happen right when I'm in the middle of something, I am naturally a person who is opposed to the idea of not being able to save anywhere anytime.

As for "cheating", it will not actually be much trouble to make a duplicate of the save file. Unless it is not created at all. Which means that your roguelike will have to be beaten in a single sitting. Unless it's one or two hours, not fun.

"Roguelike" mode would create a save file on quit and restore it on resume, if possible.

[Somagu]

As someone with a wacky time schedule that sometimes forces me to absolutely suddenly and abruptly quit a game, and as someone who has a bad enough luck for this to always happen right when I'm in the middle of something, I am naturally a person who is opposed to the idea of not being able to save anywhere anytime.

I too am against saving TOO often and usually go for extended periods of time without saving(especially during boss battles, unless they are particularly long and boring), however, I still like to be able to save anywhere anytime just in case something will explode and I'll need to leave asap.

As for "cheating", it will not actually be much trouble to make a duplicate of the save file. Unless it is not created at all. Which means that your roguelike will have to be beaten in a single sitting. Unless it's one or two hours, not fun.

Though, I may have a certain bias in this discussion since I'm a long time opposer of the concent of perma-death in roguelikes.

If someone wants to back up their saves instead of opting for permadeath, then they will. I'd personally rather this kind of thing be "opt-out" by manually backing up saves than "opt-in" by manually deleting them postmortem, if it's up to the map author. I happen to think roguelikes without permadeath are pretty boring and inconsequential, but I've always preferred when games have the potential to make me constantly eat dirt rather than a casual stroll. Of course, that's just my preference. I completely understand where you're coming from about preferring a lack of permadeath.

As for the idea of this branch on GZDoom, I'm not sure if this is on the right subforum, but I absolutely think these would be some welcome and excellent changes for certain projects!

[deathsong13]

I'm not sure if this is on the right subforum

If you're out there, mods, move this to the right place. I seem to be incapable of posting in the right place.

[DevilBlackDeath]

• Camera Shading and Voxel Support could potentially pass as code suggestions if you have the material finished. Same for the MAPINFO ideas.

I think the idea of limiting player saves has been emphatically rejected multiple times. Checkpoints is such an antiquated idea, and was only necessary when consoles had limited saving capacity (checkpoint saves are actually just an extension of passwords, where the password literally represented the game state and couldn't reproduce it exactly). Having autosaves at specific points within a level is fine IMO, but preventing players from making their own saves outside of them is a Bad Idea.

Wow there. Many things to say. First off, I'm not all that sure checkpoints were invented before "save whenever you want" (and even if that's the case, they were not THAT much used and are not an extension of passwords as far as the initial ideas is concerned IMO), and they've been used a whole lot since the "save anytime" system. 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 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 )

Edit : If you make Python scripting a reality I will love you Possibilities would be theoretically endless if correctly implemented

As someone with a wacky time schedule that sometimes forces me to absolutely suddenly and abruptly quit a game, and as someone who has a bad enough luck for this to always happen right when I'm in the middle of something, I am naturally a person who is opposed to the idea of not being able to save anywhere anytime.

I too am against saving TOO often and usually go for extended periods of time without saving(especially during boss battles, unless they are particularly long and boring), however, I still like to be able to save anywhere anytime just in case something will explode and I'll need to leave asap.

As for "cheating", it will not actually be much trouble to make a duplicate of the save file. Unless it is not created at all. Which means that your roguelike will have to be beaten in a single sitting. Unless it's one or two hours, not fun.

Though, I may have a certain bias in this discussion since I'm a long time opposer of the concent of perma-death in roguelikes.

I do agree and everyone with their life has a schedule. Back in the GBA times, they created a great feature too many times forgotten, of which I can't remember the name, but the concept was that you could indeed save wherever you want, but when you loaded your save file, the save was deleted and you were forced to use the checkpoints or whatever other system was used again So for example in A Link to the Past GBA you could do this wherever you want (even in the middle of a boss fight), then if you loaded that save game and died during a fight, you were sent back to the beginning of the dungeon or your house ^^ That imposes of course that this save system kicks the player out of the game ! Great concept used only on handheld devices...

[Loki]

Hey, all. I'm one of the other devs working with Deathsong, and we appreciate the feedback a lot. I, too, spent several years learning to code at a monastery not too long ago, albeit at a different one (mine was in a little town called Claremont). Having left the monastery, I now work as a systems programmer for a startup.

We're still working out how we want to divide the labor, but one of the features that I intend to write is a querying system over actors and sectors ("DoomQuery" lol), so you could conceivably do something like

Code: Select all

import zdoom.actor.properties as prop
import zdoom.actor.types as at
import zdoom.doomquery as dq
from operator import gt
from functools import partial

dq.actor
    .type(at.Monster)
    .where(prop.mass, partial(gt, 50))
    .do(prop.vx() += 100)

Or

Code: Select all

dq.actor
    .type(at.Monster)
    .where(prop.mass, partial(gt, 50))
    .do(lambda a: a.vx += 100)

And so on. I'm still working out what the API for that should look like, but I'm taking inspiration from the APIs for jQuery, ASQ and Mongoose. Feedback is always appreciated.

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.

[edit] Code cleanup [/edit]

[DevilBlackDeath]

Hey, all. I'm one of the other devs working with Deathsong, and we appreciate the feedback a lot. I, too, spent several years learning to code at a monastery not too long ago, albeit at a different one (mine was in a little town called Claremont). Having left the monastery, I now work as a systems programmer for a startup.

We're still working out how we want to divide the labor, but one of the features that I intend to write is a querying system over actors and sectors ("DoomQuery" lol), so you could conceivably do something like

Code: Select all

import zdoom.actor.properties as prop
import zdoom.actor.types as at
import zdoom.doomquery as dq
from operator import lt

dq.actor
    .type(at.Monster)
    .where(prop.mass, lt(50))
    .do(prop.vx() += 100)

Or

Code: Select all

dq.actor
    .type(at.Monster)
    .where(prop.mass, lt(50))
    .do(lambda a: a.vx += 100)

And so on. I'm still working out what the API for that should look like, but I'm taking inspiration from the APIs for jQuery, ASQ and Mongoose. Feedback is always appreciated.

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.

Wow, between this and full Python support (I assume this query language would be part of the Python support as some package) that could bring some really huge scripting capability to Doom Really will keep an eye on this one :