Openciv3 - Terrain and map

[Darkstar]

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...

[ElmoTheElk]

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

[Darkstar]

Why Hexes Suck for computers...

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.

[The Joker]

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.

[ElmoTheElk]

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

[Darkstar]

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...

[Darkstar]

Hexes aren't realistic...

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?

[TempLeland]

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

[Darkstar]

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.

[The Joker]

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.

[Nath]

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.

[The Joker]

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.

[ElmoTheElk]

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

[chrispie]

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 )

[ElmoTheElk]

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