 |
| |
|
|
Guildmaster
|
|
Up your butt and around the corner
Jun 2000
time: 05:14
|
|
For this we have the following... I remember if it's too complex even today's most advanced computers would get bogged down, yet if it's too simple it won't be worth playing. This system would provide a simple 8 bit code for each tile and save a lot of memory too.
00 00 00 00
Terrain
00 - Flat
01 - Featured hills
10 - High steep hills
11 - Rocky mountainous
Rainfall
00 - Dry desert
01 - Moderately dry
10 - Rainy
11 - Rainforest
Temperature
00 - Frigid arctic
01 - Cold temperate
10 - Warm temperate
11 - Hot equatorial
Elevation
00 - Sea Level
01 - Up to 500 meters
10 - Up to 2500 meters
11 - Above 2500 meters
All other things like groundwater, rivers and fertility can be a factor of there four.
As for fertility, I don't think it's important in game terms. Basically most flatgrassland is equally arable. To represent superior soil, we could simply have crop or food bonuses for certain areas like flood zones, volcanic soil, etc. Or we could just go on a combination of the above figures. Ever notice that the more rainfall an area gets, the worse it is for growing things? More mountainous areas would generally have better nutrients, ane riverbeds especially would also.
As for water, there needs to be a toggle for ground water?
Well +/-
River +/-
Navigable river +/-
Lakes +/-
I don't know how you want to do this, nut I will think on it.
Something like if groundwater = no, then next tile if groundwater = yes, then specifiy
I dunno
Ocean... How do we want to do the ocean tiles?
|
|
| |
|
|
|
dan ward
|
|
I thought SMAC had a nice model for ocean tiles. IIRC there were several different depths similar to altitudes for land tiles.
|
|
| |
|
|
|
amjayee
|
 |
Jyväskylä, Finland
Oct 1999
time: 07:14
|
|
I have also been concerned about the memory usage of the map. We have to find out what's the best way of doing it.
About your suggestions, something like that could be used. I think that it is a little too simple, though, the terrain should be more varied. But let's think about it. Perhaps in the Sunday evening meeting we can talk those things.
One of the things to decide is the tile size; I have earlier suggested that the tile is 70 kilometers wide. We should decide the tile size and stick with it - that would partially decide the scope of the geography of the game. With 70 km tiles, the map of our earth would be about 570x330 tiles = 188100 tiles... wow, sounds like a lot to me. If we want to keep the map < 1 megabyte, one tile must not be larger than 5 bytes - which might be too little.
But in our world, most of the action takes place in Europe, so we might want to make a little unrealistic map, with relatively large Europe and Asia and smaller Africa and South America.
Well, anyway, just thinking out loud. What is the medium map size, that you would tolerate? It needs to fit in the RAM. Myself, I have plenty of memory, and I might go up to even 30 megabytes or more a in single-player game. Multiplayer maps should of course be smaller.
About ocean depth: Yes, oceans also need to have varying depth - possibly affecting what ships can navigate through that tile.
|
|
| |
|
|
|
dan ward
|
|
There are 256 unique values in one byte (2^8) so memory shouldn't be too much of an issue. We should probably concentrate on making a map that supports great gameplay rather than worrying about memory or realism.
|
|
| |
|
|
|
amjayee
|
|
Jyväskylä, Finland
Oct 1999
time: 07:14
|
|
Well said, dan.
So, gameplay should be the issue, also trying not to make the map too large in memory.
Guildmaster's proposition could be the basic idea how the map would be stored, ie. using bitfields of c++. We just need to think of the tile properties, and the value ranges.
It's not a necessity to have only four values per each property. In bitfields, we can use any number of bits - so there can be 2, 4, 8 etc. values. Also every property need not to have the same amount of bits. I stated that we might want to keep the tile less than 5 bytes, but that's not a necessity. With five bytes, we can have 13 properties with 8 values each, or 10 properties with 16 values. So, let's think of the best choices, without going into too much detail. Here are some things that need to be done, at least.
1. Tile type. This could be single bit - 0 for ocean, 1 for land - or there could be multiple values for each "watered tile" type. For example; ocean, river, navigable river, freshwater lake, coast, dry land, islands. Though the islands we can live without.
2. Terrain, like Guildmaster suggested; from flat to rocky. Though rocky doesn't necessarily need to mean mountaineous - if we have a tile with low elevation and rocky terrain, It would have cliffs, etc. Four values might be enough.
3. Rainfall also similar to Guildmaster's suggestion. We might want to use more than four values, though... but less than eight, perhaps. Four sounds too little.
4. Temperature likewise. Perhaps we could have five values, with middle value, temperate. Perhaps rainfall should also have a medium value.
5. Elevation needs more values, eight could do the trick. We could use the same value for all tile types. With ocean and lakes, it would be depth, with dry land it would represent height from sea level. With coast, the steepness of the coast. With river, it would be the elevation, and the steepness of the river valley, etc... But these we don't need to care about, the map creation and drawing system takes care of these.
6. You seem to have a point when you say that fertility doesn't play such a great role, but I don't know... Perhaps the "crop bonus" thing could be done with a simplified fertility property? four values, for four different bonuses?
7. I liked the "special terrain" idea. Perhaps with some bits we could make flags to allow some special terrain types. Flood zone is a must - the Nile valley would be one, Jangtse another, Ganges, Euphrat, Mississippi, etc... River valleys would always be good for food production, but the flood zones especially. River and flood zone combined with a soil bonus, and that is the best food producing place available. There should be only one or two of those areas per Planet.
8. One thing gone missing is the "vegetation" property. This goes from grassland/savannah/prairie to thick forest/taiga. Four values for this might be too little. But we need to find out.
Does someone want to add something here? With these, I think we could get a very good map system, with some old things, but plenty of new things. Plus, it can be done with the map system I have been testing. With it, the medium map should be under one megabyte. In multiplayer, we could zip the map file... and after all, it is sent only once. When the map changes (after some kind of catastrophe, like desertification), only the changed tiles need to be re-sent.
In the beginning, we would do fine with this map. Some things that need to be included later, is the population of each tile - this would be done with a single unsigned long variable, telling the number of people living in the tile. Another is the resources, but those could be stored in a different place, so the player cannot access them before he learns about the resources in question.
Yet another would be the diseases and natural disasters, like earthquakes. The system should be that these are geographical features - some areas would be more risky for earthquakes, and diseases would live in tiles, but also these could be handled by a separate component.
|
|
| |
|
|
|
Guildmaster
|
|
Up your butt and around the corner
Jun 2000
time: 05:14
|
|
The revised terrain model is as follows:
Start with a 20 bit code having pairs of numbers:
00 000 00 000 000 00 00 000
These pairs coorespond with variables designed to give information to the map. BTW, they are in the order they are in becasue each one affects the ones following progressively, as the last grouping is a factor of all previous groups.
The first pair determines the exact type (referred to hence as T) of terrain.
00=Water
01=Land
10=Ice
11=Gas (mostly used for alien worlds)
The second group is a trio for (E)elevation. For T=00, this is a negative number for meters below sea level while for T=01 and 10, this is meters above sea level. For T=11, this is meters above available surface or highest atmospheric pressure.
000=At or below sea level
001=0-30 meters
010=30-100 meters
011=101-300 meters
100=301-700 meters
101=701-2000 meters
110=2001-4500 meters
111=Higher than 4500 meters (V=00)
The third group of knumbers is terrain (F) feature. IT's the same for T=00, 01, and 10 except that for 00 it's all underwater.
00=flat
01=low slow to rolling hills
10=steeper foothills
11=Rocky, cliffs, and mountainous
For T=11,
00=clear
01=light stratus clouds
10=pillow cloud cover
11=big thunderhead
The fourth group is another trio which refers to (M)temperature. These are the values for T=01, and 11.
000=Tundra
001=Sub Arctic
010=Cold Temperate
011=Temperate
100=Warm Temperate
101=Sub-tropical
110=Tropical Equatorial
111=Too hot for human habitation
T=10 is the same except that 101 refers to arable permafrost, 110 is permanently frozen, and 111 is too cold for human habitation. Also for T=10 there is no M=011 or 100.
For T=00, the ranges go from 000=cold arctic waters to 111=warm tropical waters.
The fifth group refers to (P)precipitation
For T=10, precipitation is in snow
000=none
001=Dry
010=lightly rainy
011=moderately rainy
100=Rains frequently
101=for T=10, light seasonal rain
110=for T=10, heavy seasonal rain
111=Rainforest
The sixth pair is modified by the first pair, and indicates rivers (R) available depending on the T variable:
For T=00
00=No river
01=Fresh Water Lake
10=Shallow Ocean Current
11=Deep Ocean Current
For T=01
00=No River
01=Small creek of stream
10=Irrigable river, but not navigable
11=Major Navigable river
For T=10
00=No river
01=Liquid running water
10=Ice/water River
11=Glacier
For T=11
00=No stream
01=Small air current
10=Trade Wind
11=Jet Stream
The seventh pair determines (V)vegetation. Now this is where it can get a little tricky. Let's start with T=00
00=none
01=coral reef
10=kelp bed
11=thick algae and seaweed (zero visibility)
For T=01, M=101+
00=Sandy desert
01=Dry Grasses and scattered trees (savahanna)
10=Tropical forest
11=Jungle
For T=01, M=011-100, except for E=111
00=Grasses & Plains
01=Grasses and Shrubs
10=Light woods (E=011- deciduous, E=100 mixed, E=101+ evergreen)
11=Thick woods and undergrowth (E=011- deciduous, E=100 mixed, E=101+ evergreen)
For T=01, M=001-010, except for E=111
00=Mostly undergrowth, scattered trees
01=Deciduous forest
10=Mixed forest
11=Evergreen forest
For all of T=10, and for T=01, M=000
00=No Vegetation
01=Light Grasses Only
10=Scattered Evergreen Trees
11=Light Wooded area
And lastly, we have (L) fertility. Fortunately for me I don't have to type as much here because it's pretty simple, and it's the same fertility rate for all terrain types, although a factor of all previous figures.
000=Nothing will grow here
001
010
011
100
101
110
111=Volcanic Riverbed soil
Please enjoy my terrain engine. I believe this would allow the greatest flexibility and at the same time conserve memory over a 32-bit code. Additional terrain aspects could easily be programmed into it and variables could be modified for superior gameplay. By having factors of factors (ie. different temperatures for different terrain types) it's like running through a gear converter. This allows a smaller code to define a greater range of variables.
------------------
Goober
|
|
| |
|
|
|
The Joker
|
|
Copenhagen, Denmark
Aug 1999
time: 06:14
|
|
About elevation:
I think we could use a SimCity2000 type system. In stead of having below and above sea level as elevation properties, how about just having an elevation value - preferably a lot of these (16 different if possible). This will all be settled before any ocean is included, and will give a world in which the lowest elevation would be 0 and the highest something like 18000 meters high. We could then simply add a sea level, which will mean that all tiles above this are land and all below are sea tiles? I think that this would not only make sence, but also be a good and workable system. This way we could have a global warming scenario, where the sea level rises "one level" thus flooding the lowest situated tiles?
I am not sure if the sea level should be universal. It could be nice to have inland tiles that were below sea level, and lakes in the mountains that were way above it.
|
|
| |
|
|
|
Guildmaster
|
|
Up your butt and around the corner
Jun 2000
time: 05:14
|
|
Question: What do we need the other 12 bits for? I mean, if we can get away with using only 20 or 24 or whatever, wouldn't that save both time and memory? I'm all for making a more complex game, but I think think we need to make up stuff to make it more complex just to fill up 12 extra bits.
Unless you're talking about reserving the other 12 for civ-related info...
Perhaps 21 would go like
0=no civ
1=civ present
22-32 would define the civilization.
But wouldn't we need more than that?
Or do you want to save the other 32 for in-game alterations on terrain, such as swamps turned into rivers, dykes built up, etc.
gotta go, bye
|
|
| |
|
|
|
The Joker
|
|
Copenhagen, Denmark
Aug 1999
time: 06:14
|
|
Here is a suggestion for how to generate a world. It offers some of the advantages of the "real world" map generation, but it's still really simple and easy to make.
The world would be generated in steps, each of which should be very easy to do:
1: The world is didived into 10-20 tectonic plates of varied size and shape (randomly chosen). All hexes are a part of a plate - the borders between plates go between hexes.
2: Each hex is given an altitude and an inclination. Both should not be very extreme.
3: Each plate is given a direction, one of the 6 possible via the hexes.
4: All plates are moved 1 hex in their direction. When 2 plates move apart (1 or 2 new hexes are made) there will be formed a new, smaller mountainrange at that place, with the highest altitude at the newly formed hexes (like the one at the bottom of the Atlantic). When 2 plates move opposite ways besides each other nothing happends (for now. In the game that area would be very likely to see earthquakes). When 2 plates move over each other, so hexes are "lost", it is a little more complex. If one plate at the hexes that are lost lies significantly higher than the other then this is pushed on top of the other plate, creating a mountainrange at the hexes on that plate near the border of it. The lower situated plate is pushed below the higher one, and a deep sea grave is created in the hexes on that plate near the border. The mountainranges and graves created has varied depth/altitude. Some would be narrow - only a few hexes wide, like the Andes, where other would be wide - up to 20 hexes (assuming a hex is 50 km wide this is 1000 km) wide. When two plates collide and their altitudes are somewhat the same both hexes would be forced upwards, which creates a tall, wide mountainrange in the borderregion - like the Himalaya.
5: In a later and more advanced model there might be several of these steps to make a more varied terrain, but with the current system if mountain generation it would be pointless.
6: Now smaller structures like hills, small mountainranges (no more than 2000-2500 km tall), valleys and such are created. For now this will just be done with a standard Civ2 type map generator.
7: Ground fertility is determined for each hex. I don't really know how this is determined in reality, so for me it would be fine to just do this randomly. Of cause it would be better to do it with a simple, yet realistic model.
8: Oceans are added. It will start by filling out the lowest placed hexes, and then fill 1 elevation level at a time, while calculating the percentage of hexes being under water. At the beginning of the game the player would choose the percentage of the world he would want to be ocean. When filling the hexes of the world with water, it would continue to check the percentage of hexes being under water with the percentage wanted. Sea level is set where the ocean percentage is closest to the wanted one.
9: Lakes are added via some model (large valleys tend to be filled with water or something) and rivers likewise. Rivers would of cause only run downhill.
10: Temperature is added via a model invluding longitude, altitude and closeness to water.
11: Rainfall and vegetation are added. This is a somewhat tough job, as they depend on each other (if it wasn't for the rainforest the Amazonas would be really dry). It should start by having some wind patterns, rain coming in from the sea and such. This would then create vegetation, which would change rain patterns. This should be done for several "turns" untill a realistic world was made.
We should now have a world!
|
|
| |
|
|
|
Guildmaster
|
|
Up your butt and around the corner
Jun 2000
time: 05:14
|
|
i'm still here, just been at work a lot lately.
here's what I was thinking:
i have always favored the continental drift concept of global design, start with plates, move them around a bit and let the world make itself.
Here's how it works creating the world:
start with a plain map grid, then strike it with something, eggshell type impact or something with all sorts of cracks fanning out in every direction, to simulate a cataclysmic collision that began a process of unleashing life-giving gases or something to that effect. Then you figure sub-crustal convection currents moving at one rate at the equator, while moving at another rate nearer to the poles. Assume that all plates will move according to these convection currents. (this same information can be used to great extent with future technologies like geothermal electricity) At the same time, you also figure trade winds will follow a set path and assign a monotonous linear jet stream to the map grid. As the plates collide, dissappear, break into more plates, grow, etc... elevation gives rise to alterations of these wind currents. This becomes the basis for forming the moisture and temperature models.
By determining how the plates collide and using the same magma movement for convection currents as described, we have a solid foundation with which to give certain areas earthquakes and volcanos, and with the weather information in place we can do the same thing with hurricaines, tornados, and etc.
This is why I ordered the stats as I did, because each pair of digits is a determining factor for the next pair. Anyway, the player can decide how long the world-making process has been going on, mich like in Civ2, but with much greater depth. Once time is allowed for erosion and all that jazz, we get to use existing figures on elevation, temperature, latitude, moisture and fertility to decide on vegetation and the rest is pretty much set.
Except for one thing...
minerals.
I would like to propose the remaining bits be used for the storing of raw mineral deposits like coal, ores, oil, etc. Note here, that Fossil fuel deposits are most likely to be located at points that some millions of years ago used to be the most fertile of areas, that's another goor raisin to use the time-growth idea.
Suggested uses for terrain:
Infantry units would incur a defense bonus in terrain similar to the terrain it was trained/grew up in.
Some diseases would have special flags meaning it's only available in certain terrains/temperatures/etc.
Similar growing conditions can be popular among agricultural colonists, that they don't have to abandon foodstuffs they were raised to eat. Sometimes an area might be especially good for X food product, ie. pineapples grown in Hawaii are the best pineapples in the world. =Þ
More later, i didn't mean to abandon you guys
------------------
Goober
|
|
| |
|
|
|
The Joker
|
|
Copenhagen, Denmark
Aug 1999
time: 06:14
|
|
Great to see you back Guildmaster!
Of cause your idea would be ideal for the map generator (although I don't really understand why it should start with a major impact on earth - could you explain, please?). Unfortunately it is pretty hard to make.
Therefor I think that we should start the design process of the game by simply completing the map system, so we can actually make a map to play with. The complex and brilliant tectonic plate map generator can wait a while.
------------------
"It is only when we have lost everything
that we are free to do anything."
- Fight Club
|
|
| |
|
|
|
Martin the Dane
|
 |
Aarhus, Denmark
Feb 2000
time: 06:14
|
|
Sounds good, but I don't think having an ice terrain (T=10) is necessary, this should in stead be part of the (M)temperature (it almost is with the tundra, and sub arctic anyway), Temperature should be climate in my opinion.
As for gas, it's a good idea, but on solid planets this would be over the surface, and on gas giants surface would have no meaning anyway, so why waste one bit for each tile one something that should be part of a header.
quote:
Originally posted by The Joker on 07-30-2000 11:12 AM
The fifth group refers to (P)precipitation
For T=10, precipitation is in snow
000=none
001=Dry
010=lightly rainy
011=moderately rainy
100=Rains frequently
101=for T=10, light seasonal rain
110=for T=10, heavy seasonal rain
111=Rainforest
|
Why does the seasonal rain only apply to icy terrain?
I just realized that my minor change will have significant impact on whole map system, but it would make it lighter.
My proposal would then be:
The file header should contain the following:
An identifier lets say "OC30" for OpenCiv3
Gas or Solid
Elevation multiplier - mostly cosmetic, but nice to have
Hex size - tells the game how large the map really is, this will allow the creation of more detailed maps.
An index of the last 15+ bits of the hex. This could also be laced in a separate file.
Each hex would then consist of 24-32 bits where
The first bit (0) determines the exact type (referred to hence as T) of terrain.
0=Water/Air
1=Land/Cloud
The next three bits (1-3) would then be relative elevation.
Level 0-7
For the programmers this will simplify the matter as the first bit is the sign of a signed integer.
I have not thought the rest through, but I don't think the exact values of the remaining bits should be hard coded into the game. This would leave the next section looking like this:
Bit 4- 5 Features or roughness.
Bit 6- 8 Temperature or climate.
Bit 9-10 Precipitation.
Bit 11-12 Vegetation.
Bit 13-15 Fertility.
Bit 16-18 Base population limit. The number of people that can inhabit the undeveloped hex at no tech. (could be determined by fertility, climate, etc. instead)
Bit 19-21 Disaster code. (fault lines volcanoes etc. Two bits might be enough)
Bit 22-31 Special features, natural resources, etc.
BTW who's the programmers?
[This message has been edited by Martin the Dane (edited July 30, 2000).]
|
|
| |
|
|
|
amjayee
|
|
Jyväskylä, Finland
Oct 1999
time: 07:14
|
|
Hi Guildmaster. What you said about map creation sounded good. Joker; the "impact" is needed to crack the Earth's crust into plates. Though I'm not sure was this caused by a meteor crash, or simply by the convection currents themselves; the currents could have been so strong, they cracked the crust. But anyway, we need a system to break the map into plates. That, like the whole creation system, will be rather complicated, but as Joker said, we will create a map drawing and storing system, then a map editor, then an automatic map creation system.
About mineral placing, they exist usually at mountaineous areas, or in areas where mountains have once existed. Some randomness will of course be used in this.
The uses for terrain sounded good.
Martin the Dane: I agree with you about that ice is not necessarily needed. About gas, that is also no needed; each map will have a "tileset" variable, which will tell how the tiles look like, and how the details of the map system works with that tileset. That allows us to create more varied worlds with simpler map system. The gas was used also in climate system, but I just realised, that we can simplify the map system by creating a separate "climate map"; we don't actually need to store the climate info for every tile, since it is quite global, involves latge areas at a time, and is always calculated according to certain rules. If we store all climate, wind, temperature and rainfall info in a separate place for the whole world, I think we can compress the space needed for it to at least one tenth, possibly even more. The map file would store only the info about drawing the map, and how it looks like on screen.
Same with resources; how much each tile can produce certain goods, depends greatly on certain set rules. We could compress the resource info a little - not as much as the climate info, but still - by having it in another file.
This system would also result in that it would be easier to model more complex rules to let the climate and resource production change depending on situation, if all that info would be inter-connected. This would also make the map creation system easier to make. I'm sorry I can't explain this better right now, I will elaborate on this later.
One more usage for the terrain system; ships could sail faster in ocean currents, and planes could exploit winds.
PS. Martin: I will be programming the map.
[This message has been edited by amjayee (edited July 31, 2000).]
|
|
| |
|
|
|
The Joker
|
|
Copenhagen, Denmark
Aug 1999
time: 06:14
|
|
Hej Martin! Det er godt at høre at du er interesseret i projektet.
|
|
| |
|
|
|
heardie
|
|
^Bump^
The thread is working again.
|
|
| |
|
|
|
Guildmaster
|
|
Up your butt and around the corner
Jun 2000
time: 05:14
|
|
Hmm
I think we should at least have the possibility of more than one city in a hex, expecially in ancient times. I mean, the largest modern cities may be some 50 miles across while two of the largest ancient cities wouldn't even be 50 miles apart.
I think that a player who controls a piece of land should be able to decide how to divvy it up into provinces, and ought to be able to change the provincial borders without too much hassle.
Thirdly, I think it should be possible to have a national border split down the middle of a single hex. That would make that hex a hot-zone for future conflict, much like East and West Berlin during the latter half of the 20th century.
------------------
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
|
|
Interesting pictures. It is a bit hard to imagine it all, though. Hopefully when we get a UI we can make real maps and turns! 
But to answer your questions:
quote:
- Should the regions be flexibel (as in this example)?
|
Yes. Completely. But there should be limitations. First hexes far from the regional capital would give increasing corruption and waste (in some form). Second larger bodies of water should limit regions seriously. I think 2 hexes of water should be the max over which a region could span.
quote:
- Should the cities and fortifications be user build?
|
Cities? No. At least not very often. A player could order a city built, but he could not decide whether people would move there. He could give them reasons to do so, either by giving them money or by forcing them, but this would be costly. Fortifications? Yes, I believe so. Fortifications would mostly be on city hexes, since these would be the ones most important to defend. But also for military bases etc.
quote:
- What about the other civs regions? Are they visable?
|
Yes, I think they should be. In the UI I think we should have a lot of easy accessible buttons (maybe located at the left end of the screen), with which the player could turn on and off different map modes. There would be economic map, which would show all trade routes and other econ things, a military map, which would show armies and other units, a political map, with which each civ's area would have a coloured filter on top of the terrain (like the colours used in your map pics), and then provinces would be divided by lines, but would all have the same colour, a demographic map, where nationalities could be seen, a pop map with pop density, a terrain map, which would toggle terrain on and off, a raw materials map, which would show the raw materials and animals on the hexes etc etc.
Generally having all maps turned on would make the map impossible to view. So the player would turn maps on and off depending on the situation.
Besides all this I think that when the UI has come a bit further we should "reopen" this thread, and the whole map discussion. The map is a truly important aspect of the game, and it is the thing we should be working on after the UI. And if it is possible to trim down the hex properties, even if it's just a few bit, would be pretty good, since we will have over a million hexes in the game.
------------------
"Damn those nazicommunists."
- McBain
GGS Website
|
|
| |
|
|
|
amjayee
|
|
Jyväskylä, Finland
Oct 1999
time: 07:14
|
|
Interesting pictures, Elmo, much what I think the thing should be! Good! As soon as we get somewhat finished with the UI, I will make the map drawing thing compatible with it, and then we can make the final map system. Shouldn't be very long until that, if things go well... During January some results be at hand.
About the map and regions thing, I agree with Joker. About the region border, I think usually they should be between hexes, but as Elmo pointed out, if two factions are arguing about some land, the border could be in middle of a hex - or in some other special case. And about fortifications, there could of course be also fortification lines, long chains of fortifications, but those are quite modern things.
I'd like some agreement on the map graphics; I have become to agree that we should use the straight above view of the terrain, it is better that way, and easier to make also. If this is agreed to by everyone, then there are some further things as a consequence of this; we could not use similar isometric tile, city and unit graphics as in civ2, if the terrain is looked straight above. I suggest therefore, that we use "satellite photo" style graphics for terrain and cities - of course more beautiful, but not like earlier. For units and fortifications etc. we could use small icons instead of isometric images of the units, or animated images. This is more simple, more realistic looking and since we will use armies, also more clear. The icons would be made so that they tell as much as possible about the armies they represent.
This would decrease the amount of work, and clearly put the game graphics apart from other games; in my opinion, the traditional civ style graphics are quite out of date, and quite stupid looking sometimes, even more so if 3d rendered units are used. With good design and artistic vision, our graphics would look beatiful and stylish, the terrain would be much like a satellite image, though more illustrative of course, and warfare would be more clear and strategy-game like - it is after all most important that the situation looks clear and doesn't have any extra things to distract the attention.
So, what do the people think?
|
|
| |
|
|
|
The Joker
|
|
Copenhagen, Denmark
Aug 1999
time: 06:14
|
|
Having borders between hexes would propably be a pretty nice feature for certain troublespots. But wouldn't it be a bit hard to implement, with production, population etc?
Graphics:
I think that will propably be the best. It would make it a bit hard to see different elevations, but we just have to find a way to do that. And I think using unit icons would give the game a cool, chess like feel. We just have to make it all look nice, and make everything easy to distinguish, or the game will be too hard to play.
------------------
"Damn those nazicommunists."
- McBain
GGS Website
|
|
| |
|
|
|
The Joker
|
|
Copenhagen, Denmark
Aug 1999
time: 06:14
|
|
With elevations I meant land elevations, that is whether it is by sea level, or high up in the mountains. The units don't really have anything to do with this. Although I think it should be possible to have several units on the same hex - first air units would not even be on a hex. They would just go from their base (airfield or carrier) to the place of action, do what they have to do and return home all in the same turn. So there wouldn't be any air units on any hexes, at least not other than where they are stationed.
Other unit types, however, could be on the same hex. I think with normal units you are propably right, there should only be 1 per hex (although allied civs could share hexes as in SMAC). But if we have spies or terrorists they should be able to be in a hex where an army is also present. There should then be a certain, small chance of them being discovered, in which case they could be killed or sent back to the home civ, or exchanged for other stuff or something. And the whole concept of guirrella (I don't think I've spelled this right) warfare would be lost if such units couldn't occupy the same hex as another unit. They would just be hidden, and like with spies and terrorists there would be a chance of them being discovered. This would, like spies and terrorists, depend on the terrain. Guirrella units would be least detectible in jungles and mountains, but easy to detect on grassland. Spies and terrorists could easily hide in large cities.
And actually I was not the one bringing up the idea of divided hexes. It was Guildmaster. Like you I like the idea for it's gameplay possibilities, but I fear it would be too hard to program. Couldn't we have border conflicts without splitting up hexes?
Guildmaster:
Since we Europeans have a majority here, we will be using kilometers in stead of miles. 
But anyway, I can see your point in having more than one city per hex. But I don't think it would be required much. Basically the hex is the smallest entity we have in the game. So what is important is, how many people live in it, and whether it is a city or not. So there might be two cities in a hex, but we wont have to model it as more than one city. It could just be made like one larger city.
And I totally agree that for gameplay issues province borders should be easily changeable.
|
|
| |
|
| |
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
|
|
|
|
|
|
24-06-2000 09:38
|