hmm, I hadn't even thought about the refraction aspect of this. (The java applet you posted demonstrates refraction.) That's usually, as I'm guessing modman was getting at, only noticeable when you are viewing from much closer in that you would usually be in an RTS game. When much larger masses of water have uneven surfaces (larger waves) it's viscosity isn't usually enough to keep it together and it mixes with the air becoming opaque (white). Still, I like the idea for realism and I think that it would indeed be noticeable.
So this leaves the topic of refraction in OpenGL for me to research
Also, I'm starting to think along the lines of optional 3d waves. The biggest reason is because I would rather the environment respond to violence as appropriately as possible. It may also be nice to have a weather system (discussed several times before) that actually dictates how safe it is for ships to set sail. By implementing a dynamic water (in 3d), that makes waves possible that make ships bob up & down and such.
So moving to steep surfaces, along with the new tileset (also called "Animated Tileset") we're working out the plans for a new map format. As is always customary, older map formats will always be supported (just like the original version 1 glest model formats are still supported). Mixing of old maps and new tilesets or visa-versa should be supported as well. In some cases, there may be a few "fudge" rules as to how this is done, but that's OK. But you made me think about in broader terms, so thanks titi!
Before I cover graphics, I wanted to touch on game rules. You were mentioning these steep surfaces being non-traversable. An OO programmer would often want to include the possibility that maybe some objects (units) can traverse them, but other can't and each object would be able to override their traversability behavior such that the game engine could ask the unit if it can traverse a particular slope by calling a function and passing the angle, e.g. "bool Unit::canTraverse(float angle);". However, when maps have a non-traversable element, it's usually critical to the function of the map. Having some units be able to traverse a terrain when the map designer had not intended it can ruin it entirely, especially when a separate mod can redefine such behavior.
As I've mentioned before in the 0.3 planning, I'm in favor of being able to dictate more in-depth rules about terrain traversability, e.g., maxIncline is the max angle the unit can travel up, maxDecline the max down and then speed modifiers for each. Most people don't know this, but bears can run faster uphill than downhill (so if you have to flee a bear, head for the decline!) I'm also intending to incude a "max hurdle" type of settings. If I run into an area where the ground becomes too steep for me to climb... for about 6 inches, that obviously shouldn't stop a human. But if a human encounters a 90 degree incline that's 5 feet tall, they should be balked short of some type of "scale wall" skill. But to a giant, this just might be a large step. And to a lion, a tall jump.
So this is the system I'm in favor of, but I also figure general rules of sensibility should be followed. If somebody wants to make a tech tree mod that defines a unit that can leap 50 feet up and traverse anything, more power to them. If they want to define one where everybody moves like that, they're probably going to loose a lot of the "Strategy" part of "Real Time Strategy". Thus, I say we setup the new map system without any inherently impassible barriers (defined by landscape), but that we do come up with some generally acceptable limit where we expect no "normal" ground units could traverse (like a 6 foot, 45 degree incline). Trees, dead trees and big trees is another topic
So moving on to graphics, I'm thinking along the lines of being able to define multiple levels of steepness, having various textures mappable to them. As you know, the steeper an incline, the less vegetation that grows on it because it just can't get a foothold. As I've discussed in the "new map format" thread, I would like to have the new map format define layers down to some depth (probably equivalent the width of 32 cells or depth defined by the map arbitrarily). Each layer should have a label like sand, sandstone, granite, limestone, bassalt-black, bassalt-grey, dirt-black, etc., and finally water (which will be our special case). Except for water, each layer will have a barren texture (for when the layer is exposed recently, like from digging a trench or an explosion) and a grassy texture (to the extent it can grow grass -- sand doesn't tend to for instance) and it will have a pair of these for maybe 3 different slope magnitudes, zero to 45 degrees, 45-70, and 70-90. Of course, it's note likely that dirt, for instance will ever acquire vegetation at a 90 degree angle, it tends to not be a 90 degree angle after a few good rains, and you'll never get sand to do it! Either way, this will be close enough.
I haven't mentioned many short cuts here, but however we do it, I want it to have the most possibility while keeping the minimal requirements for implementing as simple as possible. Thus, a tileset could just define the current tile types and the engine should make do with it. But when everything is present in both the map & tileset, it can render beautiful scenery that also functions well in game play. Please don't misunderstand me, I'm not trying to make it over-complicated, I just want it to be
capable using a high degree of sophistication to produce a realistic landscape. I have *no* plans on supporting seismic activity of any kind (i.e., movements within these layers) since this isn't a geological simulation engine (just like it isn't a global climate simulator). I do plan on implementing some mechanism in the near future to make minor alterations to the map by, mostly digging trenches, building moats and removing mass due to explosions.
In the distant future, I have some vague ideas for support of more sophisticated movement of land mass (instead of simple removal) if I end up implementing simulation game support (like simcity, lincity, micropolis types of games).
I also have some vague plans for a dynamic water flow support whereby the map designer specifies water inlets and outlets and the engine flows the water, thus causing currents that effect units who traverse it. This would add a lot of things that could complicate map design, but also add a lot of new possibilities. Each map would have to be tested for how it managed precipitation because that would effect water levels everywhere and it would have to drain off or it would form new lakes. But the cool part would be the strategy element of being able to alter water conditions to flood out your opponent. -- keep in mind this is a just a distant future idea at this point.
Pretty pictures:
