3d & Spherical maps discussion

[The Joker]

Glad that we agree.

However, I don't think the shape of cities should have huge importance to us right now. To me making them circular would be ok.

Of cause it could be more advanced than that. But it is nothing important, and definately not something we should worry about.

[DJ]

This is just a comment on the Direct X thing. I personally think OpenGL is a lot easier to program with. Is DirectX really easier? Whenever I just try to debug most of the code I just get so lost. lol, I dunno, using OpenGL to me is simple, ALTHOUGH, I do use DirectInput and DirectAudio because it just makes sense to use them right?! Of course, why not have a 3D game with 3D sound hehehe.

[amjayee]

DJ; I haven't really used OpenGL, so I can't say personally. Everyone I know has his own view of this, and I know very little people who know both well. I guess it's personal, what you are used to. Anyway, I think DX8 is quite easy to program with, though I admit the error handling in it sometimes gives me headache. I have a friend who is starting to learn 3d programming, and he has tried both DX and OpenGL, and he thinks with DX8 it's easier to get started; that was not the case with DX7, though. About 3d sound, I'm not sure if we need it. But it's not too hard to make, perhaps some time.

[ElmoTheElk]

I think we should continue using DirectX. Not only because we have used it troughout the project, but if you guys have more experience with it, this seems a simple choise.

So, we decide to put our chances on a Sperical map? Anyone already started doing some programming stuff? Please let us know! Darkstar? Still willing to help us? Hope so...

Elmo

[amjayee]

I got started quite nicely with DX8, though now I haven't done anything for the last week; my school just started, so it will take some mnore days before I get things settled once again. I willl perhaps have something to show soon, but can't say yet... in a few weeks anyway.

I will be creating a 3D rendering engine for the new map system. That way, it's easiest to do, and it's not really very difficult with DX8, don't worry. Just making it general enough and with good error-handling, takes some time. In the beginning, the map will be viewed from top, but it can be rotated and zoomed in and out freely. I think to make things clearer, the camera should always be perpendicular to the ground, thus showing the land straightly from above.

[ElmoTheElk]

Wow amjayee. That seems cool. And I guess the top down view will work.
So things are kepping better after all? Keep up the good work!

Elmo

[DJ]

I agree, really cool man!

[Nath]

Top-down will work, but it might be difficult to draw good graphics for. Anyway, if whoever's going to draw them can, then it'll be fine.

[DJ]

or, if you want get this really good book, Isometric Game Programming with DirectX, it's really good and teaches you how to do all the math and stuff. Although the focus is narrow I think it's what you need to make a good strategy game

[The Joker]

Just to present my ideas regarding how the map would look like:

Each humidity/temperature combo would have it's own colour. We should keep the colours bright and happy, like in CTP. And I don't think any diehard realism is needed here. And there shouldn't be any textures either. In stead there would just be one rendered colour for each type.

Then the 3D thing would not really change anything, just add elevation to all this.

And then, for all the areas that are covered with trees (which would be most of them in the beginning) there would simply be drawn trees to them.

These trees would again not be realistic at all. They would just be small trees with a fixed distance between them - enough to make it look like a forest, and still few enough to make it possible to see the colour beneath it. Furthermore the distance from the first tree to the edge of the area would be half the distance between the trees within the area. This would make sure that a lot of areas lying next to each other all covered with trees would look like one giant forest in stead of several minor ones.

There would propably be different trees for each temperature.


What do you think? I suppose I can draw an example, although I can guarantee you that it wont be very pretty.

The reason why I don't think we should use the realistic approach anyway is that it wouldn't really add anything to the game, it would just make the map less intuitive.

The main goals for the map graphics is to make them easy to recognize, and to make them look nice.

[ElmoTheElk]

I agree with Joker here. We should keep the map open, clear and easy to upderstand. Bright colors are okay too.
Should we draw 'cities' in 3d or 2d? since tress are 3d I suppose this is the way to go, altough it will cause a majot increasement of the # of calculatoins the game will make. Still I like the 3d approach.

Elmo

[Leland]

I was going to just get in, write the comments about Diplomacy and get out... but damnit, I should've known I can't resist poking my nose around.

I've always thought the map as a graph where tiles are nodes which have connections to few nearby nodes. Movement would always occur with several steps from node to node... but apparently what amjayee is suggesting is that instead units could move directly from one node to another. And not only that, but the "nodes" would correspond to coordinates and hence be somewhat continuous (the maximum map size would be something around 16 thousand billion different coordinates). Pelase correct me if I am wrong. Anyway, my point is that this also seems to make things more complicated for unit movement and such... for instance, the algorithm for calculating shortest path between two points AND take into account the varying movement cost of different terrain areas looks difficult (then again, I may be mistaken because I have just never considered how such algorithms would work). Also, the concept of two units being "adjacent" does not exist if everything is done as amjayee suggested, so it appears that there would be a lot of extra computing just to check if two units are close enough to affect each other, or when a unit crosses a border of two areas, or if two areas overlap...

Some of these are probably just as complicated with a discreet, tile based map too. But I do agree that the game mechanics should not depend very heavily on the map topology... we should be able to go from flat to spherical without touching much of the game mechanics. I see several design choices that can be made:

1. Continuous, vector based map (as amjayee suggested). Coordinates are continuous in the sense that the minimum movement, for example, is ridiculously small. Cities and armies would have shapes and sizes, or more accurately areas of influence where there can be no other cities/armies (I think this is a direct consequence if I understood amjayee's ideas correctly). As I mentioned above, unit movement and collision detection (if you can use such term in strategy games) becomes more complicated.
2. Discreet, vector based map. The same as above, except that the number of coordinates would be smaller. Think of a grid where nodes are connected by vectors. This would be a combination of regular tile based approach and amjayee's solution, but I really don't know what the pros and cons might be.
3. Discreet, tile-based map. A grid where each node can only be connected to a certain number of other nodes. Areas would consist of paths between nodes, but unlike in the vector alternative there would be more steps, hence more complexity for certain algorithms.

My opinion is that number 3 is the simpliest way to go, and if we can somehow make it general enough it would be great. For example, the distances between tiles could be different in different directions (a square grid, where one node is connected to 8 others: the distance to the nodes above, below, left and rigth could be 100, and the distance to remaining four diagonal nodes 100*sqrt(2)=141. That's close enough to reality), or the grid could be made unisotropic (some tiles would have less or more connections) so that spherical maps can be implemented more easily. The latter would not be necessarily needed for spherical maps, mind you... I think almost any kind of "flat" tiling (hexes, squares, triangles... maybe even others) can be squeezed in a sphere if the individual tiles are deformed a little bit (I mean, not every tile would be the same shape, but the number of neighbouring tiles would always stay the same).

Phew, that was some long drivel...

Leland

[The Joker]

You do have a point.

But from what Amjayee says he seems to be able to pull your #1 sollution - the gridless, continuus map. And if it can be done within a reasonable time frame I think that it is the way to go.

But I don't think i am the right guy to defend it. You can easily throw some info at me, and I will be unable to defend it due to my lack of programming knowledge. So I hope Amjayee will come over here and talk about it himself.

[Nath]

But from what Amjayee says he seems to be able to pull your #1 solution - the gridless, continuus map. And if it can be done within a reasonable time frame I think that it is the way to go.

Probably, but it various aspects of the game might have to be redesigned.

Each humidity/temperature combo would have it's own colour. We should keep the colours bright and happy, like in CTP. And I don't think any diehard realism is needed here. And there shouldn't be any textures either. In stead there would just be one rendered colour for each type.

That definitely has its advantages, but it might make the game look a bit boring .
Also, the player would have quite a few colors to keep track of and remember what means what.

[amjayee]

I'm still very frustrated of my lack of time. I will try to make up something this week. About gridless map, it is possible, but as Nath said, some things need to be re-designed. More of that later. About no textures, that would make map look more ugly, but we'll see about that later... hopefully soon