 |
| |
|
|
amjayee
|
 |
Jyväskylä, Finland
Oct 1999
time: 07:14
|
|
Good to find some agreement. About borders, we can as well have them always between the hexes, so no half hexes occur. About units, I agree with Joker. Some unit (army) types can exist in the same hex with enemy units. Also submarines are added to those mentioned.
About unit graphics: if we have a straight above view of the terrain, I don't think we can have 3d rendered units. What I meant, and what I think also Joker understood correctly, is that we would not have units looking like real men or vehicles etc. Instead we would have small icons representing the units, and describing them, and telling some vital information about them. This is mainly because we use armies instead of individual units; It's easier if we just have an army symbol instead of a stack of unit symbols. Also it's less trouble, since we can have only a few army/unit types, and each one has one simple icon (being simple doesn't mean looking bad, though - up to the artist). I think this could be a very cool feature if done well. It is a real challenge for the artists - to come up with icons, that look good, distinguish between army types, and are appropriate for us... more artistic freedom than dull, plastic-like renderings that look stupid in top-down view of the terrain.
|
|
| |
|
|
|
Guildmaster
|
|
Up your butt and around the corner
Jun 2000
time: 05:14
|
|
Hmm I wonder if only major important cities should be named, and we can assume that there will always be some sort of city in every single hex, even if it's just a gas station right next to the house of the person who works at the gas station. I agree, the important thing is How much of the population is urban, and how mich of the population is rural.
------------------
He's spreading funk throughout the nations
And for you he will play
Electronic Super-Soul vibrations
He's come to save the day
- Lenny Kravitz
|
|
| |
|
|
|
The Joker
|
|
Copenhagen, Denmark
Aug 1999
time: 06:14
|
|
Graphics:
I still wonder how elevations will be done with a vertical map...
I agree, however, that we should use sattelite photos as the basics of our tile pics.
Cities:
Yeah, only major cities should be portrayed, and named. All the small ones should just function as rural areas.
------------------
"The future is that mountain."
- Bret Easton Ellis
GGS Website
|
|
| |
|
|
|
amjayee
|
|
Jyväskylä, Finland
Oct 1999
time: 07:14
|
|
Elevations: I think the coloring system used in the latest map demo should be sufficient, ie. higher elevations have darker colors.
About terrain graphics: yes, they should be inspired by satellite photos, but of course they would be more illustrative. For forests for example, we should make green textures that look like a bunch of small trees viewed from above, etc. Mountains are trickier, but perhaps we could come up with something similar to the real mountain-ranges. But I think the map will look quite cool eventually.
I agree about cities etc.
So, terrain issue seems to be settled... what do you think about the unit graphics? Only icon symbols of different army types, and some status data, instead of sprites or rendered animations of men, cannons, tanks etc.
|
|
| |
|
|
|
Sikander
|
 |
Boulder, Colorado, United Snakes of America
Jan 2000
time: 22:14
|
|
I hope that I am not butting in here with a lot of useless blather but..
1) I like the satelite view of the map idea. While showing elevations might be a good idea from an esoteric standpoint, how much will hexes of different elevations really effect game play? If the models for climate etc. are going to make these of some importance, it will be of secondary importance, and should not clutter the map too much. Both elevations and army data can be shown in detail in an information box (like smac) shown when the mouse pointer is on the hex. I like the idea of various filters for the UI which turn off various map data which will tend to clutter the map if they are all displayed at once.
2) A decision should be made whether to make the game more map driven or unit / city driven. If the game is map driven, then each hex will need not only space for it's basic underlying terrain type, possibly including climate data, mineral and soil data etc., but will also need space to hold at least the identification numbers of units and cities it holds, as well as any player modifications such as roads, fortifications etc.
All of this information will make the map a memory hog, but will reduce the number of times that the various game algorithms need to call other tables to determine whether hex XXXX is occupied by an army which can react to or block movement etc., and since most of this data must be displayed upon the map, it will be required by the basic map module anyway, whether it is stored there or not.
Additional information which may need to be stored in a hex might include certain information regarding not only the hex itself, but which hexes it borders (for quick lookup of pertinent ZOC, border, land movement to a sea square conditions etc.) and again since borders and coastlines must be rendered upon the map, it seems logical to include this data in the basic map module.
Thus it seems best to build the game database around the map array as much as possible, as the map will likely have the most points of contact with all of the other data arrays in the game.
|
|
| |
|
|
|
The Joker
|
|
Copenhagen, Denmark
Aug 1999
time: 06:14
|
|
Hey, you're the artist, Elmo. 
Sikander:
No, you are not butting in here. Anybody interested are welcome to join the discussion, or post ideas for us. So thanks!
1: Yes, elevations may not have too much gameplay importance. But they are still giving some flavour to the game. But it should propably just be shown as different colours for different elevations, as amjayee said. Or, alternatively, only as stats in the bottom of the screen.
2: Since we are going to have a lot of hexes in the game, and a limited amount of units it would propably be much simpler to simply know what hex a unit is on, than to store information for all hexes on whether there are units on them. Propably the same thing with roads and such, since there will be many more hexes than there will be roads.
But I am not really sure here. You do have some points, and maybe making it mapbased would be simpler and easier. I think I will step back and let the programmers answer this in more detail, since I can not do it sufficiently. 
------------------
"The future is that mountain."
- Bret Easton Ellis
GGS Website
|
|
| |
|
|
|
The Joker
|
|
Copenhagen, Denmark
Aug 1999
time: 06:14
|
|
After the meeting and a talk with Harel I think that the 2 byte terrain types would just be way much more than we need.
Think about it: how would 60,000 terrain types improve the gameplay? So I think that 1 byte (256 types) could do it, if we give the thing some thought. I can't give a complete list right now, but I think to make the map file smaller (without really making gameplay weaker) this should be pretty good.
Second we realized that 50 km hexes would not give 1,000,000 hexes on an earth map. It would only give around 240,000. So what about to give us larger, cooler maps, the hexes would be reduced to 20 km? This would give 1,460,000 on an earth map. Something that is highly possible if we make the terrain just 1 byte.
------------------
"The future is that mountain."
- Bret Easton Ellis
GGS Website
|
|
| |
|
|
|
Leland
|
|
Another crackpot idea for you guys to shoot down:
Because of the scope of the game and the focus on regions and large scale phenomena, there is a demand to have data structures and algorithms for handling large areas of land instead of individual tiles. Regions are of course one example, but also diseases, possibly populations (at least in my wet dreams ), lines of sight, resource extraction, continents, islands et cetera are also covering large areas in the map. If all these things are done tile based, it means an overwhelming number of calculations per each turn, not to mention the memory requirements. I propose that tile-based information is banished with the exception of the map altogether.
Instead there could be a class for handling an area, long with methods to see if two areas overlap, are disjoint or share a boundary. A single tile would of course be a special case of an area. The advantage of areas would be especially emphasized when there is a need to deal with large, contiguous tile groups: areas can be difined as a closed path of tiles, and as such it is only proportionate to the square root of the number of tiles inside the area. Furthermore, a path can be compressed to considerably smaller size than a set of tiles because a tile needs to be identified uniquely, but a path only has tiles that are adjacent to another and after the first tile the rest can be referred with a relative value.
For instance, consider the following area:
map: tiles in row:
b 1
bbb 3
bbbbbbbb 8
bbbbbbbbbbbbb 13
bb bbbbb 7
bbbbbb 6
bbb 3
There is a total of 41 tiles in that area. I can conceivably see three basic storing schemes for it:
1. have the areas be referred to in a map. With a 1000x1000 map this means that each combination of overlapping areas must be stored as well. Therefore, the map needs to store one extra byte of information to know whether there is a "b" in that spot or not. Memory requirements in bytes would thus be
map_width * map_height / 8 = 1000 * 1000 / 8 = 125k
2. store the coordinates of the tiles somewhere else. This is fine with small areas as you only need a few values, but the number of values grows geometrically. The game is likely to have map coordinates expressed with two 2-byte numbers (with compression you could probably lower this number), and in addition you need to know the number of tiles as well. So, we get
number_of_tiles * x_coordinate_size * y_coordinate_size = 41 * 2 * 2 = 164 bytes
3. define the area by storing the path of the borderline. If I calculated it correctly, there are 28 tiles in there. Now, however, we know that each tile is adjacent to the other, so it's possible to store only the first absolute coordinate and the direction where the next tile is. In this example I've used square tiles and allowed diagonal movement, so there are 8 possible values to go and one value which should be reserved to mean the end of the path. In hexagonal case there woudl only be 7 values and they'd fit into 3 bits, but since four-bit representation is easier to handle we'll use that in the estimation:
starting_point_size + length_of_border / 2 = (2*2)+(28/2) = 16 bytes!
I know there are ways to alter methods 1. and 2. to be more convenient than it was in above examples, and that the calculations with areas require more computing than simple tile based system, but I still think there could be some point in having an abstract notion of "area" in the design and implement various entities as such. But remember, I am not a very experienced programmer (more like a groupie ) so there are possibly some other ways of doign things than the ones proposed above. Please comment.
[This message has been edited by Leland (edited January 01, 2001).]
|
|
| |
|
|
|
Leland
|
|
I think it's possible... hmm... needs some thought, however, and I don't seem to have time for anything but to toss wild ideas around . The way I see this, in the game there'll be need for three kinds of spatial information: tiles (units, cities, improvements), paths (roads, trade routes, unit movement) and areas (regions, diseases, AI). The question is to find the most approriate structure for any particular situation. I feel that having a conventional map on top of which different kinds of things are layered is sensible since it's a lot easier to handle and because decomposing different terrain characteristics to areas it becomes really complicated. Areas aren't really the best way to describe mountaintops, small island groups or rivers.
|
|
| |
|
|
|
amjayee
|
|
Jyväskylä, Finland
Oct 1999
time: 07:14
|
|
Hmm... here are some answers to some questions.
I think 20 km tile might be too much. 50 sounds good - if it takes only 240000 tiles to describe the whole earth, it's only good, since the map will be the most demanding thing.
I have also been thinking of ways to make the memory needed by the map smaller. One way is of course simply to reduce the amount of memory each tile requires. But having 256 tile types doesn't sound good - we are not after all having tile types, but several properties for the terrain. Those properties are needed also for modeling climate and environmental catastrophes etc., so we quite can't use simple terrain types - and this wouldn't make the memory usage considerably smaller, since the tile terrain info will be only one small part of the memory needed. The old system shold be better fro this... though I should revise the system soon.
I have also considered compressing the map data somehow; and at least when saving it on the disk it will be compressed. But I'm not sure if it is convenient to have the map compressed in the memory, since the data is accessed millions of times per turn. Old arrays sound the best thing to have - they are easy to use, and also data is stored logically so they are fast to access. And memory usage should not be very problematic when the game is ready. But everything will be considered, it's just that we don't yet know excactly what the map system will be like. But if we can save memory without slowing down the program very much, it would be good. We'll get back to this when we start to implement the map.
About map-based system, I agree it would be good to store everything in tiles. But we'll have to see what's best. After all, there will be less units than earlier, so storing unit (army) id's in tiles would be entirely possible. Same applies with most other things; Simpliness and fast access are good, if the memory usage doesn't increase too much. Once again, we'll have to see what kinds of things are needed.
|
|
| |
|
|
|
Leland
|
|
Actually, that'd be 2^8=256 terrains. Each new preperty with simple true/false value takes another bit.
I can see amjayee's concern about the map size; the proposed > 1M tile maps are BIG, a few orders of magnitude larger than in any competing games. And 256 values for each tile is not enough. However, map is going to be the kind of thing that is used only once, and the requirements won't (hopefully) become any more demanding in the future. According to Moore's law, in two years the average pc will have memory capacity around 512 megabytes, and if the map size is, say, one hundreth of that then it doesn't sound like such a big deal. And it will only become less and less significant when years pass. That's why I'd go for the more detailed map.
I totally agree that more properties are needed. For instance, in addition to basic terrain typ ethere could be information stored, as amjayee suggested, for the existence of unit, cities, certain improvements and whatnot when the actual information about what units or infrastucture there are is stored elsewhere. For example, following flags can be used:
1. units/no units (queried when moving units and such)
2. roads/no roads (movement bonus)
3. agriculture (food production bonus)
4. mining (metal/other resource bonus)
5. city/no city (also fortresses, outposts...)
6. disease/no disease (population is going to be interested in this)
7. inhabited/uninhabited
8. (what else???)
Also there is the issue of different climates and natural disasters... yikes.
|
|
| |
|
|
|
amjayee
|
|
Jyväskylä, Finland
Oct 1999
time: 07:14
|
|
I had once a pretty good view of the map, sad I didn't make any detailed notes. But I do remember most of it. One of my main ideas was to store the key properties for all tiles in a grid, and "compress" the more rarely used ones, like climate and such in some other way. But anyway the map will use much memory. I was once hoping that we could get averagely 10 bytes per tile; so the map would take 5-10 MB, depending on the size; when saving to disk, this would of course compress quite much, I think at least to some 0.5-1 MB. But still this means we can't keep sending all map info around in MP games, but rather the data that has changed.
Another issue is the map drawing thing; when the map is "drawn" to the memory (which will be done since we use DirectX) it will take much more memory than the ordinary map with only the properties saved. So, we simply must draw only the portion of the map that is visible. But that shouldn't be a problem, I have already thought of a way of doing this.
|
|
| |
|
|
|
The Joker
|
|
Copenhagen, Denmark
Aug 1999
time: 06:14
|
|
I'm back. And starting from where I left off.
First, due to my limited programming capabilities I can not say much about Leland's proposed area idea. My initial thought would be, that often using tiles would be cooler, especially for things like diseases, since diseases can't really be said to exist on a regional basis.
Using areas would at least require a lot of work, since the computer will have to be able to create them itself, and do that intelligently. So a lot of grassland tiles right next to each other should be in the same "climatic" area, and therefore diseases should be done on that level.
Hex properties:
I know that the 2 byte system sounds more cool, but I just think that with some thought a 1 byte system could be made equally so. For examble, there is no need for all "basic" terrain types (or temperature areas) to have the same amount of subcategories. Arctic terrain should pretty much be limited to a few different altitudes, and a bit about whether it is ice or tundra. Due to the cold vegetation simply does not occur like it does in a tropical hex.
I think that if we think about this we can make it work.
Number of hexes:
I think that having loads of hexes would be extremely cool. I truly love the 1 mio hexes "feel". And so I think having all those hexes would not only make it possible to have more players, it would also set our game aside from the competition. And doing this maybe 20 km hexes might be better.
But on the other hand we could just as well make an earth map a medium map size, with a few hundred thousand hexes, and then have larger ones that goes up around and above the million hex limit.
Could this make sence?
------------------
"Life is a lesson. You learn it when you're through."
- Limp Bizkit
GGS Website
|
|
| |
|
|
|
Nath
|
|
I'm not sure what was finally decided upon, but here's my suggestion anyway.
50 km hexes with these terrain types:
0 00 00 00 0
A BC DE FG H
A:
0 - land
1 - water
----
B, C:
(for A=0)
Elevation
00 - 0-500 m (low areas)
01 - 500-1500 m (hilly)
10 - 1500-2500 m (mountainous)
11 - >2500 m (mountainous)
(for A=1)
Depth
00 - 0-200 m (continental shelf)
01 - 200-2000 m (partly open sea)
10 - 2000-6000 m (open sea)
11 - >6000 m (deep)
----
D, E:
(for A=0)
Rainfall
00 - 0-40 cm (desert)
01 - 40-100 cm (land)
10 - 100-200 cm (rainy land)
11 - >200 cm (often flooded)
(for A=1)
D:
0 - freshwater
1 - saltwater
E:
0 - calm
1 - stormy
----
F, G:
Temperature:
00 - <10 deg. C. max
01 - 10-25 deg. C. max
10 - 25-40 deg. C. max
11 - >40 deg. C. max
----
H:
(for A=0)
0 - normal land
1 - forest
(exact nature of land decided by temp., rainfall etc.)
Alternatively, H could be used for rivers and currents.
|
|
| |
|
|
|
Hmm... I'm not so sure if anyone has thought about these issues since last year, so no decisions to any direction have been made. All we know for sure is that the tiles are hexagonal and that there are a lot of them. Thank you for yoru input, I think it's nice to open this thread as well, especially now when there is a remote chance for someone to finally get the time to start programming the map... 
I think your proposal is appropriate for one year turns, but if we're going to support shorter time frames (winter/summer, four seasons, bimonthly turns...), we're going to have to separate terrain and climate models somehow. The temperature, for instance, would change every year (climate) whereas forests are an example of a more permanent map feature (terrain). But, for the time being, at least I'm going to use your proposal as the basis of what I think of the map. We can probably revise the whole terrain stuff later when we need it for other models (so far, I don't see much connections... the resource production, for example, has hardly been discussed from this point of view).
By the way, how will different natural resources fit into this model?
L
|
|
| |
|
|
|
Nath
|
|
quote:
By the way, how will different natural resources fit into this model? |
I hadn't thought particularly about resources... I guess they could be placed on the map in suitable areas after the terrain itself is generated, and be treated as a separate object. Maybe the programmers ought to decide that.
Will there be different levels of resource richness (i.e. some areas rich in a particular resource, some moderate and some poor) or will they be present only in some areas (some tiles have an unlimited supply of copper or whatever throughout the game while others have none at all)?
|
|
| |
|
|
|
Darkstar
|
 |
Huntsville, AL, USA
May 1999
time: 23:14
|
|
Ok, I want to clear up a few misconceptions you guys seem to have... At least from what I read... maybe it's me that's the misunderstanding...
If your map is 1M in BASE size, that means you are going to be using that in chunks, lots. Everytime you recalculate the climate, you are going to need another 1M. Every time you do any modelling, here comes that 1M size. And when you are DONE, then you copy back the finished product to your master. Since you were modelling an aspect, you are going to run code to look up the right master hex, change that aspect, and move to the next. That's a LOT of calcs...
The reason you can't use your MASTER directly, is that it's a cellular automata, whether you know it or not.  You can't start moving people from starving city a to happville... it all has to update at once. That means copies... Make a copy of your model, recalculate, and then boost the results in your copy back to when you were done. If you are efficent, you just use master and copy of results. Inefficent, you copy your master, recalc that, and then go and update your master when done. That's 3 meg versus 2 meg.
Second... in most OOP, putting a unit in an Army doesn't get rid of the unit. That unit has properties you need, and is built/designed specifically for that. So you are not GAINING memory. You lose it. By the amount of the container (in this case, the Army), and any other possible overhead to track your "army" containers. Plus, your Army is going to be a command object. It does more then just hold the units. Heck, brand NEW units will be in their OWN Army, until they "join" (move unit ownership from old Army owner to new Army owner, now deallocate the old Army object as we are done with it) the "Army" you are integrating them with.
And that is just off the top of my head. The MAP is going to be your most used object in the game... thanks to display, if nothing else.
If you are going for a top down view... give up on the gorgeous graphics. How much wargaming experience do you guys have? That's the view and presentation you are talking. You can have gorgeous maps, but the Army icons aren't going to be that great. Get used to it. (You artists may consider that a challenge from the peanut gallery. Not an insult. Thank you.) Citys from the top down aren't gorgoes. Modern cities are ugly gridish things. At least most of them.
Why can't hostile units occupy the same hex? Heck, if a hex is 50km... that's a lot of room for ancient armies. Depending on the particulars. Maybe they are drawing up for battle. Maybe they just have lousy scouting and having lousy visibility. But even 50km on the open sea... heck, until radar, it wouldn't be unusual for navies not to see each other at that distance. And they don't have anything but a bit of haze between the two.
Second... you guys aren't keeping in mind high techish possibilities. Why COULDN'T I have my SF dirigibles floating over your armies heads for seasons? Right NOW, NASA has research planes that can stay aloft for 100 DAYS. Their goal is 2 years. Over the same piece of land... They aren't that far out, either. So you are ruling out sky bases, sea floor bases, and sub terranean units. Didn't sound like that was what you wanted ruled out earlier.
And yes, there ARE aspects of realism to this. For instance, American and Viet Cong units often occupied the same "hexes" in Nam... just the American's didn't know it. VC was underground. Had regiments living down there... under American fire bases! That wasn't the first time in history. Wasn't even really an exception. Tunnelling and underground construction has been used by many cultures, throughout history, as a means of procuring security from hostile forces, from man to the weather.
You can IGNORE this "height" factor. That's all it is... height. But it makes the game less "realistic". Especially navally... if I've gotten very advanced submarine techniques, compared to others, my subs can go deeper and stay down longer. So you could have.... my subs (deepest z), opponent subs (deep z), neutral ships (surface), and long duration air unit(high z) at one time.
If you DON'T ignore height, you gain a "map" for every height level. That's not 1M model... have 16 height levels, and you had just made made 16M, if you model is 1M.
Resources can be happenstance scattered about, or you can actually model their formation as we now understand. But that's more "height" information needed, so you know how deep it is, and how it moves over time, I would think.
Consider this though... wood is one of man's earliest utilized resources. And we have wiped out a great deal of that. If you are going to model the effect vegetaion has on climate, then you will be forced to recalculate the climate each time a hex of trees disappear... which is only "realistic". Timber was one of the primary reasons England was interested in North America. She had very little of the stuff left to make her wooden ships, and the truly good stuff was gone. It takes many ACRES of wood to make a wooden ship... or heat a town's homes... or fuel it's fire using artisans/craftsmen hearths, furnaces, and kilns. Let alone to build homes and tools...
Ok... I want to know something...
what is the difference between urban and rural? And why?
Any TOWN should be named. Doesn't mean you need to clutter the display with it's name all the time though. People have a place to call home so that other people know where that is.
I had some other thoughts, comments, and questions... but I've lost track of them at the moment. If they were important, I'll think of them again...
Be careful you aren't over analysising yourselves. It's better to get something and discuss changes (and make them) then to sit idly by and not do anything until real life drags everyone away.
Last edited by Darkstar on 23-06-2001 at 03:47
|
|
| |
|
|
|
Interesting comments. I'm just as eager as you are for someone to answer your questions, especially that thing about rural and non-rural hexes. I never figured out the distinction myself. I'd also like to hear more about your rationale for the diamond shaped tiles... "Trust me on this one" has never quite convinced me. But, real life is dragging me already, so enough for tonight.
The map is supposed to be cylindrical, BTW.
|
|
| |
All times are GMT. The time now is 05:14.
Apolyton Time is 00:14. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
15-12-2000 21:36
|