Preface

This is not a killbox, nor is it like anything else out there really... Players either love it, or can't stand it. All I can say is it deserves much more than just a quick load up and two minute walk around in single player mode... You really have to play this map with several (good) people to appreciate just how fun and strategic it's gameplay is.

Thanks,
-Mike-

###

Map: dm_plastic_beta_5
Map Type: deathmatch
Rel: In a few months
Author: Mike Jones - [EM] Moike_the_Squid
Email: moike@squick.net
Spawns: Several
Size: BSP 9.44 megs ~ Compressed ZIP 4.0 megs

###

- Screenshots:
http://moike.net/dm_plastic_beta_5

- Download ~ 4.0 megs
http://moike.net/dm_plastic_beta_5/...stic_beta_5.zip

- EFNet #Motorcycles Server with the map in rotation
66.127.103.165 / moto-games.squick.net

Since this map is in the beta stages, Feedback is Greatly Appreciated...

### 01/04/2006

<<< See screenshots at http://moike.net/dm_plastic_beta_5 for the major updates. Most of the big updates are improved gameplay. >>>

- The logic systems have been fully debugged at this point, I can't find anything else wrong with them. I'm sure someone will.

- There are two new teleport systems that seem to work gangbusters for getting player flow around the map interacting better.

- Weapons and health/batteries have been either removed or relocated as I saw fit to improve flow as well. I made some major physical changes to the overall map to clean things up a bit and add some new gameplay features.

- The sniper tower now has a switch that will bust the glass window out of the trapdoor control room for 15 seconds. After this the window pops back in place and the switch in the sniper tower locks out for two minutes before it can be used again. The status of the switch is indicated by a green/red lamp. A map-wide alarm sounds when the glass breaks, and the four lights on the killing floor switch to red for the 15 seconds that the glass window is broken out.

- The trapdoor control panel now has a 2.5 second delay on the buttons after the trapdoors reset. This is indicated by a green/red lamp. This prevents a n00b getting up in the control booth and just hammering the buttons and racking up trapdoor capture kills. Now the trapdoors take some timing and skill to use, not just blind luck.

- Successful trapdoor capture kills are now accompanied by a map-wide award alarm, and the four four lights on the killing floor switch to green for 7 seconds.

- The tram system is greatly improved, it doesn't kill you 1 out of 10 times anymore. Call button response time is about 75% faster now.

- Overall FPS improvements, lots of eye candy, some texture work, lots of player clips added to smooth things out.

- Semi-protected spawn points now. This was the biggest complaint about the last beta, My spawns were out in the open.

- Soundscapes installed, server sound bugs finally sorted with ambient_generic entities.

<<< Things to do >>>

- Lots of square rooms/corners and blocky surfaces still yet to be dressed with func_detail or displacements.

- All the lighting prop_staics need to be installed.

- All the ropes and cabling needs to be installed.

- Textures and decals/overlays still need quite a bit of work.

- Major bug with being able to see part way into the pipe room through the perimeter fence from the upper corner of the glass killing floor. You can also see part way into the tunnels leading to the pipe room from up in the sniper tower. This one has me stumped, I know it has something to do with the skybox texture being semi-transparent, and those parts of the map being close, and within line of sight. Hey... that's why the map is beta.

Any feedback on how to fix the visibility problem would be great. I've looked around quite a bit, and tried my own experiments and methods of cheating, and everything short of extending my 'open' map area to include the top surfaces of those brushes. I'm trying to avoid that since I want to keep the biggest 'room' of my map as small as possible for performance overhead reasons.

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...

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-

Sorry Orph, I just caught on from reading some other posts that you're relegated to 56k. It all makes sense now. I'll make an effort to fire up PS and strip my screenshots down as much as possible without making them look like total garbage...

As far as downloading my levels go, I'd say don't bother at this point. This is only my second map, and I'm not graphic designer by any means. I'm a server/network/logic guy. Don't expect much in the way of architectural wonderment and amazing design from me any time soon.

When I come up with something I think might be worth feedback, say five or six maps down the road... I'll get an address from you and FedEx you a CD-ROM.

-Mike-