What do you do if a room is a breeze in one port but way more difficult in another port?

[philcul]

I created a room filled with a chaingunner maze (via positioning chaingunners and using monster blocking lines) which is really a breeze in GzDoom but feels a bit like an RNG-fest in DSDA or PrBoom+. The difference in difficulty probably comes from different movement: in GzDoom it's a rather smooth experience to run through this chaingunner maze while in DSDA/PrBoom+ I bounce all over the place. The map was made in boom format, so of course I want players using the latter two ports to also have fun with it, but I also do not want to throw the room away. I could of course make it easier but then I fear that it's too easy for GzDoom. So, what would you do in a similiar situation?

 

EDIT: Well, I just bit the bullet, made a few changes so that the room is now a decent movement challenge in DSDA/PrBoom+ but a bit too easy for GzDoom. But I guess that's okay.

 

Still: Have you ever had similiar problems where one room seemed fair in one port but too easy in another? How did you deal with that?

Edited August 11, 2022 by AdNauseam

[Somniac]

I think about this a lot, and I think there's a discussion to be had here around how the mechanics of ports affect maps and the targeting of certain source ports for mapping. 

 

When I made my last mapset, I targeted and tested in Crispy Doom. In effect, the maps were "built for" Crispy Doom, but being vanilla format maps they naturally worked in multiple ports. I found testing in PRBoom+ also felt "right" for those maps. GZDoom on the other hand, mechanically I found it made everything feel too smooth and easy. I know a lot of people use GZDoom to play regular Doom maps, and it was compatible by default, but I felt those maps were just too easy in GZDoom. I just left them that way and people can make their own choice as to which port to use, but I do feel that it can colour the impression of a WAD in a way that you as a designer might not want, or may not have taken into consideration. 

 

I don't want to try and dictate to anybody what source port they should use for my map or anyone else's. Part of the fun is that there's a berth of ports to meet the requirements of a large base of players and mappers., but they do all have their own feel that can affect the experience. You do make a good point and its something I haven't seen discussed that much. 

[Biodegradable]

Cross-port compatibility does sound like a real ball-ache when it comes to mapping given the different objectives and behaviours of different source ports, so I sympathise with you on that front. While trying to make your project work across multiple ports is a commendable effort and allows for greater exposure to your work, don't be afraid to narrow the focus on specialise on a specific port(s) that cater to how you wish to design your WAD. There are plenty of WADs, even recent ones like Heartland, that have done so.

 

It's all up to you on how you wish your work to be presented and played.

[thiccyosh]

Cry and hope nobody notices.

[IcarusOfDaggers]

The smooth movement of GZDoom comes with it's own set of challenges. I suggest visiting that room when you have finished rest of the map, because what you need to alter is level geometry (or more precisely, floor geometry). 

I have not seen your map or released many of my own yet so I don't know if it can be changed in this case.

 

Booms bouncyness comes from the player moving up the steps with a stronger gravity than GZDoom has. As a result, you just need higher steps to make the steps of GZDoom feel the same as Boom.

 

It happens to be the same with wall collisions. Because GZDoom softens blows, you can make the walls a bit more uneven for them to feel the same as from Boom. The reason you need two different versions is exactly because of GZDoom movement and collision detection being different from Boom or vanilla movement.

I think it is also possible to use zscript to give GZDoom a more authentic boom feel, but I do not know how to do that (i'm making doom maps because it really does not require that much knowledge of scripting for ports outside GZDoom xd, so it's easier to learn as a hobby at first).

 

 

[HAK3180]

I think the best thing you can do is have one or two main target ports. Test early and often on these and just test for functionality on others, if at all. I hesitate to make compromises like you have described because, in my opinion, it's better to have at least one port that is the perfect representation of what you were trying to achieve than to say essentially, "It's tested thoroughly in all these ports, but none of them ends up being my true intended design."

 

Another philosophy (which you could adopt for subsequent efforts, not this one) would be to avoid having such situations where different ports do very different things. So if you think of such an idea, you don't implement it. That's a different kind of compromise that just stays in your mind and never makes it into the wad for people to see. 

 

For me, the biggest ones are manual vertical aim and infinite height. These are such deal breakers to some players that I don't want to say, "These must be turned off." I just make a note that I don't design with them and test a lot less with them. But for the most part, I'm still mentally all in on these being off in my designs, except for shoot switches, which I often make sure to recess properly to prevent GZDoom sequence breaks.

[Solmyr]

Frown at the port driven difficulty discrepancy.