That sounds cool erandur!
As wciow mentioned, it does take C++ moding. However, I was examining adding additional "fields" to the game as I'm currently working on a Glest engine mod to facilitate the mod that wciow and I are working on. Although I haven't delved too deeply in this part yet, it brings about a few thoughts that I think are worth considering. But let me back up a bit before going there.
As best as I understand it thus far, when the engine reads in and digests a map, it creates a 3 dimensional array of map "cells". These are essentially the tiles on an x,y grid with the z axis being the field. Each cell can contain one unit (or part of a unit in the case of larger units). So currently, if you have a 64x64 tile map, this 3d cell array is 64x64x2. This is how a land unit and air unit are able to occupy the same tile. However, each "cell" in this array (actually a C pointer) can be available or not (point to an actual Cell object or NULL). The engine determines if a tile should have a land cell or not based upon it's altitude above or below the water line (I can't remember the value below the water line that is allowed before the tile is no longer considered land).
What this brings to mind for me is, how should this be managed in relation to allowing water and land units to occupy each tile. Working within the existing paradigm it would make sense to say that if a tile is too deep to walk on than it should be deep enough to swim/float on, except that I don't like that. A Swamp boat works plenty fine in very deep water and very shallow water, but is pretty crappy on dry land. A canoe can be used in very shallow water as well, plenty shallow enough to walk through. However, a large sea vessel cannot come near the depth that one could walk in, requiring canoes, a pier or a doc in order to load and unload passengers.
This analysis may be too exhaustive for the purpose of Glest, but I think that it would be cooler to have units define parameters as to how they travel in relationship to water. Then, if a simple enough XML interface can feed that, it'll keep it simple where it should be simple, but also flexible where it's needed. My idea here would be to implement altitude-to-speed requirements. So a human unit can travel at speed 200, from 0 sea level to infinity altitude. Can travel at 150 from -1 to 0, 100 from -1 to -2 and then he just can't go below -2. A canoe can go 200 speed from -infinity to -0.5 altitude (the inverse of depth). But since Mr Goliath is significantly taller than a human, he can go 200 speed from -1 to infinity altitude, 150 from -4 to -1, 100 from -8 to -4 and maybe he can't go any deeper than that. My catapult/wagon/Toyota Carola however, cannot go in the water at all or it'll get stuck.
What's your thoughts on that, too complex or a cool idea? The implementation time is probably not too different, rather we say that water is everything x depth and below and land starts at x depth and above. Another aspect of this is that I intend to implement the ability to travel though areas with trees for our druid-ish, tree hugger types. It won't be easy to implement this as a "field" and it probably wouldn't make much sense, so I'm going to need to put together some alternate mechanism anyway.
