26-06-2001 04:49									#61
	Support Apolyton, buy Civilization 2

Leland?

I can supply you with the code for a play project of mine, in which you can plug in a variety of bitmaps. The diamond, I found, made it very easy to calculate where everything WAS. Depending on how you orient the grain of the hex, you can add a WHOLE lot of work to your display graphics, and everything related.

If you use the vertices as well as the sides on the square, you get the basic 8 cardinal directions. Makes deciding which little map location and direction and pathing a bit simpler. If you go with hex, well... you have either 6 directions (side only travel) or 12 directions... but in either case, tracking and what not gets hairy. ESPECIALLY for the user. I know that instructing where what Army group is to go is supposed to be just click and drag... but some people prefer cursoring... and just cursoring around a hex map is hell. up-right down-right up-right down-right up-right down-right... just to go right (with grain running north south). Or up-right up-left to go UP (with grain running east west). You always lose true cardinality in ONE axis with hexes.

And if you use diamonds (squares at the isometric look of 45% rotation), you can always just study other games looks and see how they put together certain things, graphically. Makes ramping up on the graphics easier... you can always create your own, of course. Or go with a common look.

Cylinder? Ugho. What a waste of brain power around here. When are we going to move past the limitations of a simple memory 2 dimensional array and into a more spherical map? With talk of all these systems... climate, tectonic, and what not, I'd think sphere would be the way to go. And we, pardon, the group, might even be able to just go and incorporate the works of climatic, oceonographic, tectonic, and what not directly into the game. Sure, its fun inventing your own special wheel, but there is no need to be forced to do it...

	26-06-2001 17:07									#62
	Support Apolyton, pre-order Civilization IV

Hey Darkster.

You seem to have a lot of experience with this kind of programming. So why not show us you qualities and make us some sphere looking map.

But about the hex/diamond discussion. We once had a very heated discussion on this our own, but we really want to step forward on this opposed to civ2 and other civ games. We all (or most of us) felt that we should go for hexes. I'm not a programmer, so I cannot say much about the system and the difficulty, but I know all our programmers are ready to deal with it.

I am not ignoring your comments, but you will have to convince us really hard... Elmo

	28-06-2001 03:49									#63
	Why Hexes Suck for computers... Got spare money?

OK Elmo...

The 2 things that are make Hexes suck...

* User... cursoring around with the keyboard is hell. You don't have full cardinal directions. (See my above post for the details). In hex mapping, you are always MISSING an axis of cardinality. This makes for real pain in the arse interacting with the map. I am an old school computer guy. I have nothing against mousing... but I find it's faster for me to use the keypad for navigating around to get the "details" of whats where, especially in games like Civ and SMAC.

* Computer... when it moves something in the missing cardinal axis, it has to either SPLIT a hex, or have some other system of determining which hex the item (unit) moves into to. This is a biggie... the team has already said no splitting something across a hex (like cities). So the same should apply to unit movement as well. You might be painting a path between where the unit/army is, and where you WANT it to be, but the computer has to do the scut work and move it there. Pathing becomes a lot worse... and you aren't taking the shortest path. You are "tacking" (like sailing ships) a lot more on land for nothing other then the fact that you cannot move directly on split hexes. More distance travelled... for what? A "cool looking" map artifact?

Anyone experienced with war gaming knows this. But we accepted it. Even if we were screaming about the fact that those troops didn't wear brass buttons, so they shouldn't be brassy on your figurines. (And anyone that has been to any "war gamer" conventions and moderate sized club events knows what I am talking about.) Now, why did we accept it? Because it gave you something easy to handle. No need to worry about rulers. But at the same time, the trade off was that you couldn't just go in any direction.

Since REALISM is a goal... using hexes, which force the computer to unrealistically "tack" across an open prairie goes against the REALISM principal.

Actually, one of the reasons I started looking through the open source projects is that I wanted to just "borrow" or at least get a couple of viewpoints on how to make a real "globe" map. I've got an alternate mapping system for being more "realistic" at the moment... but it isn't a true globe. Merely an old wargamer hex map trick.

	30-06-2001 23:53									#64
	Support Apolyton, buy Galactic Civilizations

Interesting points being made.


Hex vs squares/diamonds:

I am not a programmer, so I can not say much about the (dis)advantages with any of these methods in that field.

I am thinking more about the gameplay. And in that field I must say that I disagree with Darkstar. First numpad movement will simply NOT happen. There will be loads and loads of hexes/squares (100s of 1000s), which will reduce the focus on tiles, and make them just that smallest unit that you don't really use much in the game itself. Furthermore unit movement will be more realistic, which means that units will have a much larger movement range (that is, if supply is available and there is no resistance in the area), so pressing left 50 times will simply not be done. Movement will be mouse based.

So what we have to think about is how that is done best. I think the advantage of hexes is, that they allow realistic movement, in stead of the unrealistic corner to corner movement in most other games of this type. On the other hand, since we are not focusing on tiles this may not at all be important.

So in conclusion my opinion is, that if the technical problems with hexes are too big, then perhabs we should replace it with squares.


Spherical map:

Wow! Seriously, I would love a spherical map. It would make the visual side of the game extraordinary. But from what I have heard making such is quite hard. Especcially putting tiles of any kind (that be hexes as well as squares) on top of it (mathematically this simply can not be done).

But if you know how to do this, and you are interested in participating in our project, then please, talk to the programmers and find out how you can create a spherical map.

	01-07-2001 19:08									#65
	Support Apolyton, buy Call to Power 2

Hey Joker! Welcome back. Darkstar is the new member we talked about! So he isn't only interested, he already is like a member. Or at least I see him so. He already posted a lot on our forum, as you might have seen.

But about the map.

- The movement with the mouse is what is going to happen. The keypad will not be the primary input system to move your armies. Maybe we ban it totally from our game! As Joker explained already, it is impossible to move your armies hex by hex, since the scale we use is simply too large.

- A sperical map may look great. So since you are a programmer, you are the one who have to program it. If it's possible, it's great, if it's too much work, fine to me.

Elmo

	03-07-2001 00:58									#66
	Support Apolyton or Terrorists Win

I disagree with you guys.

Look... for long distance movement... WHEN YOU ALREADY KNOW THE MAP, most sane people will just us goto's. Keyboard: Hit Goto shortcut... mouse to desired target. Click.

But that's just pure LD travel. People NEVER use goto and mouse for FINE control, of a few hexes. Now, you are INSISTING they always use goto with your simultaneous turn resolution. Fine. But they are still going to keyboard cursor for fine movements. And any UI system that makes you keyboard then mouse then back again is going to aggravate people. When they have been shortcut ordering, they are going to want to STAY on the keyboard for navigating to the next command item (army, region, whatever). When they have been mousing, they are going to want to continue to use the mouse. It's basic human nature... and basic human engineering. You don't ELIMINATE an option just because YOU don't like it... not for letting the USER do what they want. Your UI (User Interface) is the single most IMPORTANT factor from a player's point of view... a good one should be invisible to the user's consciousness. They shouldn't ever have to take their attention or thought away from what they are DOING. Especially not to bounce back and forth from the keyboard to mouse and back again... or execute combination (keyboard AND mouse required) items.

Why is UI the most important aspect to the user? A BAD UI, and people just won't bother playing your game, which means they will NEVER discover all the depth and greatness of your application. And the UI is the ONLY thing the players ever deal with. That's the truth about the matter. If GGS is free, they will be a little more tolerant... but still not too tolerant.

Oh... and just so you know... I'm an extremist, but there are others out there like me... I'm an extremist because if I can't use the keyboard to navigate, I won't bother playing the game for very long (unless it's the most incredible game ever). It's an issue of limited painfree playing for me (due to heavy computer use for over 24 years, and extensive mousing for at least 18 years). No reason to bother with your game if I can't enjoy it due to it forcing me to experience real pain to play it. (That brings up Accessibility issues, I know, which is something else entirely.) However, it's always FASTER to use the keyboard then the mouse for almost any and all things, which is something you should keep in mind. One or two key presses versus mouse movement, and another movement, and then clicking, and then another movement and then another movement and then clicking... That's why mousing is so bad for computer users. Too many extra movements to do something basic like SAVE (versus Control+S for most english based apps).

Always engineer in multiple ways of allowing your user to instruct your app to do a particular thing. Never force the user to have to only use one way, whenever possible. Not unless you are ONLY designing your app for YOURSELF. I thought you guys were saying you want this game to have a potential of 500,000 users? And not just the team and their bestest of buddies?

It's easy to put hexes or squares or whatever regular shape you want on a "globe". Role Playing Games have done that since they moved into wilderness travelling.

And as far as globes go... I know where there are tons of globes. AT&T, Hewlett Packard, NASA, and many many others have all implemented a true GLOBE with old machines that haven't the computation power nor the memory of my little Casio PDA. It is very possible to make and model globes. Most TV weather stations run software on simple NT 4 Workstations that use globes in their overall weather modelling. So please do not say silly things like "that's impossible". You can do ANYTHING in software. You merely have to figure it out for yourself, or use someone else's that has already figured it out. In a business environment, the only thing is it's cost and time. You don't have COST here... because it's all free.

---

Now that said... Software Design is all about your trade offs. Each design has it's pluses and minuses. For example...

Now... I have been thinking about these "millions" of tiles... and you know what? Not gonna happen... realistically . You CAN do it. But guess what? MOST people that would stick with the game are going to go for something SMALLER. There just comes a time where you just can't handle MORE. And if the player can't conceptualize it, they will just eliminate it. You are starting at the wrong end for easy development... You start small, and scale up.

In a GRID system... in "hexes" you have one of two ways of uniquely identifying a hex... the first is each hex is uniquely numbered. Tag in current architure... in Win32 environments (your starting platform), that means fast direct access is a LONG. So thats... (signed) 2,147,483,647 and (unsigned) 4,294,967,295. (A LONG and an INT are the same storage size/format in the Win32 architecture. For quick addressing, we would use the ID as the offset from MAP_BEGIN address, IF your map data fits into ONE BYTE, which it doesn't, but we will speak about that later. ). That's 4 thousand of 1 million... or 8 thousand of 500 thousand... just what size a "grid" are you guys thinking? 16K by 250K? 32 x 125? 64 x 64.5? The second way, using an ARRAY (if you position the grain correctley), gets you row x column y... which you then turn into a straight unique for fast addressing (by multiplying x by number of columns and adding y to it). Guess what? This is the same whether it's a square, diamond or hex... only with hexes, you ALSO get into whether it's at 0 height, or the "odd" row and at the moved 50% offset in display and location. (Doesn't mess with your memory addressing, just what is by what, and what are legal move direction, as you only have 6, and where to display it in the GUI rendering... yadda yadda blah. You don't get this with SQUARES, making them easier to implement in your display.)

You guys spent some time worrying about the amount of memory REQUIRED, but you HAVEN'T thought of the only thing that REALLY matters... the amount of TIME the user is going to have to wait while the computer deals with computing on that number of elements... and on the amount of time it takes to find that map tile object in your map collection. For only 10K of items, you can see a large HIT. Object lookup in a collection is never fast, no matter what your instructors may have said. You can merely implement a few things (which adds to your memory storage requirement, per item) on making it FASTER... like double linked lists to support moving to the next object and the previous object quickly from THAT object. You got six directions with a hex... that means if you need QUICK access to it's six neighbors, you have to have 6 pointers to it's neighbors... one per side. Now you can QUICKLY find it's neighbors from that hex object... so long as that object (nor it's neighbors) never gets deleted, and another created. But if you need to make a non-adjoining jump? (for instance, pathing to your "goto x,y" and calculating the cheaper movement point costs, rather then least amount of hexes travelled...) You are back to having to get the map tile objects through its collector... Very slow... (And that's presuming that your map tile "database" isn't being manipulated by any other "threads" at that time... otherwise, you ALWAYS have to go through the collector, for data safety. This I can see happening under a common free game design philosophy of making each "AI" run in it's own little thread world, interfacing with the main game engine using the same API and Interface as the Player's Client.)

Speed. You guys are saying: We don't care about the local area, and we don't care if it takes 2 hours to just display the local screen full of data... nor 8 days to just do one turn resolution.

The "local" area will ALWAYS matter, SOMEWHERE. And you will need very quick access to it... if it takes 200 commands to just find it and return that one tile object, multiply that out by every tile looked up per larger operation (painting the scream, determing paths, calculating various models and their changes (people, disease, economy, weather, climate, supply chains, regions, yadda yadda blah). Second, humans can only comprehend and conceptualize a limited number of items at once. Some of us are very good at it, with the ability to put together 20 items at once. Some of us aren't... and only handle 3 or 4 at a time. The AVERAGE person can handle 5 to 7... What does that mean? That means we break things up into smaller chunks... in a TBS game with a lot on the screen, that means we have to shift our minds over a range of things, and filter lots.

Now... how many of you have played SMAC? Civ 1/2? Just how meaningful is the map at max zoom? If you can't see it, you sure can't figure it out for yourself what that area of screen really looks like... but if you zoom out the SM games, it doesn't really help does it? Because you can't see things... people need to be able to see things to know them. You acknowledge that with the layers of the map... but you aren't following that principal out from what I've seen.

Code wise, your map is all important... it will be the "object" used the most by your code, and be your true bottle neck for speed/performance. Unless you are going to go get MySQL or some other form of database, you are going to be using "tools" and techniques that don't scale up very big, very efficently. That's very important. Going past their PRACTICAL limits, means choosing to get SLOWER much more greatly with each step.

Just the new village idiot...

Last edited by Darkstar on 03-07-2001 at 01:47

	03-07-2001 01:16									#67
	Hexes aren't realistic... Support Apolyton, buy Galactic Civilizations

Oh... and just to finish this off for today's comments on mapping... HEXES AREN'T REALISTIC!.

That's right. I said it! What do all the armies and navies of the world USE? Square maps. For LARGE scales where the actual curvature of the earth maps a difference, they use STRETCHED/distorted squares in all the older systems I've seen. If hexes are superior, don't you think they'd USE them? They'd have used them long ago. They never have and they never will because hexes aren't. As I said before, hexes are used in war gaming for ease on the human to JUDGE distance.

If you want to do this thing right, why not use 'mixels' (a map pixel) on a globe? Or a poly sided object at least (say... polyhederon). Believe it or not, code developed for the American goverment is public domain, unless it's a "security" risk. Let's see... NASA has lots and lots. Their Oceonagraphy, Meteorlogical, Hydrological (the complete water modeling in the biosphere)... that's just what I know of here at Marshall Space Flight Center (where I work). And I would think there should be some free source games already with an actual working globe. Then it's just a matter of adjusting their map unit to use yours instead. Why reinvent the wheel? Again?

	03-07-2001 03:29									#68
	Browse Apolyton AD-FREE

Interesting points, you sure seem to know what you're talking about. Anyway, the main reasons for me personally preferring hexes (without "diagonal" movement) over squares are

1. We can calculate the approximate distance between two hexes simply as the amount of moves it takes to get from one to the other. Yes, you can do this with squares, but let's assume that we want to illustrate the area where a unit can move within a turn... in a square map, this would always be a square, and in a hex map it will always be a hexagon. In a non-discreet map, the area would realistically be a circle (which is of course an optimal situation, more about that later), and hexes are closer approximations of circles than squares, so it would be more realistic.
   
2. The computer can think of hex map as a two dimensional array, just like it would a square map. The only difference is that instead of eight possible neighbours, there would be six; in practise, just two diagonal neighbours are disabled. There doesn't need to be pointers to adjacent squares, simple offsets in the array will do. If a hex's coordinates are (X,Y), then the adjacent coordinates are for example (X+1,Y), (X-1,Y), (X,Y+1), (X,Y-1), (X+1,Y+1) and (X-1,Y-1). Doesn't sound too compuationally intensive to me... though I may of course be wrong, since I have no experience on these matters.
   
3. The drawing of the map may not be as intensive as you make it sound... the UI gets a copy of the portion of the MAP it shows to the user, and thus the main map need not necessary be polled 70 times per second. Only when scrolling... well, that could be a problem, yes. But anyway, when the program is acting as a server (and making the heavy calculations and having AIs querying the map) the UI may not be active or as critical as it is on the client side. I think it is not an unreasonable compromise to make the game little more unplayable to the server guy (who'd have a slower game anyway due to several AIs on the background) in exchange for hexes.
   
4. I don't think we need "true" distances between two hexes as opposed to the number of moves between them. I believe that if we use square maps, we're forced to do most of the stuff with real distances, and that can get really complex when we have to take into account different movement costs for different terrains and other such factors. Sure, it is unrealistic, but it's still more realistic than a discreet algorithms with square maps would be.
   

I'm not totally against innovations like spherical maps, or fully realistic movements. I just believe that they are too difficult to implement. This is why I think that the game should be designed so that we can later change the map implementation (or someone else can make a new game based on ours which changes the map) so that the regions, units and such would not be affected much. But what are the benefits of truely spherical map, or "mixels"? Polar regions never played a big part in the history of mankind, and I don't think that geography in general is what makes a game terribly unrealistic. I'm sure we can simulate climate and plate tectonics with cylindrical map. At least sufficiently. The main focus of the game should be in being realistic about the mechanics of social interaction, not necessarily on geography.

As for the number of hexes... the comparison to SMAC is a strawman because SMAC was not designed to be zoomed out so much. We have that design choise... I can imagine a map zoomed very far away, each region being color coded or something so that it really does show relevant information instead of thousands of individual tiles. The tiles would be like pixels on a bitmap image: itself they don't matter much, but they form objects that are tangible. When you are reading this, does it hamper you because each letter consists of several pixels? And each word consists of several letters? And each sentence... okay, you get the point. Anyway, just because there would be a great number of small primitive objects doesn't mean that there wouldn't be larger, emergent structures which would be just as comprehensible to the player as theit smallest parts. And this is what makes the game region-based instead of tile-based: you might have ten thousand tiles making up ten regions, which do you think the player will think of, tiles or regions?

L

	03-07-2001 04:12									#69
	Support Apolyton, pre-order Civilization IV

Leland...

I can understand how and why hexes are better approximations of circles. But why have a copy to the map? You are just slowing down that much more, I would think. And wasting memory. Memory gymnastics are something to be avoided.

As far as quick neighborly access, that was my point. In a straight array, you an do that (whether single or double or whatever). But so far, it SEEMS as if a map tile, whatever it's shape, isn't going to be a simple item. So where does that object come from? If the final code goes with map tile objects out of global memory, then you won't have a straight array. You will have at best an array that has pointers to your objects. At which point, it's faster to just store some more, per map element to access the actual map tile object. You are already eating up huge storage, and storage size isn't important. Not in this discussion.

I hadn't meant to make a straw man out of SMAC comparison. I often change my zoom levels in SMAC and Civ2... from local theatre to a good bit bigger. In playing such games, I think globally, regionally, and locally. Just as I would suspect many TBS players do. Your focus changes depending on what you are doing and what you need to do, for the immediate, near, and long term future in the game. But, on the other hand, the outermost zooms are USELESS, and do not show me any information that is of any worth to look at.

Actually, the poles play a VERY important role in MODERN times. Strategically speaking. The shortest PATH on a globe is a curve. And it really does affect things like climate and currents. But if the GGS team would rather go for the tradional rather then the realistic or the ultimate (because it would be supremely STUPID or DIFFICULT ), I can understand. That's the design process. You don't do things because you COULD, you do things because they implement your design and meets your acceptable pluses and minuses.

	03-07-2001 16:03									#70
	Support Apolyton, buy Civilization 2

You seem to know what you're talking about, Darkstar. I don't, however (know what you're talking about), so I wont discuss any coding stuff with you.

But: You are talking about a globe, using pixels and no tiles at all. That is, I think, everybody's favorite sollution. But I can't make it. And it doesn't seem like the programmers can. Can you? Will you? Having a good, easy to use (not as static as the globe in, say, Manifest Destiny) globe would, again, not make or break a game. But it would be SERIOUS spice!!! So please, if you want, find out what you can about such a map, and get together with the programmers to find out what you can do about it.

	04-07-2001 12:43									#71
	Lose 30 kilos (of popups)

Instead of a proper globe with one-tile poles etc., it might be an easier to program though not quite as good alternative to make a flat surface, but with units/armies able to go straight from the top tile to the bottom. Is this what was meant by a cylinder? In some games this only applies for latitudinal edges, but that isn't very realistic.

	05-07-2001 15:08									#72
	Avatar Enlargement: We've got the solution

Ehh, I think what you are thinking about is the "donout" world from CTP.

Such a sollution is not really any good. It is unrealistic, and quite frankly wrecks the game.

So I think we should use a normal, cylinder shaped world unless we can get Darkstar's help to create a cool sphere one.

However, not using tiles at all brings problems as well. Not only for unit movement (the problems here are easily solved) but for ressource management. So we simply need a basic tile/pixel size, so we can allocate workers to those, and know how much they can produce.

	05-07-2001 19:56									#73
	Inflate your Upload Space

I agree Joker. I say we go for the cylindrical (ordinary) map. A sphere could be good, but it may be really hard to program. Unless someone of the programmers really wants to give it I try, I say we do it the cylindrical way. Just fine to me..

Elmo

	06-07-2001 22:36									#74
	Support Apolyton buy from Amazon

I agree on the cylindrical map style, I think it fits a game of this type well enough. I think our aim is to make an interesting game based on the rules and systems of the game, not on just having a cool map, people would soon grow bored of it I think anyway, in the same way that a game with no gameplay and fancy graphics becomes tiresome quickly.

Darkstar has a lot of valid points to make about hexes, but I'm not so fussed about making it 100% realistic, hexes are not so horrific so I see no reason to change the plans that have been in place for a while ( even when Darkstar does the face )

	09-07-2001 21:12									#75
	Browse Apolyton AD-FREE

Okay. But what exactly does it have better than hexes are? Besides from the programming difficulties..

If you think mavement isn't realistc: It isn't too with squares. But more important: we will have no hex-to-hex move orders, so no clicking on each hex and seeing your army move back and forth between hexes.

Elmo

	13-07-2001 01:56									#76
	Support Apolyton or Terrorists Win

I am still not absolutely sure what to do about the map.

I think that if Darkstar wants to make it, it would indeed be by far best if we could have a spherical map, using something else than tiles. Of cause in this scenario we still need to have defined "tiles" or areas or something, to allow ressource management to be done. But if we have the option to make a spherical map this is not something that is out of our reach.

Anyway, I have created the beginnings of a tile model. It is, as of now, merely a list of the tile types (I think terrain types are better) that we should have.

I know that we once had a hugely complex and advanced model, with thousands and thousands of possible tiles. But since we are, no matter what, gonna have a whole lotta tiles, and since we are trying to reduce the importance of tiles in the game, I think having a simple 1 byte terrain system, with 256 terrain types, would be more than adequate.

The model I have made is pretty simple, and the terrain types still doesn't have very appealing names. It is, however, logical, and as of now it only has around 60 different terrain types. So although I find it good as it is there is room for expansion. Of cause this room could be spent on ressources.

Here it is:

There are 4 main groups in terrain types. They are based on temperature: Arctic, Temperate, Subtropic and Tropic. Apart from that there are some other groups: Dry, Medium or Wet, and Mountain, Hill or Flat. And then there are a few special categories.

Arctic: icecap, water (containing icebergs), dry mountains, dry hills, dry flat, medium mountains, medium hills, medium flat, medium forest mountains, medium forest hills, medium forest flat. (NOTE: Since arctic regions are generally not very rainy I have not included any wet types in the arctic group. Actually I am not even sure if forests can be considered arctic - here I was thinking of forests in Northern Norway or Canada or something. Correct me if I'm wrong)

Temperate: water, dry mountains, dry hills, dry flat, medium mountains, medium hills, medium flat, wet mountains, wet hills, wet flat, medium forest mountains, medium forest hills, medium forest flat, wet forest mountains, wet forest hills, wet forest flat, swamp.

Subtropic: water, dry mountains, dry hills, dry flat, medium mountains, medium hills, medium flat, wet mountains, wet hills, wet flat, medium forest mountains, medium forest hills, medium forest flat, wet forest mountains, wet forest hills, wet forest flat, swamp.

Tropic: water, dry mountains, dry hills, dry flat, medium mountains, medium hills, medium flat, wet mountains, wet hills, wet flat, medium forest mountains, medium forest hills, medium forest flat, wet forest mountains, wet forest hills, wet forest flat, swamp.

So rainforests would be wet forests, either in temperate, subtropic or tropic climate (there are temperate rainforests). Deserts would simply be dry areas etc.

Actually terrain that was not dry was always filled with forests in the good old days before man. So wet flat would be an area that used to contain a rainforest, which had been removed, leaving the area with grassland of some sort (which would mostly be used for farmland).

What do you think?

It is not our greatest breakthrough, but I think that with a little work (not much is required really) we could have a terrain model working. This will mean we can have someone (Elmo?) draw the different terrain types, and someone else (Darkstar?) can program a (spherical?) map that can be put into our UI.

Let's get this train moving, shall we guys?

	14-07-2001 18:15									#77
	Support Apolyton, buy Civilization III: Complete

quote: Originally posted by The Joker Let's get this train moving, shall we guys?

I'd love to!

As I already asked earlier: what type of graphic would you like to see?
1. Realistic (like photo-edited)
2. Drawn (like in civ2)
3. Rendered (like in Amjayee's first map demo, but not really a good possiblility anymore maybe)
4. Something different....

I like 1 the most but 2 will also do the trick.. I included a pic of what I made some months ago. You have (probably) already seen it...

I just want to add to this picture that I like to see it that there will be some sort of border to each terrain type (like coastlines and stuff), so that it doesnt look so silly.

Elmo

	14-07-2001 20:58									#78
	Help yourself to an AD-FREE life

Would 'sort of realistic' be an option, i.e. not quite a photo, but a fairly realistic drawing?

	14-07-2001 21:06									#79
	Support Apolyton, buy Civilization 2

I agree with Nath here.

Sort of realistic, not sattelite realism, not Civ2 drawings, but somewhere in between, where the terrain looks pretty much like what it would in reality, but with a few refinements to ease recognition, would do the trick.

	15-07-2001 03:02									#80
	Help yourself to an AD-FREE life

Yes, of course it's an option. I actually agree with you. It seems the best option for me too. The image I included is made from original photos and some of my own influences. And we (I?) could draw coastlines and stuff which are drawn, rather than taken from a photo.

	16-07-2001 19:43									#81
	Support Apolyton, pre-order Civilization IV

These new ideas are fine for me, I think terrain is not that important... also, it is quite easy to make the map drawing system working like that. But has anyone considered how huge job it is to create the tile graphics? We need lots&lots of them, a reason why I thought of making the rendered map system... I was not sure if we can get enough artists to have enough tiles. But anyway, it's not me who will make all those tiles, so fine.

	02-08-2001 19:10									#82
	Suffering from ads?

A little different idea for map-making that would ease the graphical part (I'm no programmer so don't ask me ). It would work quite well with tileless systems, which I believe to be the best solution.

It's a sort of rendered map; First of all create the elevations (like you do in 3d modelling software) - I wonder if it's practically possible to generate a 3d model of the map without any regard to tiles. Try doing it by some sort of 3d vectors. That's the first layer, basically an elevation map. You can even use 2d shapes and give each a height value, like in, um, elevation maps
some four bits will be enough.

The next step is to establish temperatures, rainfall etc. - that can be done, again, with vectored shapes, and having nothing to do with the elevations. I'd say four bits for temps, two for rainfall, four for soil types (will have to check some essay about geology/geography for that).

Then you put the coverage, meaning vegetation. You'll need about two or even one bit for that, modified by the temps, rainfall and soil type. Again, consult real-world data.

Pathfinding? I think that if you use real kilometers for that and somehow draw lines using key data (elevation, soil type and coverage) using, again, vectors, it'll be possible to implement, although again, I know next to nothing in programming.

Anyway, if you use for the graphic engine the elevations as a 3d-model and the coverage/soil as textures, with overlays that will draw the temps and other things, it's implementable using the computers that will exist by the time the game is out. You don't have to use high-quality rendering either, and I'd recommend using OpenGL and not DirectX...

Use a 'real-world' coord system with kilometers as the basic units - although most of the time you'll refer to larger distance units. That way the large-medium-small map types will refer to the detail of regions and not to the number of hexes, detail meaning both number of individual regions and number of vertices.

I bet that if you look around you'll find a couple of hundred implementations you programmers can work off. So start looking. I'm willing to help in the graphics department as well as in the overall discussion.

By the way, since elevation and other things automatically modify terrain types, you can put "terrain 1" as a biggie region and have it show as a part-tropical-part-rain forest with the big mountain in the middle gradually changing from forest to bushes to no coverage at all. It'll reduce work, I believe - if you can somehow store the info so that it won't have to make the calculations all over again. You can have a thing called "geographic regions" that will be the intersections of all layer regions and will have the basic tile-like properties like fertility, etc.
Human stuff can have layers of it's own, this way you can have any size city possible and won't have to worry about armies sharing tiles and such - just put a value modifiable by terrain type, unit type and tech level that will be the min distance between armies before they start duking it out.
The problem is that there seems to be such a huge amount of calculations here that I'm afraid this is *not* implementable. But if you have some 200 megs for temporary data you're all set

If you somehow manage to implement this, you'll have absolutely the best terrain engine ever.

And terrain *is* importat - it's the stage on which everything is happening! The social stuff and all too.

Again, this is my disclaimer: I don't know anything relevant about programming, so don't blame me if you can't program it. It's reasonable.
If it's not reasonable, then you can yell at me - but not "can't program this" kind of reasonable!

	02-08-2001 19:52									#83
	Support Apolyton

By the way, if you seperate the drawing of the regions from their other info, (or assign identifiers to non-explicitly-drawn regions or whatever) you need only explicitly draw half of them, since the "negatives" are regions too. In other words, the border of one region is the border of another one too.

	03-08-2001 13:05									#84
	Support Apolyton or Terrorists Win

You know, I thought about it some more and now it really seems to me too complex and stuff. But Darkstar seems to be knowledgable about all this, so I'll just listen to him
And to the others

	04-08-2001 02:06									#85
	Enter the AD-FREE zone

Nice suggestion, comrade!

I, like yourself, do, however, think that implementing such a map model will be serious work. The majority of things - unit movement, regions etc - can be done fairly easy. Of cause defining different vegetation areas etc can be done like defining regions - laying down some vectors and telling the computer that between these there is a forest. What really creates the problem, however, is ressource management. When we have workers working on the land they will either have to work on a single spot, or in an area. Both becomes rather odd and abstract when trying to make it happen.

Of cause it can be done. And I agree with you that Darkstar seems to know what he is talking about. So if anyone can help making it happen it is him. Let's hope he will.

	11-08-2001 00:07									#86
	Tired of ads?

An interesting idea, people seem to prefer point-based movement to tiles. On the other hand, making climate independent of elevation is over-simplifying things a bit, and I don't mind tiles.

	11-08-2001 02:39									#87
	Support Apolyton buy from Amazon

Not generate climate seperate from elevation, but map it seperate. My suggestion wasn't concerned with the mechanics of the map-generator.
Point-based movement is much more flexible.

	20-08-2001 01:20									#88
	Support Apolyton or Terrorists Win

Actually when I think about it I don't really think I like Elmo's map drawings that much. This is weird though, since I am tremendously impressed by everything else he has made.

This is why:

- The colours are a bit "sad" or "dull" or something. Like in SMAC the colours are not very bright and happy. CTP was a terrible game, but I think the map graphics were pretty good, since they were bright, easy to recognize and nice to look at.

- Each hex has texture on it. I don't like that, since several hexes next to each other all has the same texture and it ends up looking like a tiled floor or something.

I propose to use a bit different approach, which also differs from what I have suggested earlier:

We are gonna use areas in stead of tiles, as described by Amjayee in the spherical map thread. This means that each area is going to have it's own shape and size. I therefore suggest that each terrain type (with two variables; temperature and humidity)has it's own (bright) colour. There would be perhabs 16 different types, so it should be possible. Each area should ONLY have that colour, so no texture of any kind. And the colour should be easy to recognize from the other ones. I don't care too much about realism any more, since I think playability is more important in this aspect of the game (map graphics). Then, if an area is covered with forest this would be drawed on top of this underlying layer, by drawing actual trees Civ2 style on it. This again has to look nice, realism is not very important. To make it look nice we should make sure that there is a set distance between each tree, and that the trees "start" at half that distance from the edge of the area. This will make sure that a large land with different areas all covered with trees would look like a giant forest, and not several small forests seperated by a small border. The areas should not be easy to seperate from each other in the game. Each temperature (arctic, temperate, subtropic and tropic) should have its own type of trees, just to make it possible to differentiate, and to make things look even nicer.

Furthermore, when/if the map goes 3D, elevations would be drawn. I think to make things easier rockyness (whether an area has hills/mountains on it) should merely be a function of the inclination of the area. So an area where all parts of it is the same elevation should be flat, where an area where one part is high above sea level and another is low should be covered by mountains (which should be drawn).

Generally I think the areas should be drawn to make them meld together. They shouldn't be clearly seperated on the screen. In stead the borders should be visually unclear, and it would be like looking at an actual terrain.

	20-08-2001 03:04									#89
	Support Apolyton, buy Civilization III: Complete

Thus far I haven't meddled in the discussions about the map, since I know this is definitely not my subject of knowledge. Yet I would like to make some remarks now:

Whatever the map will look like, we will always need tiles/squares/ hexes to organise population, resources and political structures.

Then I would like to say that Jokers' terrain types list makes sense to me.

quote: There are 4 main groups in terrain types. They are based on temperature: Arctic, Temperate, Subtropic and Tropic. Apart from that there are some other groups: Dry, Medium or Wet, and Mountain, Hill or Flat. And then there are a few special categories.

But I think there should be at least four levels of precipitation. After all, every atlas distinguishes between Desert (extremely dry), Steppe (quite dry), Savanna (rather wet) and Rain Forest (daily showers). In desert country very few humans can survive for any lengthy period. The steppes are not suitable for agriculture, but often highly inviting to extensive stock breeding. Without them we wouldn't have a living space for the steppe nomads, who were quite important in history.

I also hope we will have some differences in altitude. This was one of the few features of SMAC I liked. I also think the possibility should be there that the climate will change (caused by human interference or by 'natural' causes) and sea levels will rise or fall. I don't think we should necessarily follow history here.
When we would do this, substantial parts of land would be swallowed by the sea during the game. Until about 5,000BC Britain was still part of the continent and the North Sea only developed gradually.

Finally I would remark there is a significant difference between a low mountain range -like the Harz in Germany or the Scottish Highlands- and high mountains -like the Alps.

	20-08-2001 18:08									#90
	Inflate your Upload Space

Basically I agree with you that some "tile" system is needed for population purposes. But the great things is that Amjayee's newest system (in the 3D map thread) replaces this with areas, which can have any shape we want them to.

This means that the area of each area is calculated at the beginning of the game, and after that the area will just work like tiles, except that units, cities etc wont be restricted by them.

Personally I find this system much better than a tile system, since it is much more versatile, and not much more complex to create.

Furthermore I agree with you that we need 4 kinds of humidity.

And I think that changing climate would be a good thing as well.