"DSDoom"

Game Engines go in this forum
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine are perfectly acceptable here too.

Please read the full rules for more details.

Re: "DSDoom"

Postby Marisa Kirisame » Wed Jul 09, 2014 4:50 pm

Wait... you guys added custom screen shading? Damn that's what I gave up trying to implement...
User avatar
Marisa Kirisame
ZScript Crimester
 
 
 
Joined: 08 Feb 2008
Location: Vigo, Galicia
Discord: 霧雨魔理沙#1666
Twitch ID: magusmarisa
Github ID: OrdinaryMagician
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: "DSDoom"

Postby deathsong13 » Wed Jul 09, 2014 4:51 pm

Saya-chan wrote: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?
deathsong13
 
Joined: 22 Jun 2014

Re: "DSDoom"

Postby Chris » Wed Jul 09, 2014 9:59 pm

DevilBlackDeath wrote: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.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: "DSDoom"

Postby Marisa Kirisame » Thu Jul 10, 2014 2:06 am

deathsong13 wrote:
Saya-chan wrote: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
User avatar
Marisa Kirisame
ZScript Crimester
 
 
 
Joined: 08 Feb 2008
Location: Vigo, Galicia
Discord: 霧雨魔理沙#1666
Twitch ID: magusmarisa
Github ID: OrdinaryMagician
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: "DSDoom"

Postby Sinael » Thu Jul 10, 2014 3:42 am

deathsong13 wrote:[*] 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.
User avatar
Sinael
Russian Ripman
 
Joined: 18 Oct 2011

Re: "DSDoom"

Postby Josh771 » Thu Jul 10, 2014 9:57 pm

Loki wrote:
SidDoyle wrote: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.
User avatar
Josh771
formerly known as SidDoyle
 
Joined: 03 Apr 2013
Location: Elsewhere.
Discord: josh771#7771

Re: "DSDoom"

Postby Loki » Fri Jul 11, 2014 2:01 am

Saya-chan wrote: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.

SidDoyle wrote: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 :P
User avatar
Loki
another goddamn wizard
 
Joined: 07 Jul 2005
Location: Sigil, the City of Doors

Previous

Return to Game Engines

Who is online

Users browsing this forum: No registered users and 0 guests