flipcode - Fog Of War In RTS

Fog Of War In RTS
Question submitted by (12 July 1999)


	Oh boy, a place to ask all the pending questions! Well, as quite a lot of other inspired programmers, a friend and I are trying to design/implement our own RTS. Currently we are deep into the design phase, and are recognising several areas, that gives us some problems, as how to implement them the most efficient way. We are both educated in Computer Science, and are aged in the late twenty's, so feel free to be rather technical in your answers. But 'nuff said about us - On to the questions: "Fog-of-war" - We are considering several angles to this, and are currently sticking to have a counter on each tile. The counter keeps track of how many of the players units can see the tile. When a unit moves it increases/decreases the new/old tile's counters. In addition we have a smaller counter, counting how many allies can see the tile (For shared vision). However we wonders if this is the "best" way to do things(?) - Another approach would be a list of units connected to each tile, but we think, that maintaining a list on each tile may be a little CPU-expensive(?) "Movement-cost and unit-speed" - We would like to have some hills in our game, but how we should make it visible, that the unit slows down uphill is not clear to us. If we detect a height difference between the current tile and the next (destination), we can of course slow the unit. But let's say that it's a steep hill with a flat top, then the unit will slowly approach the hill, only to run up the slope (because the top is the same height). Is the solution to have tiles that are stored as slanted in one direction? We would of course still like to be able to move at close-to-normal speed along the side of the hill. "Tiledata" - We are currently working with a model, that stores tile data in an array of 32bit numbers, using a word to store the tile-type (Upperleft corner of dense forest etc.) and the rest to height and fog. However a different approach would be to have a list of pointers to tile-objects (We saw this on the web). This approach has some obvious advantages, but it seems to be rather slow, when you need to access the tile-data for path finding. What approach is most widely used today? Another way of doing thins could be like the Age of Empire way, that seems to store each single tree in the "forest", and thus being able to cut them individually. Well, as you can see we have a lot of possibilities, but not much experience to make the selection, could you please advise? Well, I will try to stop with this, as you most likely has other things to do, than do help would-be game designers to get started. :-)


	>"Fog-of-war" - We are considering several angles to this, and are currently... Yes, that would be expensive and probably unnecessary. This really falls under the category of what kind of thing you want the fog of war to provide. Do you want the fog of war to simple not show parts of the map to the player where they are not currently able to see? This is mostly why it is used, and so would only have three stages. Either the player has never seen it, so it is black. The player has seen it but cant see it now, so it is greyed out, or the player can currently see it, so it is drawn normally. If you dont need anything more than this, than just check to see if any of the players units are currently within a radius of the tile, and then set it. If you do need more than this then you need to determine exactly what you want it to do and work from there. >"Movement-cost and unit-speed" - We would like to have some hills... Well, one way you can do this is to move the units on a coordinate system that is separate from the actual map. Then you can have all the data you need and you only need to reposition them on the map to make it look correct. Since you are not moving them by pixels on the screen, but are instead moving them in their 3d coordinating system, you can use normal vector based physics to place them in your 3d world, then just convert it to your 2d drawing system. This would probably mean chopping off parts of the sprites if they are beyond hills as well. >"Tiledata" - We are currently working with a model, that stores tile data... This is something you will really need to determine for yourselves, since it will determine the look of your game. A simple way to do it however is to use a BYTE or INT for the tile number and have a series of images stored in a large tile map, like a checkerboard. You could then make another map on top of this that determines individual height for the areas and use that for your abstracted movement system. I would suggest that you start out simple and then build on it once you see how it works. Starting out in a complex fashion gives you no experience to experiment with what you like and what you can do. Response provided by Geoff Howland

This article was originally an entry in flipCode's Fountain of Knowledge, an open Question and Answer column that no longer exists.