Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Big Ol Billy

How do you know when a map is "ready"?

Recommended Posts

Posted (edited)

What's your rule of thumb for when you send a map to others to play? How does this vary by the nature of the map and the people playing it?

 

I've been going around and around on my Interception II map recently. "This fight on HMP could be better... maybe if I adjust the geometry a bit... ok, just better make sure I didn't break something on UV—OFC I JUST BROKE SOMETHING ON UV... ok, fixed that... hmmm, but I should really check the fight on HMP again just to make sure... well, what if I use that alternate route..." But I've noticed I always get to this point on a map, where it's teetering on the edge of being worth playtesting but it's hard to break out of the loop of tweaking stuff, especially when I'm still occasionally finding stuff that's broken or very suboptimal.

 

You want to be respectful of your playertesters' time, but should you just keep tweaking minor things on the map when an outside perspective might make you want to rework that stuff anyway? Is it better to get feedback earlier or later in the process for you? And how much testing is adequate—is it practical to test every route on a map on all three major difficulties with multiple source ports, for example? Where do you draw the line? 

Share this post


Link to post

I construct my maps empty and test them over and over again, finding as many problems as I can and fixing them. I also try to find potential shortcuts through them so I can close them off (or, if they're difficult/clever enough, leave them). Once I'm satisfied with my debugging efforts, I add the monsters (before balancing difficulties) and make sure I can do it from pistol start. After that, I implement the difficulties and ship it out as an "alpha" stage.

 

Debugging is, of course, good, but when you start repairing little things that can be fixed at the same time as larger things noted by playtesters, it's probably time to drop its first version to make the process a little faster.

 

For testing, I try to test all the potential routes I'm given (I try for nonlinear, so these tend to be plentiful) to see how the game might play in a specific way, but nothing beats an outside perspective on this. "If you go right, you can miss the rocket launcher and run straight into that mastermind room with only the single shotgun and chaingun." Things like that.

I try to test on multiple ports, but since I map for GZDoom, the only one I'm really aiming at for compatibility is GZDoom. My (few) Boom maps are always tested in GLBoom to make sure that I haven't broken something or otherwise made it unplayable.

 

Where do I draw the line? Depends on a great many variables.

Community projects: built with the player in mind entirely, so if others find something wrong with a given map, I immediately repair/change it.

Requests: I could do these, and these of course would be tailored to the one who requested the map. Same thing applies to gift maps.

My mods: tailored to me, primarily. I like mazes, platforming, and traps, so these get used more prolifically than in the other categories. I'm unlikely to change the map structure much, though combat will likely get tweaked somewhat, and scripted events (like cutscenes), while uncommon, will almost always be skippable.

 

That's how I determine a map ready for playtesting.

Share this post


Link to post
Posted (edited)

When I test a beta, I accept a possibility of certain things being broken, and I don't take offense that the mapper didn't labor infinitely long to reduce the likelihood of that to zero. Stuff slips through, it happens, and I won't be too upset about that as long as the mapper gives an honest effort. Otherwise I should be waiting for the map to hit idgames. So don't feel guilty about that.  

 

About when a map is ready for public posting of some sort: at a certain point, 1) my feedback as a tester becomes a lot more effective at spotting and diagnosing flaws than your continued inspections, because the major or obvious problems have been addressed and your familiarity has inured you to most of the minor and non-obvious ones,  2) you are pretty happy with the map, and you think it's good*, 3) you are also confident that the map is close enough to being a finished product that you wouldn't mind a beta tester playing only this version, but not replaying the finished version, because you expect only minor improvements, and nothing that radically changes the 'proper experience' (that might end up happening, but the point is you are quite confident it won't).


My experience from having done it a lot is that endlessly tweaking stuff has rapidly diminishing returns, and it's usually not the best way to spend time. If you are still not satisfied with the map (the above criteria aren't met), it's better to put it aside for a week or more, not think about it, and get some critical distance. A fresh perspective makes it much easier to judge the map objectively as a whole, and revision afterwards will be a lot more efficient (desirable larger-scale changes, like cuts or overhauls, will jump out at you). Endlessly tweaking stuff can be good when you are actually having fun doing so, when you find it stimulating. The Rule of Fun should win out, regardless of efficiency. 

 

 

*Alternatively, you don't think it's good, or it's not even finished, but you are confident that you are done with it, and you think it might be interesting to a specific set of people for a specific set of reasons. You caveat this clearly in the OP, so that it's unlikely to waste the time of people who aren't in that set, and all is good.

Share this post


Link to post

Until I find no bugs or I get tired of working on a nearly finished level. (played the whole level -> found 2 bugs -> fix them -> don't play it again and assume level is ready).

 

It also helps a bit let people play the level before it goes public, which is what I've been doing (and hopefully it will work better this time). For now, I think the cycle I'm trying is: Solo testing -> Private beta testing -> Public beta testing -> Stable release -> /idgames. The earlier the phase, the bigger the changes I'm allowed to do, so I don't end into a endless product.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×