Jump to content

Do you obsessively playtest your own maps?


Do you obsessively playtest your own maps?  

89 members have voted

  1. 1. Which of the following applies to your playtesting process?

    • I only use the editor, playing it is your problem
      1
    • I use editor features and tools to scan for common mapping issues like OOB things and HOM textures
      24
    • I test specifically for softlocks, cheese strats and unintended progression as well as I can
      40
    • I make sure the ammo and health is reasonably calibrated for getting all kills (if desired)
      47
    • I make sure to get feedback on the gameplay from a few people before the public release
      30
    • I will test multiple ports and complevels to prevent stuck monsters and other preventable issues just in case
      25
    • I'll actually boot the thing up in a source port to see if it runs and has custom sprites and MIDIs working
      39
    • I'll make sure I can beat the map without incident on at least one skill setting
      50
    • I spend a lot of time playtesting at every stage of the build, and rarely make major changes without careful testing
      67


Recommended Posts

I'm curious what level of effort people generally put into playtesting their own stuff at a minimum. Select all that apply and feel free to share details about your process. 

 

Also I'm not trying to make this about design choices, eg maps that are impossible to 100% because the mapper didn't care or those with intentional softlocks. Obviously playtesting is more about checking whether your map meets your goals and standards as a mapper. I didn't include checking for broken secrets because there are a lot of options already in the poll. 

 

Spoiler

Personally I spend a lot of time iterating through changes and I'll often test out a section I'm working on to check minor things like texture alignment on moving sectors. Part of it is my modest experience not trusting myself to do it blindly, but also I tend to take a lot of pride in not making dickhead mistakes and putting out a broken map. As a result of this and experimenting with somewhat nonlinear design, I usually go ham and try every route and strategy I can think of.

 

I either go very slow trying to be meticulous about the design of the map in one session, or I'm productive as hell but finish nothing but cosmetics in another.

 

Share this post


Link to post

I usually test the maps as I make them to make sure that each room, door or linedef action works smoothly, but I admit that at the end of the process of making a map I'm pretty exhausted from playing it over and over again, so almost always the first players end up reporting me some misaligned texture or similar problems.
My advice to anyone who wants it is not to publish or send the map as soon as you finish it. Wait a day or two, play it again, and if you find no problems, then publish it.

Share this post


Link to post

It depends. I rarely playtest until the map is pretty much done, unless there is a setpiece fight which is a major part of the map. Afterwards, I will test the map for ammo balance (and add 10-15% to what I am comfortable with) and make sure setpiece battles are not cheesable (if so desired). I have some people test my maps before release as bugs, unwanted itembumps, HOMs are inevitable.

Share this post


Link to post

Nice thread!
 

For me, playtesting is not only something I do in order to hunt for bugs and stuff, but it's rather a crucial part of the creative process itself. Whenever I implement a new room, a fight, a puzzle, you name it, I run it and see how it plays and then iterate on that. Since non-linear maps are my thing, I also play them a lot to try to get an idea of whether the progression flows naturally or if it feels forced/confusing. I also find playtesting a partial map very useful in order to come up with new ideas on how to continue it, especially if you're having a mapper's block.  
 

In general, if you see a map published by me, you can safely assume that it has been played tens, if not hundreds of times by myself during the whole development, and at least once by one or more playtesters once it's in a more or less finished state.

Share this post


Link to post

I hate making gameplay, I play through the map every single new encounter I make just so I can get a rough idea on how you'll be fairing when you get there then how you'll end up afterwards.

 

Takes forever.

 

Sometimes I make the entire gameplay then run the thing through to ensure there are no points where you are boned.
 

Non linear maps are a massive struggle, corralling someone to where they won't get obliterated is how I always preferred it.

Share this post


Link to post

I test my maps until I'm sick to death of looking at them, and that still doesn't stop me from missing a few things

Share this post


Link to post

yes.  It's one of the reasons I don't make many maps; I spend way too much time testing to the point I hate my maps.

Share this post


Link to post

The maps I made in the period 2009 to 2014 for TNT:Foreverlution?

 

I still tinker and playtest them on a semi regular basis.

Share this post


Link to post

Yes, a lot. I think this is part of the reason I'm so slow at mapping, I iteratively playtest too much.

Share this post


Link to post

Testing pretty much occupies 50% of my mapping process. The other half is just staring at the screen blankly until something pops up in my head and then draw it.

Share this post


Link to post
4 hours ago, Lucius Wooding said:

I'll make sure I can beat the map without incident on at least one skill setting

 

may i know what you mean by [without incident]? do you mean "without dying"? thanks in advance.

Edited by rita remton
clarification

Share this post


Link to post

You're not a real mapper if you don't visit your map each time you do a tweak.

Edited by Roofi

Share this post


Link to post
15 minutes ago, Roofi said:

You're not a real mapper if you don't visit your map each time you do a tweak.

 

F yeah dude. It's that sigma Doomer grindset amirite? (Did I do the coolkids thing right?)

Share this post


Link to post

Yeah I tend to test a lot as I build my maps, ranging from just getting a feel for the environment to actually testing the gameplay. As for difficulty, it isn’t so much about surviving a map but gauge as to whether the fights are beatable without being too rage inducing.

Share this post


Link to post
3 hours ago, rita remton said:

 

may i know what you mean by [without incident]? do you mean "without dying"? thanks in advance.

 

I guess this might be a bit vague. It's mainly about completing a run without dying, but I realize some mappers might use saves if they're making something hard enough or they just consider them intended. It's less about skill than about being able to reach the exit with full knowledge of the map's progression and thing placement. I guess we'll call it "I can reach the exit in my own map", but whether it includes saves is a matter of personal standards. I can't account for every different playstyle with its own poll option and I don't want to get into the weeds too much. 10 options is already a lot.

 

It was a hard poll to make since there are a lot of approaches I had to account for. I mainly made the thread for the replies anyway since people may view without voting, or not realize it's a multiple choice poll so the results will only be roughly accurate.

Share this post


Link to post

Mhmmmm... grinding that odd angle for hours at sr40 to see if player bobbing and quick turns will produce a vpo...

Mhmmmm... playtesting a map that's been left alone a week or two because it was complete; then adding a bunch of new areas --> see above.

Share this post


Link to post

I'll test to make sure everything works in the intended sourceports and for ammo/health/monster balancing, but I don't do nearly enough bug or exploit testing. Perhaps a bad habit picked up from mostly doing speedmaps.

Share this post


Link to post

Loading up on the ground level, full fight no cheats is the only way to progress anything and its still not enough to prevent errors.

 

YOU HAVE TO PLAYTEST LEGIT FOR EVERY SINGLE CHANGE NO MATTER HOW SMALL

Edited by Dreamskull

Share this post


Link to post

I definitely play-test the hell out of my maps… however; I’m not too great at being a player, which results in the maps probably becoming pretty easy for many Doomers out there. 

Share this post


Link to post

I used to tell myself "oh, I don't need to playtest this whole 30 minute map just because I moved some vertices to fix a slime trail." Then I discover some revenants in a closet don't wake up any more and UDB has unmapped the hidden textures on all my lifts. Playtest, playtest, playtest. Always playtest.

Share this post


Link to post
Quote

I will test multiple ports and complevels to prevent stuck monsters and other preventable issues just in case

Why would you test in multiple complevels lol.

Share this post


Link to post
3 hours ago, Ravendesk said:

Why would you test in multiple complevels lol.

 

Yeah I get that complevel is mainly about demos, but let's remember for a second that most players have no clue about any of that. Unless I'm trying to get cute and rely on those behaviors, it's better if the map is built robustly and plays more or less properly across various settings. This kind of testing is not something I consider completely necessary, but based on the results it looks like a lot of people in this thread, like me, favor overkill when it comes to testing. It seems about as common as using the automatic editor features to check for mapping errors (which should be the first thing taught in mapping school IMO even though they have their limits).

 

Most threads on the topic indicate that at best 30% of people are on any given port and obviously people want to use what they're used to. Yet the vast majority of projects list a single source port as their target and don't bother to try anything else. In my case I like to target both PRBoom+ and GZDoom since they are both popular, and very often I'd find one would fix certain issues like stuck monsters or broken closets automatically, but not the other. This goes even further when you consider visual things like slime trails and light levels which will look completely different between the two. Another issue that was raised was how bouncy collision walls in tight quarters could get annoying due to subtle differences in movement. Or you might be able to crowdsurf on top of non-infinite height actors to reach a unique softlock, or abuse freelook. All things I'd rather not have in my map if possible.

 

Yeah I agree it's on the player to follow directions for the intended experience, yet when has any user using any kind of product been good at following directions? Plus I'd want to know just out of curiosity how things change. I consider it time well spent since my own knowledge was improved as a result.

 

I may have built a map to be limit removing, but a large chunk of people will boot it up in GZDoom where the default settings are not at all accurate to my carefully chosen complevel. These players usually aren't going to know about complevel minutiae or source port differences. And I'd rather not have a lot of my effort dismissed over something preventable. People are not going to always give the map a chance if they run into an issue of their own making, so I'd rather not give them a reason to shitcan my map unnecessarily. Better that they just finish it without problems than hear an earful about complevel and port differences. Players will move on, not accept blame and correct their behavior.

 

3 hours ago, SilverMiner said:

I still hadn't fixed a certain softlock on a certain map despite that I've been replaying it for around 7 years

 

Persian flaws are a thing. Personally I found one or two very minor cosmetic mistakes in one of my maps later on but I'm leaving them in because the scope is so small. On the other hand I updated the thing on idgames even though I had considered it complete when I discovered an annoying unintended switch press even though it didn't really affect the progression. 

Share this post


Link to post
2 minutes ago, Lucius Wooding said:

Yeah I get that complevel is mainly about demos, but let's remember for a second that most players have no clue about any of that. Unless I'm trying to get cute and rely on those behaviors, it's better if the map is built robustly and plays more or less properly across various settings. This kind of testing is not something I consider completely necessary, but based on the results it looks like a lot of people in this thread, like me, favor overkill when it comes to testing. It seems about as common as using the automatic editor features to check for mapping errors (which should be the first thing taught in mapping school IMO even though they have their limits).

I think you got it the other way around.

 

Map is always aiming for a certain engine (doom, boom, mbf21, etc). Complevel is a thing that allows a single source port to run maps for different engines. You just specify a correct compatibility level and here you go.

 

Surely there is a fundamental misunderstanding about the difference between compatibility level and a source port in many players' minds, but let's not make it worse by enforcing this misunderstanding as mappers, because its not productive to cater to it.

 

Testing in various sourceports - ok, sure. But don't test in various complevels, it makes no sense.

 

Let's say you are making a cl9 map. You tested it with cl21 and it breaks. What are you going to do about that? There is absolutely no way to fix that problem, what's the point of testing then?

Share this post


Link to post
1 hour ago, Ravendesk said:

what's the point of testing then?

 

You can take a source port and set whatever compat flags you want to get whatever settings you want. A complevel is just a list of settings that are agreed upon for demos and keeping things as intended. Every setting could probably break some maps on its own. 

 

 

I never said it made sense to test all complevels that exist. You're not limited to the list of standard complevels anyway unless you're recording demos; if you truly want to be thorough then you should test every permutation of different settings flags in a given port. (This is ludicrous obviously). But surely it's reasonable to at least make an effort to check the default settings of the most common source ports? (Is there any source port that even uses mbf21 as a default? Come on now, nobody is going to stumble into that one on accident.)

 

Someone might open a Doom 2 map in Boom or ZDoom ports by accident; I just want to make sure the map is playable in that case. Playtesting these edge cases gives you a good idea of what the experience might be, so you can see if archviles falling off a ledge or the lost soul limit really ruin the map. If it is a big deal then you can make an effort in your post to warn the player that X settings definitely make the map unbeatable or something.

 

And then when you throw GZDoom into the mix it all goes out the window. It has compatibility settings as well but only behaves similarly to other ports; in fact GZDoom doesn't have true complevels as I'm sure you know. Even if you use the Boom compatibility mode or something, it won't be close enough for demos not to desync with actual Boom. But it is functionally equivalent enough for most players to still be playable and give a good experience.

 

In your point of view "breaking" a map refers to affecting demo compatibility, which casual players don't give a toss about. There is an important distinction between that and making the map unbeatable, or affecting the gameplay and balance in a major way. 

 

In my opinion, if this really were so worth enforcing, we should make the port throw an error and refuse to load the map if it's under the wrong settings. I'm afraid the horse may have left the barn on this one since the game is 30 years old. But it is common practice in programming to make the thing break at the beginning rather than try and run in an undesirable way. Personally I wouldn't mind this at all but it seems like most development gets driven by adding shiny features while compatibility settings are more of an optional sidebar.

Share this post


Link to post
6 minutes ago, Lucius Wooding said:

But surely it's reasonable to at least make an effort to check the default settings of the most common source ports? (Is there any source port that even uses mbf21 as a default? Come on now, nobody is going to stumble into that one on accident.)

Whatever, let's do it the other way around if you want, the wad is in mbf21, you tested in in cl9. It doesn't work (duh), what are your further actions? How are you going to address this problem? What is the purpose of testing in different complevel if in case of a) everything it working - you do nothing, in case of b) something is not working - you literally cannot do anything, it is a complevel-specific thing that broke.

 

And I'm not talking about demo compatibility, I'm just talking about the map not functioning properly in a different cl.

 

You made a voodoo closet in cl9, the map no longer works in cl2. You made a instakill floor in cl21, you tested it in cl9, it doesn't work. You made a cl9-specific instakill floor setup (see wormwood 3), it doesn't work in cl21 or cl2. Ok, so? Your actions?

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...