Welcome!

The current map in development is Concrete Bayou 01 - The Office Park.

The current version is Beta 1.0 - Download

Monday, May 11, 2009

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!

Sunday, May 10, 2009

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.

Monday, May 4, 2009

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.

About Me

My photo
Nick Woll grew up in the Florida Keys, and is furthering himself in the fields of writing, software development, and web design. You can contact him at nwoll27 at gmail dot com.