20-01-2000 17:38									#31
	Support Apolyton, pre-order Civilization IV

Henrique:

I come down mostly on the side of your choice 2. Although if these aren't enough for game play purposes, it would probably need to throw in some of the larger deposits in your category 1.

While clearly in reality each square should have a potential to contain any of the many resources, the current plan in the economic model is to have only one "special" (and minerals are among these) per square. So although I think it's worthwhile to calculate deposits and their chance for every sort of square, I just wanted to make it clear that the game mechanics will probably cut off most of these possibilities. So, for instance, while there might be tin in Greece, the early Greeks had to go to near Rome and other places to obtain tin. If there aren't nonuniformities in the distribution of tin, we will miss out on effects like that.

Thanks for working on this!

	20-01-2000 19:07									#32
	Got spare money?

Mark
Lets see if you like this:

step one
Allocate geographical position and abundance of resources on the map (with geological credibility)

1 - They will be divided in surface and deep resources.

2 - resources are exploitable only if you have the knowledge to do so and if you have found them (this will require infrastructure investment - covered by econ model; and prospection investment - not covered yet.)
ex. a big % of surface deposits will be readily available to the player, for the rest of surface and deep deposits they will have to be hable to explore (prospection) on a square/province level and create production infrastructures.

How to make the player A really need those products that only B has?

Well... small deposits will only give you a little bit of production, way bellow your needs, and tendency will be for them to get smaller.

The very large anomalies (that can be simulated in example 1 as well as in two) will be 100 to 1000 times bigger and also much more productive (and this is not unrealistic!). The deposits in these regional anomalies (something that should be 2-10 squares big if the scale is 60 miles across)will be huge and hard to deplet (germany still produces huge amounts of coal :-))

The idea is to make everybody able to produce a little bit of everything (even if to make it so they have to invest a lot, and STILL not being able to satisfy product needs - one small deposit will only produce a max amount of ore no matter how much money you put into it) but make it much more cost per unit efective to trade.

I believe this will give a few more interesting things for the player to do, namely to bet in mineral exploration if he wants to - note that in the beggining of the game you might be sitting on top of the "mother load" and you wouldn´t have the faintest idea. Has tech progresses old territories gain new importance :-)

	20-01-2000 21:58									#33
	Tired of ads?

Henrique:

I like your idea on this a lot. If nobody strenuously objects, that's the kind of thing I think we should go with. Perhaps we can handle the smaller deposits in a statistical way even, so the player doesn't deal directly with them. The player would know there is some tin locally, but that the economy could use a Lot More...

	21-01-2000 02:53									#34
	Enter the AD-FREE zone

I want to know what the amount would be needed to develope them for use on larger scales. FE Japan although there was copper, never had a bronze age because there just wasn't that much. So i'm wanting to know, does it take a large area to actually produce the material for anything more than trinkets?

	21-01-2000 03:56									#35
	Support Apolyton, buy Civilization 2

Lord Jinnai

There is one thing you must take into account regarding the development of metallurgy and availability of resource.
The region may have the resources but they may only be exploitable if the mining tech is available.
The resource production technology used for the discovery of bronze/iron deposits is extremely rudimentary and only high grade (big nuggets) surface deposits where exploited. So if you can´t even get a bit of concentrated cooper + tin you will never be able to develop bronze (by the way for bronze metalurgy you must have coexisting tin and cooper deposits, after the discovery you can start getting cooper from square A and tin from square B to make bronze)

I believe you can make the availability of resource a prerequesite to develop a metallurgy tech.
ex:
you must produce copper+tin to be able to develop bronze metalurgy

Iron for iron metalurgy (la palisse :-)

And to make it fun you can make the amount of progress on bronze vs iron metallurgy research dependent on the exploitable abundancy of the prerequesite resources.
So if you have much more iron than bronze+tin you will probably develop iron first (and make any development on bronze obsolete)
On the other hand if you have plenty of copper+tin you get bronze first.

This, of course, must be weighted by the basic amount of research you need to get each tech... it is obvious that iron met is much harder to get than bronze (which means you must have a lot more iron than copper+tin to get iron first)

	23-01-2000 07:34									#36
	Tired of ads?

Our coder, MCA, seems to have dropped from sight. Unfortunately, he has the only copy of the code for the map gen model. If anyone on the forum has access his page (via the link in the forum), please check your caches to see if you have a copy of his website saved. If we're lucky, we won't lose the code that MCA started. The following steps should work:

1) Log off the Internet (they MUST be offline)
2) Click the link. If it's cached on their systems, they'll get the web
page. http://danish.visl.ou.dk/~mca/clash/
3. Save the page file with a different name, and forward a copy to me, Kull, and Mark.

Thanks!

	24-01-2000 15:43									#37
	Support Apolyton buy from Amazon

Ack! Sorry about that. IP numbers and DNS entries were changed here some time ago. No need to check your caches, it's at
http://mca.visl.sdu.dk/~mca/clash/ now. But it's true that I've dropped out of sight - I am no longer coding the map generator (I still lurk around, though)


Martin

	24-01-2000 19:43									#38
	Put an end to popups!

Thanks a ton for the update, and for all the work that you put into the model, MCA! Sorry that you couldn't continue with your efforts - we're always open to suggestions, or to welcoming you back onboard should you change your mind about the coding.

	04-03-2000 00:08									#39
	Lose 30 kilos (of popups)

It seems to me that we are starting to hardcode different land types. This is fine for the standard setup, but it limits customizability. I think that we should plan for a terrain system something like this:

There is a terrain editor that allows the user to alter the map tiles. It has the following options:

Movement: Sets the type of units can enter the tile and how difficult it is for them to move. In conjunction with this, every unit has a movement type defined. I think we are already doing this for units.

For example, a Tracked unit type would be unable to enter a swamp, while an Infantry unit would go in with a movement penalty. An Amphibious unit, like a DUKW, would be able to enter the terrain and travel with no movement penalty.

Power Modifier: Sets a bonus or penalty to a unit’s power in a certain type of terrain, For example, Chariots are much less effective in hilly or forested terrain.

Note that land and sea are not coded differently. They simply have different movement settings. They also have different habitation and economic settings, as described below:

Roads eliminate these movement restrictions and penalties. All roads are about the same, except for roads over hills and mountains. The editor would have the ability to define the cost of the road and the upkeep it requires, as well as the movement required to go over the road.

In addition to effects on units, the terrain editor should allow a designer to set the economic impacts of the terrain, as follows:

Habitation: Sets the ability of people to live on the tile. This can be No Requirement, Never, or a technology level requirement. There should also be the ability to set a structure or improvement as a requisite for habitation, FE Undersea Colony.

Structures and Improvements: Allows the user to alter the ability to build things on the terrain and the cost and upkeep of those improvements.

Vegetation and Resources. Allows the user to alter these aspects of the tile. I am pretty sure that in the current model, vegetation is mostly independent of geology, and I think this is good. I don’t think vegetation should have its own different terrain type, like Forest. Depending on the climate, vegetation can change over the game. Also, altering vegetation should be much easier than altering land structure.

There should be the ability to create entirely new resources, like Mana or Dilithium. This can be done by defining a variable, having terrain add to that variable, and make applications that require that variable and subtract from its pool. If we plan for this now in this model and the econ model, it won’t take much extra coding effort.

Each terrain type in the game would be defined this way. For the map generator model, we can hard code things like “Plates Collide = Terrain # 3 at junction” but if someone wanted to make a custom map, they should have the ability to dramatically alter the terrain and its effects.

Also, at present there seems to be only one type of ocean terrain. I would like to see a game where undersea colonies or mines are possible, and for that to happen there would have to be different types of ocean tile. Even in the present day, they routinely build oil platforms, which are possible for some types of ocean terrain and impossible for others. At a minimum, there should be a difference between continental shelf and deep oceans. The terrain on the shelves should be variable like it is on land tiles, because a reef or kelp forest will have a big impact in the amount of fish in the area. This vegetation would be vulnerable to pollution, and its loss would impact the resources of the ocean tile.

These kinds of things could work with the same Alter Variable equations that the techs and applications would use.

This won’t be in Demo 5, but I think we should keep it in mind as we make the terrain model. There should be enough flexibility in terrain to create any number of new worlds. If we include the flexibility from the beginning, we will have a much easier time and the product will be better. An "Editor First" coding plan is IMO the way to go.

	04-03-2000 03:39									#40
	Support Apolyton, buy Galactic Civilizations

Richard:

I think you've got it exactly right. I believe Mark agrees, and has planned it this way too. He's just been too busy to do this particular analysis/design yet. (I think he's having too many Pina Coladas at night, the slacker!). Hehe.

But there needs to be a 'terrain' object defined ASAP, before any coding is done on any model that uses terrain objects.

It needs these methods/behaviors, as you outlined:

object Terrain --
public methods:
setTypeName(String n);
getTypeName();
setMovementModifier(int m);
getMovementModifier();
setCombatModifier(int m);
getCombatModifier();
setHabitationRequirement(Object r);
getHabitationRequirements();
addPopulation(Population p);
getPopulation();
addImprovement(Object i);
getImprovements();
addResource(Object r);
getResources();

This is important to do as early as possible, actually. Because hard-coding the info means all that code will have to be modified later -- a serious waste of time, especially once the program gets complex (which it already is!). There will be plenty of coding to be done without having to go back and redo anything.

It's also important to consider that instead of variables for movement modifier and combat modifier, we can use objects/systems to create dynamic modifiers. If that is to be the case, it needs to be known now, before too much code gets written relating to the movement/combat of units.

Otherwise, we lose power (the ability to have a dynamic system) and we lose time (all that code that has to be changed). And we lose customizability, as you noted.

In other words, if we don't do the object design up front, the world will come to an end and children will begin listening to Lawrence Welk! And I wouldn't wish that upon our children at all . . .

	06-03-2000 02:54									#41
	Support Apolyton, buy Civilization 2

Another thing about units moving across terrain is the climate.
For example, Hannibal tried to get something like 38 elephants across the Alps. One of those elephants made it, they just aren't cut out for the cold.
The same is true for explorers in the arctic. Many explorers tried to reach the north and south poles. Many of those early expiditions failed because the people died in the cold.
I think we should try to include somethink like this in the game.

	06-03-2000 05:39									#42
	Support Apolyton, buy Call to Power 2

I don't think that climate will change the movement rate much, but you are right in that it should change the rate of attrition your armies suffer.

	06-03-2000 06:11									#43
	Tired of ads?

Richard:

This model is meant to generate a realistic map based on scientific principles. That is distinct from the "active" map in the Clash game per se, and any map editor that derives from it. For these reasons, most of the stuff that you described is already planned (and some of it implemented in code) but there is no mention of it here. Some of that there is no distinct mention of anywhere except in the code.

That said, I don't know exactly how we are going to handle a lot of these issues. And one new thing that I'm glad you brought up was the possibility of people living at sea. I had the notion of Clash being ahistorically limited game, so it never occurred to me that we might actually want to have people taking up shop on or under the ocean.

I do not think their roads should eliminate movement restrictions entirely. The reason is that as one gets toward more modern weapons, use of roads in combat situations becomes problematic. As they near a battle site (or are subject to aerial attack) units have to disperse over a much wider area than the roads can accommodate or they will suffer tremendous losses. You can see my general thoughts on this (which are probably wrong at least several specifics) in the current military thread under the ticks system.


F. Smith:

You know, my initial attempts at organizing the Clash project, which you were part of, involved carefully crafting everything upfront and then beginning coding. You know what happened??? Everybody, including you, took off about one month into the four-month process. While I agree with you in general that we should do as much up front as possible in terms of coding specs, there is only so much we can do. Each programmer will do their own coding definition as they have time. I know that this somewhat cavalier way in which we are going to do it is going to involve some wasted effort. But when put up against the risk of the project imploding because of insufficient progress in terms of demos and such, that cost fades into insignificance. We are not a professional project that has a known amount of resources, and can call on them at will. Our extremely valuable programmer time must be put into making tangible progress, not ornate specs. Your commenting on some other part of our approach would IMO be more valuable at this point.

	06-03-2000 07:46									#44
	Support Apolyton, buy Call to Power 2

Mark:

You're exactly right. I wasn't talking about combat movement. My view is that a unit can move on a road over bad terrain with no penalty, but if it is attacked it suffers the same kind of penalty as a ship in port.

	07-03-2000 01:43									#45
	Support Apolyton, buy Civilization 2

Mark:

It is true that finding qualified programmers is not easy.

But I don't think that is a reason to abandon architecting the system. My fear is that your current approach will allow things to move along until it gets highly complicated. And I was afraid that at that point the entire thing becomes so confused it can fall apart irretrievably. As you've said, as far as coding goes, what ya'll have so far is basically simple stuff, altho a ton of work has been done. It will get much, much more complex. You will have several complex systems, which are going to have to talk to other complex systems. A gui will have to talk to everything. And this can not be done with algorithms -- a comprehensive object hierarchy is your only hope for finishing this. Please take that advice as being worth exactly what you paid for it.

As I've said before, it is your project. I wish I had time to make your project mine, really I do. But life is life. I told you all this up front. As you know, I'm working on other projects as well. I'm sorry. I have gotten the feeling that my input is not proving valuable to ya'll, since most of the people on the project seem to disagree with my focus on a good object design as the heart of any program. So to avoid any more difficulties, I will now to go back to lurking, permenantly. I'll check back in from time to time, but I don't think my comments are proving helping to ya'll.

But one final thing: architecting the system does not mean doing a careful crafting of everything up front. Quite the opposite -- you build an object hierarchy and then a prototype, then refine the objects, then a new prototype, and on, and on. It gives you the demo versions you seek. And the models write themselves perfectly. I really wish I could communicate more effectively my understanding of software development. Ah, well. I truly hope that things work out for ya'll. I look forward to playing Clash someday soon.

Ciao, my friend. Please forgive me if I have in any way made things more difficult for you. May the road forever rise to meet you.

	07-03-2000 03:14									#46
	Full PM-box? Change here!

F_Smith:

I didn't mean to chase you away, just to change the topic. The drumbeat of OO design principles truly just wasn't being helpful At This Stage IMO. So please feel free to abandon your lurkerhood whenever it suits you

Mark

	07-03-2000 19:26									#47
	Got spare money?

Mark:

Just wondering if you have had a chance to look at that "Civ II Evolution" game project that the patron saint posted.

From that page's 'Status' section--

The development will take three stages:

[*]Preparation: The construction of the software framework. A lot of work, but it's virtually done now.
[*]Rules Development: Concurrently implement new ideas, test them and develop the AI.
[*]Modernization: The rules are fixed now. Artifical intelligence and user interface are eternal subject of improvement.
[/list]


So I'd like to make one last stab at this -- ya'll should not be fine-tuning the game rules (the models) yet. Because they will have to hang off of the basic program framework, and a simple framework change can change everything about the model. You can't build a car by asking one person to make the tires, another to make an engine, another to design a body, all with little to no coordination of design. It almost certainly will not work out when it comes time to put the pieces together. I've seen this happen before.

I really believe, from my experience in software development, that this is a seriously important deal-breaker. It can (and has on more than one occasion) ruin a perfectly good project. I feel I'm only trying to save your project. So forgive me if I'm being 'anal' about this. But I'm pretty sure this has to be your next step, if the project is to ever be finished.

	07-03-2000 20:06									#48
	Support Apolyton buy from Amazon

I'm using my gaming alias here, but y'all know me as Paul Crocker I've also returned from my lurkerhood to echo F Smith's concerns. I'm involved in an incredibly complex project at work (government projects seem to always have much more complexity than a sane mind would deem necessary). We're grappling with similar problems - we have contractors around the country developing separate modules for a hardware/software system. A major part of my job has been to coordinate the integration of these modules - and I've noticed that working out many of the small details at this stage is a fruitless battle since core design changes often make these details irrelevant. I'm sure you've much more experience in this than me, Mark, but I just wanted to underline what F_Smith is saying for the others that don't have experience in developing complex projects.

BTW: I also opted out of taking on a major role because of 1) time restrictions,
2) I felt that people were worrying too much about minor details rather than tackling the basic framework (FE worrying more about adding coral reefs, etc than how the whole thing fits together).

When time (and energy) permits, I hope to rejoin the team in a larger role. In the mean time, I'll continue to lurk - and wish y'all the best in making progress on Clash! I still see progress being made - I just hope everyone keeps the long-range focus that's necessary!

	08-03-2000 10:57									#49
	Increase the size of your Attachments

F_Smith:

I know your intentions are good , and I'm glad you're back!

F_Smith and Paul:

Yes I have looked at Civ2E, both before and again recently. Maybe there's a defect in my understanding, but IMO the projects are completely different. They are implementing an already existing and Tested and (somewhat) balanced rules framework. Their approach is quite reasonable for Their project, but IMO Not for Clash. I think their approach is what is generally used in the gaming industry, and you can see for yourself how many Atrocious games come out. We are trying to use the 'Sid' design philosophy of continually playing what you can cobble together to test at all times for fun and playability. Sure there will be lots of wasted effort involved, but this Isn't engineering. We don't know what the framework looks like yet... how can we make detailed object models?

Some people are talking about really detailed things in the Clash models. The only details I'm interested in now is ones we can throw into a demo to see if our basic concepts are Fun. I wish we had more people who were more interested in the big picture and how everything fits together, but that's life...

Perhaps I'm just the wrong person to be thinking about this, but I just can't see how we can plan the software framework before we have some knowledge of the models and their interactions. Thats what IMO we are trying to develop now. But there is a third factor that is not present in the kind of software projects the two of you have experience with. This has to Be Fun. We need to have some small details (just first guesses) to be able to gauge the Fun.

Maybe one of you can outline exactly what you think we Should be doing. The examples so far haven't made a good impression on me. There already are a lot of getters and setters... and putting in more are trivial. I get the idea that there are things beyond that that you are saying. I know we need objects for the models, but you can't envision the objects before you have the model, at least at any detailed level. And keep in mind that whatever the prescription it can't slow things down too much. We need as much continuous obvious progress as we can get IMO.

	08-03-2000 03:07									#50
	Support Apolyton buy from Amazon

Mark:

Actually, it's the other way around.

The gaming industry typically consists of small companies with a handful of programmers and no actual architects on hand (they can't afford the skilled people -- most of those companies don't pay much, and only employ people willing to work for cheap because they love games). And they often end up with 'cowboy' coding as their 'methodology', often with a focus on the single angle they are interested in -- usually graphics.

The few game designers who tend to have an over-arching vision for a game are the obvious ones -- Sid Meier, Blizzard, EA, etc. One perfect clue that a company did *not* do the design well is a lack of customizability. Personally, I think we're trying to keep ya'll from becoming one of those 'others'.

As far as examples, there are several. But one comes to mind almost immediately: the tech model. You have people spending oodles of time on algorithms that won't get used. Developing instances of tech objects that haven't been designed yet. All that work will have to be redone, almost certainly.

You see, first the code framework must be laid out. The specifics of the tech system don't matter yet. Once designed, the framework will be able to handle any tech system you design -- which will allow you to change, tweak, and fine-tune the tech system to your heart's content.

What *should* you do, in my opinion? First, take the tech system as proposed. Break it into objects. Define those objects -- especially the required methods. The functionality in those methods (this is where the algorithms come in) will change later, but it is imperitive to know what the types of behaviors will be! Then code up a prototype, with one or two examples of each object. Then distribute that prototype to people, and let them play with it. After getting all feedback, only then do you begin to worry about the specifics of all the various 'techs'. This gives you the demos you want, more excitement from the participants, a faster development cycle, and on, and on.

Specifically, you have a tech system with 4 levels. Question number one -- are these to be 4 seperate objects? Will some inherit from others? Will some encapsulate others? Are some actually the same object?

Answering just this first question will go a long way. And the choice between inheritance and encapsulation will have a major impact on the shape of the final product.

How do you feel the tech objects should be arranged? Encapsulate or inherit?

As far as fun, that means (to me) that it has to be a well-designed program. Nothing is more of a fun-killer than a poorly designed interface! And actually, ya'll and the Civ2E people are engaged in exactly the same kind of project -- creating a game program. The rules of the games will be slightly different (but not so different as the ones in an RTS, or a FPS). But the rules don't matter, since a good game program framework will be able to handle any rules if it's designed well. The module types that both projects need will be identical. Only the implementations will differ.

	08-03-2000 04:04									#51
	Suffering from ads?

All I can say is IMO before you model objects you need to model the World. How can we define an object hierarchy before we even know what Happens in the model. If we don't even know for sure the car Has tires, how can we define the 'tire' object and its interactions? Before we didn't Know for sure the 'things' or interactions in the tech model. Any generic OO model at that point would have been so general as to be useless IMO. In terms of the tech model Now (but we Just got there) it seems to me fairly simple... Levels 1-3 techs are really the same type of object, and level 4 (applications) is different. Probably the two object types will share an interface since there is some commonality between them. Garth will probably do this shortly. What is the big deal? Richard, afaik doesn't kapish OO programming so how in the heck was he supposed to do the OO part?

However this is all horribly OT. If you want to discuss further, please copy some of this stuff into a new thread... and give it a push.

added afterwards:

I'm sure you can tell I have never had a software class since Fortran . If it helps any Garth is also much more into the code organization thing than I, so your savior may be entering stage left soon.

[This message has been edited by Mark_Everson (edited March 07, 2000).]

	09-03-2000 00:09									#52
	Enter the AD-FREE zone

Mark:

You answered your own question in your first sentence -- ". . . before you model objects, you need to model the world." Model the world in an object model, which has not been done yet for the tech model. You just did that, tho, in deciding that there are two types of tech objects.

As you pointed out, it looks like ya'll have 2 objects required by a tech model -- basically, a 'theory' or 'field of knowledge' object and an 'application' object. This suggests that the concept of breaking the model into 4 levels is a mistake that can limit the models realism.

For a specific example -- what about applications that only require a single, basic piece of knowledge? Does it in fact make sense to require that to be a '4th' level tech object?

Is it possible that a more accurate way to model this might be to have 'application' objects encapsulate 'field of knowledge' objects as requirements? An application can require one, two, four, a million differing 'fields of knowledge', each 'field of knowledge' can have it's own level of specificity.

This obviously gives much more power and flexibility than a static model, and more customizability as well.

This hierarchy supports your tech model, and also supports any changes you might wish to make -- even if you chose to completely re-do the tech model to include magic, or psionics, or whatever. Once this framework is coded, you can go back for game-play reasons and force a 4-tiered structure if you wish.

So the second step, now that you've defined two tech objects (we'll call them 'fields of knowledge' and 'application', for now), is to define their behaviors.

What methods do you think each should have? What behaviors do they have in common? Should they each extend an abstract 'technology' object? Or would you rather use an interface? Personally, I'd almost certainly inherit from a 'tech' object, because that will make it easier to handle them later, in loops.

So, specifically,

[*]What methods should 'field of knowledge' have?
[*]What methods should 'application' have?
[*]What methods should be moved up to the 'technology' abstract class?
[/list=a]

I'll create a thread, and also paste this there. I'll look for your response in the new thread.

	29-05-2000 03:05									#53
	Increase the size of your Attachments

I've had these ideas for a while but never got around to posting them:

I would like to see a realistic planetary map. The cylander approximation doesn't seem right to me. So I experimented with various map arrangements until I fimally came up with the simple idea of approximating the planet with a cube.

A cube inscribed in the sphere of the planet, with the poles normal to the top and bottom faces, should be a simple and effective way of modeling a spherical planet. The shapes are topologically identical and there would be a lot less distortion than any flat map system.

This can be done by defining six square maps and setting rules for how the edges line up. Normally, the screen would only have to display one square and a few rows of the adjacent squares. Scrolling over and changing between the squares should not be too hard.

The four equatorial squares would each cover ninety degrees of longitude and the latitudes from 45 south to 45 north. The two polar squares would cover all latitudes greater than 45.

I think that each of these squares should have a side length of some multiple of ninety. This would allow equatorial squares to correspond to latitudes and longitudes, which would create an intuitive mapping system IMO.

The map editor should allow scenario makers to set the rules for edge connections. A flat map could be made by arranging the squares in a 2x3 grid and setting the outside edges to No Connection. A map of the asteroid belt could be made by creating a line of all six squares and making the two sides connect. Again, this shouldn't take too much effort, and the customizability options would be well worth it.

	29-05-2000 07:36									#54
	Remove this text

I have a better idea IMO. Its based on an old game SimEarth. Basically you have your zoomed map which is flat or can be slanted like now, but what you see on the screen isn't disorted. On the side or whereever you have a sphere of the world with a square on it (can be a retangle since a square is a rectangle). The square doesn't move. It's always dead center, but you can move the mouse around and the globe will spin. We can make it so it doesn't do this too fast. That's not hard. Anway, then wherever you look at on the map nothing is distorted.

	29-05-2000 18:54									#55
	Support Apolyton buy from Amazon

It seems to me that such a thing would be really hard to program. The cube's distortion would be about the same as the distortion of most flat maps.

	29-05-2000 23:21									#56
	Remove this text

I really like LGJ's idea. In fact, it's what I would have liked to have done from the start, but when someone suggested using hexes instead of squares, Mark said that too much work was put into the map already and going back to change it would be too much trouble, so I assumed the same would be said for this idea.

	30-05-2000 17:47									#57
	Get a bigger avatar today!

Hi all. I'm returning from Lurkerhood now that I've managed to get a hold on real life stuff (I had just moved across country and started a new job when I took my "vacation" back in Feb). First, I can add some insight to the discussion on map projections:

We discussed this in incredibly gory detail last year (do a search and you'll see). Since my job involves a great deal of cartography, I might add some insight to this discussion...When you make a map, you can have ONLY two of the following (unless you do it on a true, revolving sphere)

1. True direction
2. True area
3. True distance

Pick any two. We decided that in the interests of coding, and for simplifying the interaction with the map, it was best to have uniform tiles (same size as you move around the map). Sure, the cylinder isn't perfect - but NO projection is perfect (see above). Unless Mark plans on modeling a sphere (spheroid actually). I'd personally prefer an Alber Equal Area or UTM projection, but I won't confuse the issue by pushing THAT one Unless someone can point out a REALLY good reason why we should go to a cube, I'd say we should scrap this discussion and move on to other issues.

Edit: I should add that LGJ's idea is a good one, but it still involves a projection - just one that minimizes distortion when viewed at large scales (zoomed in). You would still need to use another projection to show the "big picture" (ie the whole world on a single map)
[This message has been edited by Mannheim Tanker (edited May 30, 2000).]

	31-05-2000 01:25									#58
	Support Apolyton buy from Amazon

The Clash map is a Cartesian grid. Any map projection that is not based on two mutually perpendicular sets of parallel lines will mess up the relationship between what the player sees and what the computer is calculating, thus making life miserable in any number of ways. For this reason we cannot use equal area projections, a true sphere, or anything that bends longitude lines.

There are two kinds of maps that would work with the Clash gridding system:

1) A Mercator projection
2) A cube

The mercator projection, which is used in most games, has many flaws. Any movement near the poles will be seriously distorted, and moving over the poles is impossible.

A cube would model the planet much more accurately while keeping a Cartesian grid. It would also be relatively easy to implement, unlike most map projections.

I think that the polar movement ability and the greater accuracy of the cube compared to the Mercator map would justify the time spent making the cube map. Also, the six-square approach is a lot more customizable than any other type of mapping system.

	31-05-2000 05:49									#59
	Support Apolyton, buy GURPS/ Alpha Centauri

Richard:

We've already done some of the map AI and its all based on cylindrical maps. All the code has a flat map based on diamond-shaped tiles already. We've just had to lock in more and more as time goes by or we'd never be able to make any progress...

Anyway, We have Extremely limited coding resources. Until we get the first implemetation of most things done, the things that work already need to stay as-is. I agree it wouldn't be all that difficult to make the changes you propose, and I appreciate the thought that went into making something that works by only moderately tweaking the existing setup. But I personally don't really find the improvements in gameplay from your suggestion to be particularly compelling... Its Very difficult to supply an army up where the distortions become quite large anyway.

LGJ:

Cool suggestion. Perhaps Much later in the project we could look at implementing an appropriate transformation. It would probably look really great, and would be useful for jumping large distances in the detail maps.

[This message has been edited by Mark_Everson (edited May 30, 2000).]

	31-05-2000 18:07									#60
	Avatar Enlargement: We've got the solution

On a side note, an equal area "would" work - I use them every day at work. The down side is that you can't view the entire map at once...something that would also happen with your cube-map. In any case, as Mark said, this is a dead issue, so I'll shelve it right here.

On another note, I think I've found something that would work well in conjunction with LGJ's idea: Being able to rotate the map (like in ANNO 1602 by Sunflower Gmbh.) would allows the player to view the map from different perspectives. This works great on a 3-d type map (such as we're doing). Not sure how tough that is to code though... in any case, I think we need to keep LGJ's zoom mode in mind for future work.