I update the shield code to match the new style. The old style of shield just absorbed a fixed percentage of damage. The new style, takes damage points till it goes down, then doesn't begin recharging until it doesn't take any hits for a second or two. After adding shields to some enemies, this has a nice tradeoff of wanting to finish off an enemy whose shield is down vs waiting for your shield to go back up.
Technical update :
I added a mini-map the lower-left portion of the screen the other day. I implemented it by deriving a new Frame class called MapFrame, that sets up its camera above the player pointing down. I then skip geometry chunks with non-walkable materials, then draw the remaining ones in the top-down camera frustum.
Works great, and runs fast. It was interesting in that the map didn't look right from so far above. For instance, the brick textures didn't look like brick from so far up - so I added a texture scaling parameter to adjust the map texture coordinates when drawing into the map. This way the bricks show up nicely.
Next was to add a fog-of-war type effect so the player couldn't see too far ahead, and also give the player an indiciation of unexplored areas.
It's not obvious how to do this in the best way, as we don't have a tile-based or 2d world - it's a full 3d environment. I thought of a relatively simple method and coded it up this morning but it's not practical :
I already have a navgrid, which consists of points above walkable floors that the AI uses for A Star navigation. So, what I did was to find the player's nearest navgrid location, then record this location as visited by storing it in a set.
Next, for each navgrid point near the player, see if it has been visited by the player, and if so, render a quad with a circular falloff texture to navmap's dest alpha.
Finally, blend in the nearby geometry with dest alpha showing only the nearby areas.
This solution works great, but was way too slow, due to the large amount of overdraw involved. For a 10x10 area of nav points, I ended up drawing 100 largish circles to dest alpha - so it's a function of the overdraw.
Another idea with potential is to just mark up the navgrid itself by starting at the navgrid spot nearest the player, then walking in a 25x25 grid around him, and increasing a 'visitation' value from 0.0 to 1.0 based on distance to the player.
Then each frame, go through the navgrid, and construct a mesh from the grid locations, and use the visitation amount as the color for the mesh vertices.
Then draw this to dest alpha instead of the large circles. This will take a bit more CPU, but will have no overdraw.
A weakness with this idea is that it won't always make walls or other features show up that are not part of the navgrid. To improve this, I could StretchRect the dest alpha offscreen to a smaller buffer, then back up to blur it somewhat before compositing the rest of the map on top.
Come to think of it, that might be the whole solution - use what I'm doing now, only reduce the circle radius from 25 meters to 2 meters to vastly reduce the overdraw, copy it offscreen to a smaller rect, then back to get the larger visibiliy radius...
