wowzers! lots to address here. Let me try to start with gameboy. I'm highlighting all of my questions in blue (so please do respond to those).
61) better merging of tiles.
61) please elaborate on what you mean.Now modman, very nice list, thanks! What this sounds like is more of a full-blown map, scenario, campaign editor. I don't have any conflicts with that per-se, just clarifying the scope. I'm in favor of an iterative/multi-phasic development approach on this as opposed waterfall methodology (i.e., attempting to have all of this in the next release). So we can get to project planning later, once we are more clear on what we want.
First, let me elaborate on my current concepts for the new map format, map editor, etc. When I think of the "map" I'm thinking of a very basic set of data that defines landscape, its ground cover and water. I'm generally feeling that every thing else belongs somewhere outside of the core "map data", probably even the start locations! While I'm not solid on this, here's how I'm thinking of it:
- Geology: defines basic parameters for a substance that a portion of a celestial body may consist of and the images for its appearance. Each layer will be defined under defined under ./data/game/geology/<layer_name>/<layer_name>.xml (relative to the project root) and will define the image files (which will be located under./data/game/geology/<layer_name>/images) for surface and eroded surface (probably a collection for variety) as well as some very rudimentary properties like erosion tendencies and tinsel strength (generally to be used only in the map editor when we get around to landscape generation through simulation in the distant future
). We should probably start with some really simple base types and expand upon them later when enough is implemented that it actually matters. Example:
- black_dirt: or maybe we use "dirt_black" with a noun_adjective type of naming convention (isn't that how you say things in Spanish?). As example, this could have the following files
- data/game/geology/black_dirt/black_dirt.xml - the definition file. points to the images below
- data/game/geology/black_dirt/images/black_dirt0a.png - an image for what it normally looks like when bare on a flat (i.e., zero-degree incline) surface
- data/game/geology/black_dirt/images/black_dirt0b.png - a variant of the above
- data/game/geology/black_dirt/images/black_dirt_fresh0a.png - an image for what it looks like when bare on a flat surface when recently exposed (dug up). This wont be useful until we can dig trenches.
- data/game/geology/black_dirt/images/black_dirt70a.png - an image of what it looks like when broken, cut, eroded, etc. at an incline of greater than 70 degrees
- data/game/geology/black_dirt/images/black_dirt70b.png - a variant of the above
This is just an example - brown_dirt
- red_dirt
- sand
- limestone
You may ask why I used the term "celestial body" instead of just saying planet or the Earth. The reason is that somebody may want to write a set of maps, scenarios, faction trees, etc. that takes place on a moon or asteroid. I like to keep possibilities open, especially where it causes no extra work aside from just considering it as possible. This will keep the design as extensible as possible. - Map: roughly specified, the map will define the following:
- Header information: current info plus all the other requests (like modman's items 51-53)
- geological layers -- the substance will be one of those under Geology and the map format will define in some way the shape of each layer. Geological layers really do curl up sometimes, so we can't reliably say that a geological layer for a given cell starts and stops at a specific altitude, so we'll either need a mechanism to specify one or more sets of lower_altitude, upper_altitude or some other mechanism (like defining the shape of a geological layer in terms of it's encapsulating verticies)
- surface/ground cover: this is analogous to the current ability to select a tile (road, grass, barren, etc.) but with a transparency layer to expose the texture of the underlying geological substance.
- water levels: currently, there is a single static water level. See my answer to items 22 & 24 below
- cliffs, gullies, chasms, valleys, etc. (needs it's own discussion)
- caves, tunnels, dugouts, etc. (maybe for a future revision of the map format)
- non-interactive objects (statues, ruins, non-resource stones, etc.): probably each defined as entities. As discussed before, the map format should have a list of objects used in a section after the header and for each object, one or more alternate object names can be specified so that if somebody doesn't have a particular object installed, it can use a replacement.
- player start locations & resources?
At the moment, I think that this is all that should be in the actual map data (obviously open for debate). I put a question mark after start locations & resources because I have some questions about where it's best defined. These two items go hand-in-hand so should be dealt with together. Resource nodes also serve as barriers, a very important part of map design, so start locations & resources may be inseparable from the core map data (i.e., wouldn't make sense to swap them out with a a different meta-data layer) but I'm not 100% certain of this so I would like to leave this concept open for now.
Lastly, I also see a few different avenues for the definition of the non-interactive objects. If we define them in a meta-data layer and we allow multiple meta-data layers to be used at once (each one with the opportunity to override previous definitions) then maybe it makes more sense to store these in a meta-data layer and have each map define a default metadata layer. This could also support putting start locations and resources in the meta-data, but still keep them tied to the map. - Entities: After a lot thought, I'm thinking that we need a separate concept called "entities" that will encapsulate Glestimals (a.k.a., "whats-its"), statues, ruins (all map objects) and even special objects that are not necessarily visible or corporal like quicksand, poisons plants, teleporters, spawn points/regions, spawn traps (or other types of traps), and maybe immutable bridges bridges (non-player built bridges that is, because when we implement player-induced map modifications like building trenches and moats, we'll need to allow units that can be built or created that act as bridges and are destructible -- more on that elsewhere), things like modman's exploding volcano (an invisible entity that resides at the mouth of the volcano), etc. Entities should be scriptable objects based upon built-in types (Glestimal/whats-it,
traptrigger, etc.). Their definitions & media files will probably reside under ./data/game/entities (from the root of the project) and the layout within there should probably be just like everywhere else in the game (units, etc.) with subfolders for each entity and from there, additional subfolders for content (sounds, images, models, etc.). - Map Meta-data: (EDIT: It may make more sense and to just have this be part of scenario data. It would certainly decrease complexity.) I don't particularly like that name, but it's the best I can come up with for now. This should be a swappable superimposed layer that adds to the base map data. From this is where entities are pulled in, placed on the map and (optionally) assigned input parameters. Thus a volcano_eruption entity may take parameters like latency-time, latency-time-var, explosion-radius, explosion-radius-var and damage, a spawn point may take a list of entities it can spawn and their parameters, etc. If we move the player start locations and resources from the core map data, then this is where they would end up. This layer may also describe weather and climate and even expose multiple weather "aspects" or seasons. Thus, the map meta-data may define general weather conditions for winter, spring, summer and fall or you may be able to use this to say that you want to see what this map would look like if it were a jungle. This overlaps the current concept of tilesets, so that will need some thinking.
I also think that it should be possible to combine meta data in layers. Thus, it will also require the capability to remove a previously defined entity. - Scenario: The scenario extends upon all of this, specifying a map, zero or more map meta-data
(possibly allowing alternate meta-data, I'm not sure) and would have all of the script-ability of Glest 3.2 scenarios plus whatever else we deem. I still haven't gotten to play much with 3.2 and learn about it's new scenarios and campaigns, so I can't comment yet on what else it will need to have added. 
But just suffice to say for now that it's distinct from the other meta-data.
So having said that, let me address modman's items point by point. It sounds like we need to start working on a real specification doc however.
1, 20, 57 & 58) Better help, tutorial, help bubbles and tips: These are good ideas and they need should be grouped together (although not as a single requirement).
2) more players: I'm thinking max of 16 players. It sounds like a big number, but nobody HAS to make a map that big or play a game that big. But by using 16, I can cleanly use two bytes for a lot of the internal data that manages some things (like the map exploration data, etc.) that that way if there's ever a desire for more than 12 game slots, no hacking of bit mangling types of optimized code has to be jacked with. (I'm thinking mostly of the map saved game data at the moment).
3 & 7) Cliffs: Yes, and in the core map data (I will post later on "cliffs, gullies, chasms & canyons")
4) Glestimals: I was initially thinking to define Glestimals in a tileset, but since I've come up with what I think is a better idea (discussed above)
5) Glestimal bases: Are you describing Warcraft-style bases where mobs hang out and guard treasure? That should be supported with an entity and be able to pull it into the meta-data, but again, that doesn't belong in the map format its self.
6) Portals: (a.k.a., teleporters) Yea, but in the meta-data
8 ) Cliff lines: What are do you mean?9) Special objects: Right, but definitely in the meta-data or scenario! Although perhaps these can be encapsulated as scripted "entities" themselves and be pulled in where desired (in the map meta-data or scenario)
10) Caves: Yeesh, I don't like this one. Not that I don't like the idea, but it's the challenge of cleanly integrating it. Maybe we need a new discussion thread just for caves.
11) Bridges: yes. But in the future, a tech tree will be able to define units that are walk-able and span gaps -- essentially be able to build bridges (even mobile deployable bridges like current day militaries have). So at the moment, I'm thinking that the bridges that come with the map should be defined in the meta-data and be indestructible. When we get to the point of being able to support player-made bridges, we'll need the ability to specify rather or not the bridges that are on the map when the game starts can be destroyed. Thus, we should keep this in the design in advance. This may be a matter as simple as a game setting (bridges can be destroyed) and if you turn on that game setting when using a faction tree that can't build bridges, then that's your mistake!
We should be able to override game settings in a scenario so that the scenario will be able to explicitly define rather or not the bridges are destructible.
12) Fill entire map: like cover the land in trees? Maybe we just need bigger brushes? I dunno, whatever you guys think?13) Geological layers: hurray!
Again, I assert that if a map maker doesn't want to jack with it, they can just have the entire ground be dirt. The idea of the geological layers is to generate nice looking scenery with minimal actual work when creating the map by having geological layers defined in advance. Also, we can eventually build a function that will just create the layers (to start with) based upon common occurrences in nature (like costal, plains, hill country, mountainous, volcanic island, atoll (what happens long after a volcanic island sinks), etc.).
14) What do you mean?15) Change colors for topographical view: I have no problem with that. I would also like a 3d view personally.
16) Set middle earth layer: Not sure what you mean. Like in the geological layers?17) Climate zones: Yea, like the difference between a mountain top and a valley or a dessert and an oasis. That will take some thought for me personally (on how to best implement this). See also item 25 (and this will break the tileset paradigm)
18 & 19) Mountains & top-soil: Yea I think this goes with geological layers (13)
20) good idea! We'll have to solidify the actual editor before we go there though (because it will change!)
21) "Cover the basics" you mean like writing up a specification? We're kinda hashing that out now
22 & 24) Water level & Rivers: Yea, I was thinking about this while on vacation last week. It's normal for there to be different levels of water at different places in a map (i.e., lakes vs sea). I think that the best way to do this (scary as it may sound) is to specify water inlets and outlets as well as average precipitation & evaporation rather than defining bodies of water. I think the map editor should take this and render it into water levels and current and that data should be on a per-cell basis. Current isn't so important for now but it only takes 3 floats to specify. Later, we can allow water current to effect units in the water (ships, ground units forging a river, etc.). But most important for now is being able to specify water level on a per-cell basis and having the map editor be able to create lakes & rivers automatically based upon water sources and drains. From there, it's a matter of running a simulation (in the map editor) to create the levels. In the interim, we can just specify that the new map format will allow water level to be specified on a per-cell basis and an initial version of the map editor can just allow you to change that like you do the altitude of the ground. So in summary:
- map format: each cell contains a water level and possibly a float[3] containing current (a.k.a. water velocity).
- phase one map editor: water level is edited like ground level with a function to flatten (i.e., reset to zero) and maybe to raise and lower the entire level?
- phase x map editor: By specifying water inlets, water outlets, average precipitation and average evaporation, the map editor can run a simulation to create map-wide water levels. If we wanted to get fancy later, we could even use this for erosion functions and to calculate vegetation based upon exposed geological layers (i.e., top soil, sand, etc.), precipitation, ground water tables, climate and weather patterns. That is just a *possibility* for the future!
23) Paths: Hmm, please clarify this. I may understand some of what you are saying here (and may have already covered part of all of it)25 & 26) I'll have to get back to you on this. Climate is closely tied to the tileset. You mentioned wind direction later in your list and that's related to weather, but it's also what I categorize as "simplified weather". Maybe we can revisit this after we nail down some of the other stuff. Essentially, this will break the tileset paradigm, which may need to be broken anyway, but that will add a lot of complication.
27) Place rogue glestimal: belongs in Scenario / map meta-data
28 & 29) Weather zones: You mean like specifying a region where it always rains or snows? What I'm starting to get here is different weather systems in different parts of a map -- that's not unreasonable. Remember that the current concept of tilesets is designed to encapsulate both weather patterns as well as vegetation, precipitation and exposed geology. It uses a lot of "short cuts", rather than attempting to look at the components that cause these things, it just says, "bah, it looks like this -- KISS (i.e., keep it simple)". But what we're trying to do is break out of that paradigm to have more flexibility. Also, remember that the advanced weather system will supersede all of this by using more real weather simulation algorithms (but simplified) to determine weather systems. I think we're still far off on that, so perhaps being able to specify weather patterns in the map (or map meta-data) would be a good feature for the interim period.
30) please elaborate (do you mean zones where statues & such may appear?)31) In-game or in the map editor? I can already get a psudo-1st person view by tweaking the camera settings in the .ini. I actually have some vague plans for a future FPS/RTS combo type of game where you can play heros in 1st person, or have a teammate (player who shares control of your faction and/or team shared control or something) who plays the heros in 1st person while another player manages the rest of the faction. So this doesn't need to be in the map editor, although a 3d view with camera controls similar to what GAE has now should be a nice improvement
... once again, my post is greater than 20k characters, so will have to make two posts of it
EDIT: October 18th, 2009: I usually use blue font for my edits, but since I've already used blue in this post, my edits (above) are
highlighted in yellow.
