Monday, September 29, 2008

New Level Concept, MAD: Mutual Assured Destruction

I've been wanting to make a TC (Total Conversion) level for a while now, since I am more familiar with Unreal. I will probably be unable to contribute custom characters or guns, due to time restraints. I really want to focus on art AND gameplay in this new level, to show that I am competent in both modeling and level design. I am indeed an artist, though, and enjoy more of the lighting, modeling, texturing, and asset placement as opposed to scripting and white boxing levels (although I feel proficient in these, too). I am focusing my new level on a single-player style level for Unreal 3 and already have some simple AI systems that I've been working on to contribute. My major predicted obstacle is changing the core game mechanics: player ground speed, jump height, and ability to dodge. I have been researching mutators and have tried created a simple one to control these parameters, but to no avail. If all else fails, I will cater the level so that it works with both Unreal mechanics or any other.

Here is my concept:
-Based off the first Metal Gear Solid and ambiance of the Bourne Trilogy movies
-Player has to infiltrate a nuclear warhead/biological weaponry facility (not the most original, but I am planning on creating a fresh spin to the atmosphere and gameplay)
-There will probably be only a couple of guns -- stealth being the primary objective -- so a pistol with a silencer should suffice (again, this may have to change do to skill restrictions at the moment)

I am anticipating this level to take roughly 7 weeks to finish and will update any progress once I start production.

Thursday, September 18, 2008

Level Finished

I officially finished the level on 9/16 and have uploaded it to my website and FileFront.com under the name DM-FeatureCreep. I also heard back from Gamespot and my first level, Ebb, is now on the site (Feature Creep Download).

Tuesday, September 16, 2008

Note to Self

I've noticed that map sizes significantly decrease in size if lightmapping was occupying a large portion of that size. My first try was a level that went from 68.9MB (uncooked) to 45.5MB(cooked). In the newest revision I decided to be more liberal with the lightmap sizes, and got a map that was originally 77.5MB(uncooked) to get down to 47.9MB(cooked). If you were wondering about the math behind that, it's:

45.5MB / 68.9MB = .66

47.9MB / 77.5MB = .62

.62 + .66 / 2 = .64

This means that the lightmap size after cooking decreases by roughly 34%. Pretty nifty, indeed. I will definitely be using this formula for my next map to calculate file size :).
I went ahead and cooked my level at my school (thankfully they have Unreal 3). I had decreased the lightmap resolutions all around so that my map was around 70MB... a reasonable number. Whenever I cooked it, the number dropped to a very pleasurable 45MB :)! This got me to go back and scrutinize areas that had discrepancies with lighting (in the form of whitish bands in between 2 side-by-side meshes). Right now I have increased the lightmap resolution of the most important areas, and it seem that a lightmap of 64 and above is recommending for lightmapping -- anything below isn't worth lightmapping, as it makes the mesh look even more screwy than before. I will be recooking the map later today and hopefully it will be released today.

Monday, September 15, 2008

I've finished the version of my rain/city map. I call it DM-FeatureCreep. I've had one friend play test the level near completion and just had another friend play test the final version. He gave me a couple of small things to change and I've gone ahead and changed those. I've been having problems cook the map so I had to use one of those friends' computer to cook it. The only problem is that he is running the game without the version 1.3 patch, and, when I try to play on my computer, the game shuts down for some reason. This may relate to the previous problem of not being able to cook the map, though.

I've also been thinking of a concept of light up shoes. I know there are already shoes such as the pair of L.A. lights that I had when I was a kid, that flashed red when the wearer steps down, but I am thinking of a more adult and futuristic version. When the user steps down, white light turns on in a line until the whole bottom of the shoe is lit. If the wearer stands in one place for a duration of time -- say, 15 seconds -- the light would, to conserve energy, blink in a pre-programmed pattern and then fade out. I was thinking that this would be a cool dynamic to a survival/horror game where everything is usually under lit. Light could be use to harm or scare away monsters, such as vampires, and so that enemies couldn't get too close to the player (unless they stand still too long :) ).
To execute this, I would plan on connecting a dynamic white light to each foot bone and running a test so that the light would only turn on if the foot was flatly colliding with another collision box (this way, if a player where to kick something or jump next to a wall (and there foot happened to brush against it), the shoe would NOT light up. It would light, though, if the player managed to do a running back flip off a wall or while jumping platforms, etc. I will be coming up with a few concept sketches in a later post.

Thursday, August 28, 2008

Past Deadline

Wow! Long time without updating but not long since I've been working: everyday I have been pouring more work into this level. I had set a pretty tight deadline on myself when I started this new project (which I calculated from the amount of time it took to complete the last level). Seeing how this level is exceptionally larger and more detailed, I have already passed the deadline by a week.
Here is a quick overview of what I've accomplished:
8/28 - Started adding sound
8/23 - Scratched the surface of adding pickups. Decided to save for once other areas were complete (I was still adding extra entrances in an out of areas)
8/25 - Found out that lightmaps severly increase file size. Too many unnoticeable meshes were being lightmapped or had too high of a resolution. I decided to limit lightmapping mostly to objects that had lighting hitting them. Objects that had silhouettes cast from other objects have the highest resolution.
8/27 - Added extra side entrances into garage, built a huge cull distance volume that covered the entire map, added post processing
8/28 - Added animated ground fog planes, finalized boundaries (which were kept at unlit BSP for the longest time), found out that when multiple players were added the current car system would only kill the player (not npcs) -- had to fix in Kismet

Current work that needs to be done:
- Find any holes or descrepancies in blocking volumes or static meshes
- Finish refining the interior of the main building, while making it more open all around
- Continue to optimize lightmap resolutions. Current file size = 90MB, desired file size = 50 - 70 MB
- Add pickups and balance player flow
- Finish scripting any additional cool features
- Surround level with kill volumes
- Add rain static mesh
I'll give myself another week to finish. For now, here are some screens of my current progress:








Thursday, August 21, 2008

Level Update

I've been experimenting lately with lightmapping meshes. By default, Unreal has every static mesh defaulted to override to a lightmap resolution of zero -- which isn't good for shadows cast by other meshes. I've been trying to push the lightmap value at a pretty high amount (usually 128-256 for each mesh), and leave meshes that are farther away or not seen by the player with no lightmapping. A good rule of thumb I've developed is to use a higher resolution on horizontal surfaces that will be walked on by the player and have more shadows and lights hitting them overall. For vertical surfaces, such as walls, I try to use a lower lightmap value (the exception to this is if there is a hanging wall light that is casting a dominant shadow).
Another fun aspect I've begun today is adding sound. I actually knew very little about sound for my last level, but managed to mix and match different ones in certain areas to get the right feel. Now, I'm more comfortable mixing custom sounds with the sound editor that have a much better result. For instance, I made a randomly generated thunder sound that randomly pairs with another thunder sound -- so there is always two thunder noises at once. This adds a lot more depth and the randomness is for realism. Once I add a new element it always inspires me to add another, so I will most likely have flashing lights to simulate lightning that will be synchronized with each thunder noise.
There was a sound that I've been meaning to add for a while and finally got to it today: the sweep of air and rumbling engine of a passing car. I have observed cars during the rain before, and they make a loud hissing noise from the tire tread quickly spraying water particles everywhere into a fine mist. I wasn't able to do this with a KActor, as there doesn't seem to be anyway to attach a sound to a dynamic object and have it movable. For this, the interp Actor, a.k.a "Mover" was perfect. The player now has a sound clue as to when a car is coming down the road and won't feel as cheated when one hits them from behind. I am also thinking of adding a trigger to honk at the player while they are in the street. Now I have to focus on adding a little more light to spice things up in darker areas, fill any gaps I probably have overlooked with static mesh, add decals for variation on larger surfaces, and add small amount of particle emitters (in which I presently have the least knowledge of).
I have marked item pickups with notes and am not too concerned with them at the moment. I have a pretty clear idea in my head where each will work best, and as the level has been changing gradually as I began to add more detail, logically it would be best to hold off on any placements at this time. Player flow and aesthetics are my main focuses at the moment. The level should be done in a week from now :).