A Bad Mapper's Bad Map Design - A Visual Companion, Part 1

It's no secret that I'm no good at this.

I mean sure, I understand gameplay mechanics and level design, I understand lighting techniques and balance, but let's be honest here.

I have no idea what I'm doing.

That being said, I'd like to bring up a few (too many) issues with Beta 1.0 of my current map, The Office Park. Illustrations are included, so there's no excuse for not catching these kinds of things in your own maps!

How (not) to map, in order of appearance:


1. Make quality lights. Lighting is important. Like, really important. So don't go cheap on your lighting, even if it means making a prefab and using the same lights over and over again; nicely lit areas are always better than badly lit areas (not to be confused with poorly lit areas, which are spooky. Remember, spooky = good). Unlike the example set by ME in the STARTING SAFE ROOM, use glow sprites and dust motes to make your lights really shine. Using the right model and light color help, too (at least I did something right).


2. Put important item spawns in obvious places. When places aren't obvious, make them obvious. This means putting objects along paths players MUST take, or at least are very likely to take (an exception to this is very powerful items, such as pipe bombs, molotovs, and health kits. Exploration should be rewarded). This also means drawing attention to an item by placing it in a prominent location in a room. Prominent locations do not include empty tables with no interesting features.


3. Good mappers will never leave a large area completely empty. Where there are no gameplay elements to contribute, there should at least be SOME kind of detail to separate one area from the next. This is especially true for explorable areas that have no purpose. And look at those lights! Haven't you read the title of this post by now?


4. Mappers should be careful that they don't extend their brushes too far, unless the resulting clipping is completely hidden. Avoiding clipping entirely is generally a best-practice, just to be on the safe side.


5. Under-extending a brush can be more noticeable, though.


6. Just connect the brushes. It's really not that hard.


7. But of course, even if a real mapper made any of these mistakes, at least the brushes would be textured properly. Right?



That's all of the mental anguish I can inflict on myself this time; the rest of the map's follies are soon to come!

The Office Park - Beta 0.5 to 1.0 Changelog

A lot of work has been done to The Office Park since the original release, and a lot of changes have been made to the original design documents (some of which will not be seen for another release or two). This isn't a bad thing, but testament to development as a process. From inception, we gain experience, learn, adapt, and - hopefully - succeed.

Inadequate record keeping means that a more explicit changelog is impossible, but I have made an effort to glaze over some of the more notable changes in this post.

Changes from Beta 0.5 to Beta 1.0 are as follows.

Gameplay:
-Entire courtyard reworked.
-Weapon spawns adjusted.
-Additional vents added inside administration building.
-More decals, overlays, and props added for detail.
-Locked two rooms in administration building.
-Removed unfinished alternate route on ground level leading outside the office park.
-Removed exit to balcony from starting location - players can still look out to the courtyard via peephole.
-Extra door added in administration building between rooms.

Technical:
-Lighting adjusted in numerous areas.
-Cieling light textures that were previously lit when off were fixed.
-A number of textures were adjusted.
-Changed a number of prop_static entities to prop_physics entities.
-Changed some func_details to world geometry.
-Changed some world geometry to func_details.
-Adjusted func_viscluster in courtyard
-Navmesh edited for greater functionality. OBSCURED marks used more liberally and open areas were weeded of excess navigation squares.

The Office Park BETA 1.0 - Known Bugs

Tonight marks the release of Beta 1.0 of The Office Park. As mentioned previously, I ran into a number of issues prior to release and missed out on about a week's worth of development time, leaving us with a product not quite as polished as I had hoped.

I was hoping that I wouldn't NEED to release a bug list, but such is my folly. Provided below is a list of known bugs in the current release of Concrete Bayou 01 - The Office Park.

If anyone sees anything that's not on this list, please comment here or otherwise let me know so that I can add it and get to work.

Known Bugs/Issues - Updated 5/10/09
-Purple haze on higher graphics settings (SDK Issue)
-Flourescent lights that are OFF look more like chalkboards than glass, these textures will be replaced.
-Lighting in general still needs some tweaking.
-Security lights near the warehouse portion of the map exhibit incorrect light values.
-Pills and Pistols don't spawn randomly.
-Molotovs and Pipe bombs have not been placed (not a bug, but needs to be addressed).
-Weapon spawns still need work (a new system is in the works, more soon).
-A majority of areas still lack detail.
-No ladders for special infected.
-Some brushes don't line up.
-Many vehicles don't have lights. They don't NEED lights, but I want more of them to have lights.

This Isn't As Easy As It Looks (Sometimes)

Frustration.

I had hoped to have announced a release date by now for Beta 1.0 of The Office Park. While that announcement is still forthcoming (May 10, 2009), it's only an aside to todays post. Here's the issue:

For the last several weeks I have been making some major gameplay changes to The Office Park, some will be seen with this release and some won't be seen until the final release with the campaign (it will all be clear when the time comes). Up until last week, progress had been coming along smoothly and I had been nearing the end of the largest changes. The plan was to finish up the gameplay changes by last Thursday, have a compile for the Beta version by Friday, and then spend Saturday and Sunday generating the nav mesh and enduring all of the related tedium involved in editing all of the fine details by hand for the Nth time. The simple fact that I'm making a post about this should say that something went wrong. I present a timeline:

April 27, Monday - Release date decided for May 10, with early release for SDP Community as soon as the 5th.
April 30, Thursday - Major changes complete and ready to compile. Early tests were favorable, so map was saved as a separate file titled The Office Park Beta, in order to facilitate Beta-specific changes without the need to undo said changes in the final version after release of the Beta. New map compiled overnight.
May 1, Friday - The compile completed. I launch the game client in the twenty minutes before work to quickly run through the map and get the nav generation started, but the map doesn't launch; strange. I close the game and try several more launches before opening the console on one attempt and seeing what looks like memory errors. I attribute the error to a bad compile and set the map to compile again while I head off to work.
Friday Night - The second compile completed with no serious errors, but the map still won't load. I'm not sure what causes this, but it seems to have something to do with renaming the map. A similar issue occured before the previous release of the map where I appended "Demo" to the end of the filename, but in that case I had assumed that something else was at play. I reverted to using the original file and compiled.
May 2, Saturday - This compile seemed to load with no major issues. I found a couple of oversights in my playthrough as well as a number of issues related to the navmesh as was to be expected. Not to be discouraged, I set the navmesh to generate while I went to work.
Saturday Night - My computer crashed (or was shut down, I won't speculate) while I was gone. Annoyed, I set the nav mesh to generate a second time overnight.
May 3, Sunday - I have high hopes this time as I set the navmesh to generate in the morning. Returning home from work around 5PM, I have an earlier start working on the map than usual. I open the game and zoom around with the new nav mesh for a minute before restarting the map for a playtest. This time I recieve some new errors and start right in the center of the map. I quickly realize that there's a problem with the nav mesh - one of the sections that previously worked only did so because the navmesh was broken in that spot (and assumed there was no object where there is now an object that the player must jump over). Not a major issue, since it seemed easy enough to fix by hand, but it destroyed the map flow from starting point to saferoom and needed to be fixed immediately. Toying around with nav area creation didn't help, as the object was rotated out of line with the map's grid, and wasn't treated correctly by the navmesh.

I had plenty of time at this point to perform another compile to fix the issue, which I did, only to find that adding a Clip block over the prop - which was necessary, but must be done precisely - solved the issue of the navmesh finding the object, but further broke the map in that the player could no longer jump over the object.

I ended the night with another compile, which will hopefully fix this issue, and this is where I stand. The problem is that I've lost several days of detail work to a small handful of minor, but very annoying issues, and I've yet to see how the map plays with the changes because of this.

Hopefully my next update will be more exciting.

Walking the Path

In my last post, I discussed the difficulties of developing flow in a game like Left 4 Dead, and the specific challenges I've been facing in the large, open courtyard central to The Office Park. I narrowed my options down to two potential paths, pictured again below.

From Mapping

The first path, aptly-named Path A, seemed the most logical choice to me. Here was a huge open area with a number of dividing structures (the planters), obviously it would be best to have the player explore every nook and cranny of that space, zig-zagging back and forth to get to their destination.

This was fine in theory, but putting it into play brought a number of issues to the foreground. Forcing the player to maneuver back and forth achieved what I wanted, in that you DID see the entire courtyard, but it also had the effect of feeling contrived. No matter what reason I might imply for having to take this route, it was readily apparent that it was all just "designed." This is a real location, at least in the mind of the player, and this is an effect best avoided.

Additionally, all of this walking back and forth made for a lot more work cosmetically. Most players don't mind a long trek - after all, it's just a matter of holding the W key - but nobody wants to stare at the exact same scenery for ten minutes. Populating all of this empty space was, as mentioned in my earlier post, proving to be exceedingly difficult, and my attempts were feeling increasingly forced.

The final issue I didn't notice until calling in a friend for testing. My changes since the release of Beta 0.5 have been tested internally amongst myself and a few others who have been following development since Day 1. When bringing an unversed player into this environment for the first time, Path A often found them wandering off into some non-essential corner of the courtyard. While I do believe that the ability to explore should be encouraged, players should NOT be put into a situation where deviating from the most obvious course will get them lost, and this is what was happening.

That said, I have opted, officially, to develop along Path B, and so far it is working nicely. A number of features have been added to the courtyard (cosmetically) to emphasize this route, and after seeing it all come together I'm beginning to wonder why I needed to take a three month vacation to come up with this in the first place.

The new route will be detailed in a future post, but now I must sleep.

Developing Flow in the Courtyard

One of the most difficult design aspects of developing for a game such as Left 4 Dead is the management of game flow in a realistic environment. In order to truly give the impression of being a part of a zombie apocalypse, we must put the survivors in real, familiar environments: the collapsing remains of the places stored in our collective consciousness. Difficulty arises when we try to give the players meaning and direction in what would be an open environment.

There is a great deal to be said on the subject of immersion and believable barriers in map design, far more than I could pretend to have mastered. Where some games may establish a clear path through the use of tunnels and corridors, we must introduce recognizeable boundaries and obstacles for the players to navigate without ever breaking the sense that everything is all connected to a much bigger world. At no point should the player feel that they are confined to a path as an element of a 'level;' rather, they must be presented a situation where the path in front of them is LOGICAL and intuitive, a path that they themselves would follow. This has been my struggle in The Office Park.

For anyone who's had a chance to play the released beta, you will have quickly noticed that the design of the office park itself is inherently very open ended. This was dealt with largely through the use of destruction as a barrier; structural collapse forces the survivors on a fairly direct route, and while room is left for exploration, players can never stray TOO far from the main path.



The problems arose with the courtyard: a massive, flat, open area with only a few planters to break up the scenery. While some would agree that it made for a rather attractive vista, the fact remained that it was empty. What was more, there was nothing to be done to restrict the player from exploring the space which, while detailed and interesting, proved to be very disorienting, as the various nooks and crannies gave no hint leading towards the next point of progression. Something was needed to give the player a GOAL.

There are a number of common techniques for giving an unwitting player direction, the most commonly cited of which (at least in the Left 4 Dead community) being lighting cues. Players, thrust into an unfamiliar environment, are naturally drawn to familiarity, activity, and detail. A good way to suggest all of this is by the use of lighting to lead players from point to point, and an attempt at this was made by placing a security spotlight in front of the entrance to the administration building. This was met with failure, as the size of the Courtyard prevented players from noticing this light until they had travelled a fairly large distance unaided. It was clear that an alternative was needed, and an alternate courtyard was drawn up.


This time, instead of the true-to-life planter configuration, I settled on a much more obstructive design. By raising the height of the planter walls to block more vision and joining each 'set' of three planters into three very large planters, I was able to create hedge walls to divide the courtyard into several sections. This, combined with a number of obstructions (chiefly made up of police barricades), allowed me to force the player on a specific route to cross the courtyard without sacrificing the feeling of open space or the view from the balconies. While the changes brought a new set of issues (populating all of that space interestingly without overextending the bounds of the engine), it made for a much more controlled feel and had the added bonus of showcasing parts of the map that might have been walked past initially.

There's much more to be said, but I'll leave that for another update. I will soon be testing the playability of the two paths shown below, and will be making a decision on which one to develop further.

Pictured below: Two potential routes through the courtyard, travelled from right to left upon exiting the warehouse. Note, the dark yellow boxes are the new planters, while the light yellow boxes are other obstacles (primarily police barricades).

From Mapping

The Office Park - Known Bugs

I've decided to repost this list from Automated Sweet Talk since it's only appropriate that I plug the Concrete Bayou blog in relation to the Concrete Bayou campaign. This makes me sad, because I like the Automated Sweet Talk blog, despite never accumulating any readers. If you'd like to make me happy, start reading that blog too. Provided below is a current list of known bugs in Concrete Bayou 01 - The Office Park.

If anyone sees anything that's not on this list, please comment here or otherwise let me know so that I can add it and get to work.

Known Bugs/Issues - Updated 4/26/09
-Several displacement surfaces cause NoDraw surfaces to be exposed.
-Displacement edges render incorrectly (seen in several locations, let me know if you see others: ledge outside of first office, room with broken wall dividing offices)
-Purple haze on higher graphics settings (SDK issue, everyone probably knows by now)
-Warehouse crescendo can be skipped *FIXED*
-Vents in administration building DONT spawn zombies *FIXED*
-Some textures for flourescent lights that are OFF are wrong.
-Lighting in general is off. Light sources are missing in places where lighting exists (mainly the admin building).
-Fire doesn't generate light. *FIXED*
-Zombies don't spawn in one of the side rooms on the lower floor. *FIXED*
-Weapon spawns need balancing. *FIXED*
-Ammo piles don't spawn correctly.
-Washing machine boxes blocking the path past the warehouse entrance are clipping into the wall. *FIXED*
-Fire at crescendo event takes up larger area than intended. *FIXED*(No longer considered a bug)