Mapping!

One issue I keep running into time and time again with the production of this game is my inability to produce quality art resources. It's unfortunate -- and due to the nature of the game, I am hesitant to ask for assistance in this regard. Perhaps later, when I have enough put together to actually post a download and really release it into the wild.

Been pondering how I want to handle the map. Currently, I'm using a section of the mall from Dead Rising, extracted from the game itself. The mesh isn't ideal for my purposes, though, for a couple of reasons -- though the layout is pretty spot-on to what I'd like to do. There doesn't appear to be any pre-generated collision meshes or anything, nor am I certain how the game handles NPC navigation.



For the uninitiated, a collision mesh is a 3d model that determines how an object collides with other objects. Generally, this mesh is simpler than the object it represents, to make the process of collision detection (and in this case, physics simulation) simpler, and faster to execute. Case in point: This is a screenshot of a section of railing in the mall, currently.

I've rendered it out with a wireframe overlay to show how the mesh representing the railing is structured. It should be noted that the entire railing for the whole level is in two objects -- one for the main body of the railing, and one for the bar along the top. This means that any object on the second floor of the mall will be calculated as a potential collision with the rail during broadphase collision detection. After that, every face of the entire rail must be checked for collision with every object on the second floor. There are two ways to simplify (and thus speed up) this collision detection:

1. We split the mesh into multiple parts, increasing the number of objects considered during broadphase (which may lead to broadphase pollution -- which is the notion that too many objects in the scene slow down broadphase collision detection), but reduces the number of faces to be considered for collision, as we are limiting the size of collision pairs determined during broadphase.
2. Alternatively, we could simplify the mesh used to calculate collision. In this railing example, it is unlikely we need to perform collision detection as precise as the actual topology of the mesh -- the majority of objects colliding with it will not be small enough to fit between the rails, I would expect. Thus, we could simplify each segment of the railing into four vertices and four faces -- a two-sided plane.
   
   • If we kept the entire railing as a single collision mesh, we wouldn't be introducing new entities to broadphase detection, but would still potentially have a lot of false positives in this phase. However, the resultant calculation to fine tune the collision would be faster, as there would be far fewer faces to consider.
   • If we both split the mesh into pieces and simplified it to as few faces as possible, our fine detection phase would be as fast as can be -- we would be considering the smallest set of faces for collision. However, we run the risk of broadphase pollution, as we are increasing the number of objects to consider.

In practice, I'll need to experiment with whether or not to split and simplify, or only simplify to see which operates faster. It is helpful that our physics solver is threadsafe -- I've currently got it set to start up a thread for each core on the processor. I may tweak it to run one fewer, and have them run on the non-primary core (assuming that the main game thread is running on the primary). In the future, I may also tweak it to run on 2 less than the number of cores present (minimum 1, of course), to free up one core for game logic/AI calculations. We'll see!

On the subject of the map, I am wavering in my dedication to using Willamette Mall. The mesh itself will need a good bit of work to make it ready -- and I wonder if I can't just model something up from scratch. I've got good resources for textures and some clutter objects, and I can set them up correctly from the get-go. It's also spawned another idea I'd like to implement: Random layouts.
In the past, I've considered how I would lay out a mall for this game, and I've turned to a board game, Zombies!!!, for inspiration. Particularly, there is an expansion for it called 'Mall Walkers.' The general concept behind Zombies!!! is that you are a survivor in a zombie apocalypse -- the layout of the town is determined at random, from selecting a tile out of a pile of them and placing it down. The road layouts must be 'valid' -- IE, you cannot have an edge of a tile with a street up against an edge of another tile without one.

Mall Walkers is similar, except that it is in a mall. The tiles are corridors and stores, you see. And the concept would lend itself well to a game -- model out shops and corridors, and have them randomly oriented about when a new game is created. I'm likely to be modeling out the stores and things individually anyway, to encapsulate them from the main level layout. Right now, the whole mall is in one big file, and it is kinda messy.

It would mean making navigation and events a bit more complicated, though. It is worth some thought, I think!