I received this followup on another forum... I wrote what I thought was a informative reply. I thought it might be useful here, as it gives insight as to how I came about developing this map. I'd be interested to hear how other developers work through the actual play testing of their maps...
"Duke:hazzard" said:
I like your concepts behind it but people never take the time for tactics in Hl2:DM maps. Also the crossbow(sniper) is crap and no one camps with it.
I have my own public HL2DM server... moto-games.squick.net
http://www.moike.net/hl2-maps/motd.html
So I actually get to do lots of testing with my development maps on a live crowd. Not just "Gee, this is a good idea... I hope it works." closed loop environment in SDK.
That's why there's a .357 in the tower, and not a crossbow. Players use the tower once they figure out how to get up in it. It gets camped often, and the crates that make up the floor do come into play. It's also how the idea for the switch that breaks the glass out of the trapdoor control room window made it into the tower. That came directly from a random player in the middle of a game. Literally, "Man I wish there was a..."
But how do I test? This is the development process I created along the way when I started working on dm_playground. Since I have worked in the technical QA industry in the past, I have experience with creating a good development workflow system.
I save off the first playable beta version of a map at a number and a letter. 1A for example... I load it up on the server, play it heavy rotation for a couple days, getting feedback and making observations during game play. I always make sure to be in the game when the map is in play on the server and there are clients active. I take actual pen to paper notes the whole time. I then go back and reconfigure the map in Hammer based on my notes and memory. I then do a fast recompile and save that build as the next in sequence, 1B. This new version gets stuck on the server for another couple days or more of live game play, feedback, and testing... with more notes written up.
Lather, Rinse, Repeat?
Since I .bz2 my maps, and have a very fast dedicated offsite map server, players generally are not impacted a great deal by being required to download updated builds of my beta map every couple days.
This usually goes on for weeks. A through Z. So my map gets crafted around how the players use it, and the feedback I get directly from the players on the public server active in the game. Once I have gone through 26 major revisions of the map, I do a normal/normal full compile and update the readme.txt file included with the zip of the .bsp to highlight the major revisions in this new beta release. I then publish a public 'beta' on the forums for feedback from 'real' map designers, dm_plastic_beta_1 for example. That feedback is then processed and incorporated into the next major first revision of the map, 2A for example. 26 more cycles, then dm_plastic_beta_2 is published.
I don't know how many map developers actually get to that level of interaction with their beta testing. I have not seen any other real write up of how the veterans develop their maps. Maybe they just know what 'works' based on all the maps they've played.
Anybody who plays dm_plastic more than twice who isn't a totally green to hl2dm starts to develop tactics instead of charging around the map. Those who just charge around the map die quite a bit very quickly. They tend to get frustrated and leave.
Probably to go find a nice Killbox to run around in. Good for them, that?s just fine.
-Mike-
-Mike- is: Biker ~ Slacker ~ Iconoclast ~ Eclectic Thinker
MoikeNET ~
www.moike.net - Bad Cat Racing ~
www.badcatracing.com
