 |
|
The Joker
|
|
Copenhagen, Denmark
Aug 1999 time: 06:15
|
|
These seem like some great links.
Could you take a look at these, programmers?
|
|
|  |
 |
|
amjayee
|
 |
Jyväskylä, Finland
Oct 1999 time: 07:15
|
|
I was going to post these ideas some days ago, but that night the apolyton site was down and I couldn't post. I didn't have time to post until now. But here are some ideas about the new map system for consideration. I think we could be a little more innovative without losing very much more time.
I think we can design the map so, that it is possible to change the 2d map to 3d later. The trick is, that we forget tiles. So, map is an area where vertain distance in pixels represents certain distance in reality. The map would be navigated with coordinater just like in our world. So, armies would exist in certain coordinates. To attack another unit, you would not move the unit to the same tile. Rather, you would need to get to close contact with the army, and that would be done by ordering the army to attack; they would try to engage in battle, while the other army could try to escape. Production could be handled by dividing the map into areas of arbitrary shape and size. In a simple map, they could be squares for example.
Cities, terrain improvements etc. would be placed in coordinates rather than areas, like units. Cities could have any radius and shape, freeing us from the unrealistic restrictions with the tile system. Population and production would be handled by the areas on the map. There could be many areas in a region, and the areas should perhaps be created according to climate, vegetation and other natural discriminating factors.
The unit movement is already not very much dependent on tiles, so we can as well make units move freely, not restricted by tiles. The same goes with cities and tile improvements. For production and population, we need to have areas of land, but it's not necessary for them to be of any particular shape, or of the same size. The only thing that matters is the amount of people and the amount of natural resources and production facilities. So this would be sufficient. To start simply, we can have square, hex or diamond-shaped areas all of the same size. Later in the 3d map, we could have areas of any shape or size.
With this system, it would be quite easy to store the elevation, climate information and population density as vector graphics. Also coastlines and rivers would be vectors. This system would offer great amounts of flexibility and realism, and endless possibilities for enhancing and adding new features, if it's designed generic enough. Also this system would take time, but not much more than ordinary tile system. And it would be quite easily applied to 3d system, with a planet of any shape. We could as well make cube or donut-shaped worlds.
I think this new system would be worth the effort, and we could get some results quite soon, if I have time to make it. What would you think of it?
|
|
|  |
 |
|
Mark_Lipovrovskiy
|
|
Israel
Aug 2000 time: 05:15
|
|
Great!!
|
|
|  |
 |
|
The Joker
|
|
Copenhagen, Denmark
Aug 1999 time: 06:15
|
|
WOW!
You have great ideas, Amjayee. You really, really do.
This system is so simple and straightforward, and yet I hadn't even thought about doing it that way. To me a tileless map would mean endless work just do design it, and yet this is indeed possible to make.
I am in a hurry now, but I will tune in tomorrow with more comments.
|
|
|  |
 |
|
The Joker
|
|
Copenhagen, Denmark
Aug 1999 time: 06:15
|
|
Ok. First I have to state that I think Amjayee's proposition is fantastic. And it is just what we should have.
Some comments:
I think you are right that starting out by just making all these areas (let's call them that!) square would be pretty good. Then the map could be made, and a more advanced one with elevation can be made. Then we can have maps just as we want them, AND we can turn the map into a sphere later on.
The areas are also great since each area is propably gonna be a lot larger than the 50 km hexes we thought about using. So storing the terrain info is gonna be much easier. I am not yet sure whether regions should be bound to these areas (so that an area can not be split between two regions, although I don't really like that concept), but I do think that some of the more fundamental population things (nationalism, some economics etc) can be bound to the areas in stead of to the regions. This will make sure that players does not cheat by just changing region borders when they have some problems.
I am not yet sure how many areas we should have in the game. But we thought about having upwards of 1 million hexes. And I think we can easily cut that down to 100,000 or even fewer areas. And that suddenly leaves some space to put some more aspects of the game into areas, which, I think, is more realistic than binding them to regions.
|
|
|  |
 |
|
amjayee
|
 |
Jyväskylä, Finland
Oct 1999 time: 07:15
|
|
Wow, thanks for the positive feedback guys. I feel baffled. 
Anyway, it's good that we share the same vision of the map. I think that I will concentrate my time on the map now, and try to get something done. I will need to do some design, to ensure that the thing will be generic enough. I hope I could have something to show soon, but I can't say when.
I will use DirectX 8 for the map, because I'm personally very fond of it, and consider it a huge advancement from DX7. So, eventually I will need to make a new wrapper for it, but that causes no problems - Chris was far-sighted enough not to make our UI dependent of our current wrapper. That's good.
I will keep you updated of the progress with the map.
|
|
|  |
 |
|
amjayee
|
 |
Jyväskylä, Finland
Oct 1999 time: 07:15
|
|
I'm working on the visuals currently, not the map... and yes, hopefully the data and its representation will be separated. It would increase portability too.
We are using DirectX for the UI, in windows environment it is the Thing to use for multimedia things, it's just like that. And since we already use DirectX for other things in the UI, it's just logical to use Direct3D for the map. But we are separating all platform-independent stuff, so porting to some other system and possibly to some other graphical environment is "just" a matter of replacing some classes with new ones. We are doing all we can to make porting as easy as possible.
And besides, I like DirectX. It's one of the most sensible things from Microsoft, which is not much said, of course - but it is quite good and easy to use, and we can do everything with it, without too much hassle. That saves time, which is good, since we are already short on that.
|
|
|  |
 |
|
Mark_Lipovrovskiy
|
|
Israel
Aug 2000 time: 05:15
|
|
Israel is where I live. But I'm generally flexible with timezones.
|
|
|  |
 |
|
Nath
|
|
I'm commenting on this topic a bit late because I've been on holiday, but here are my suggestions:
quote: Production could be handled by dividing the map into areas of arbitrary shape and size. In a simple map, they could be squares for example. |
These 'areas' are basically tiles .
I like the idea of combining tile-based gameplay with point-based, as you've suggested. It'll take a LOT more work, though.
quote: Cities, terrain improvements etc. would be placed in coordinates rather than areas, like units. Cities could have any radius and shape, freeing us from the unrealistic restrictions with the tile system. |
Sounds good, but what'll effect the shape of the cities? Also, at the scales being discussed, changes in the city radius onscreen will cause unrealistically large changes in the actual area. Little cities and settlements will be invisible if the point-based system is followed too rigidly.
|
|
|  |
 |
|
The Joker
|
|
Copenhagen, Denmark
Aug 1999 time: 06:15
|
|
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
|
 |
Jyväskylä, Finland
Oct 1999 time: 07:15
|
|
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.
|
|
|  |
 |
|
amjayee
|
 |
Jyväskylä, Finland
Oct 1999 time: 07:15
|
|
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.
|
|
|  |
 |
|
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.
|
|
|  |
 |
|
The Joker
|
|
Copenhagen, Denmark
Aug 1999 time: 06:15
|
|
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.
|
|
|  |
 |
|
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:
- 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.
- 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.
- 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
|
|
Copenhagen, Denmark
Aug 1999 time: 06:15
|
|
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.
|
|
|  |
All times are GMT. The time now is 05:15. Apolyton Time is 00:15. |
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
|
|
|
|
|
|