I’m seeking advice concerning approaches to terrain representation and mapping far a wargame application.

I’m at the beginning design stages of what is, in effect, a real-time strategy game that realistically depicts ground warfare at the entity (i.e., individual vehicles and soldiers) scale. At present, I intend to create a strictly 2D simulation played entirely from a 2D overhead map view of the battlefield (specifically, a topographical map, with 2D military symbology superimposed). I also intend to create the application using Qt/C++ and the QT Creator IDE. I consider myself to be an intermediate-level C++ programmer. This project, while obviously complex, is just a non-commercial, open-ended labor of love with which I intend to keep myself busy with interesting sub-projects and to experiment with AI later on down the road .

The basic parameters are as follows.

> Windows desktop app (only)

> Simulation to run in pause-able real-time or accelerated real-time.

> Terrain representation consists of digital terrain elevation data, plus “overlay” data containing things like vegetation coverage and waterways, man-made objects like roads, buildings, minefields, etc.

> Efficient LOS, pathfinding, and tactical planning are essential (that statement is probably mostly superfluous in the FPS/RTS/wargaming context).

> As far as rough order of magnitude, a given mission might feature as many as 200 vehicles and several hundred individual soldiers and the high end, with typical missions containing half or less of that.

> Not an MMORPG, but 100 participants on all sides should be at least theoretically possible, with 4 to 25 being the most common number of participants.

> Presently, I have neither the intention nor the desire to create a 3D simulation. To the extent I can get the necessary infrastructure to do so at little or no cost (either my development time or runtime performance) at some point in the future, however, I suppose it makes sense.

I’d like to find an open-source mapping library that I can integrate with a minimum of fuss. Ideally, a library that can (1) read and write digital terrain elevation data files; (2) generate contour map images; (3) determine the slope of terrain at any point on the terrain surface; and (4) perform line-of-sight calculations.

I’ve done some preliminary digging, but am a bit bewildered at this point, being a complete neophyte when it comes to geospatial information systems. For example, I know there are 3D frameworks like Unity3D, Delta3D and Ogre3D, but it seems like there would be a significant effort to master these systems in order to use just a small segment of their functionality. I’ve read a little about ArcGIS, but it also seems like a heavy-duty solution to a simpler problem.

Can anyone advise?

Have you looked at http://www.gdal.org?

Have you looked at http://www.gdal.org?

Thanks, Interesting to see that, according to the website, ESRI uses GDAL. Some further googling, though, indicates that GDAL does not itself have a line-of-sight checking capability. I shudder at the thought of having to do that myself.

I sometimes use GDAL or its related projects for my job. I have not done it myself but as long as you can work in a metric projection, like UTM (which should be doable even on the fly by GDAL without significant accuracy problems provided your area is not significantly moving outside the UTM zone) you just need to sample the height values on a line from your source to your target.
Now, reading that line in an efficient and fast way could be a bit of a pickle (especially if you allow arbitrary input file formats since there are significant differences in how data is stored and which access pattern are performant), but simply getting a result should not be too hard.

I sometimes use GDAL or its related projects for my job. I have not done it myself but as long as you can work in a metric projection, like UTM (which should be doable even on the fly by GDAL without significant accuracy problems provided your area is not significantly moving outside the UTM zone) you just need to sample the height values on a line from your source to your target.
Now, reading that line in an efficient and fast way could be a bit of a pickle (especially if you allow arbitrary input file formats since there are significant differences in how data is stored and which access pattern are performant), but simply getting a result should not be too hard.

Yes, I am going to use UTM or a related local coordinate system. I spent some time looking closer at ESRI. It has a lot of nice built-in capabilities, but I'm a bit concerned about how closely my code would become coupled to ESRI. After some thought (and Googling), I think for the time being I will stick with simple heightmaps and use Bresenham's algorithm, along with height-checking, to calculate LOS. It should be a reasonable-enough approximation for my purposes, although I am worried about performance. Especially as I would like to use 1-meter terrain resolution