Stage 2

[VetLegion]

It seems we have agreed on most important design issues.

So, what we should do now, is work on algorithms. I am working on population & government, but it is not a private area, so write your favourite pop growth, riot or simmilar algorithms, or anything related.

I personally can not concentrate on ten things at once, but if I think of something about other areas I will let you know.

I am checking is my login working, too

[heardie]

Do we worry that the distance to the edge of a hex is 1, then the distance to the corner is 1.25

Using Phythagors Therom (wow, a practical use)
1+(.5^2)
1+.25 = 1.25

And also the distance between two sqaures is
SqRoot(((y2-y1)^2)+((x2-x1)^2))

Actually thhinking now that wont work because that doesnt take into account roads, ocean tiles.

But I know there are heaps pf sites out there about this A* Algorithm

[heardie]

Okay I was gunna be funny and pretend I wrote this, but its wayy to long
http://theory.stanford.edu/~amitp/GameProgramming/

has a great parthfiniding algoritm and pages of notes, implemetnation, etc, etc, for Civ GAMES!!

[TempLeland]

quote: Originally posted by VetLegion on 02-11-2001 06:10 PM It seems we have agreed on most important design issues.

Huh? The way I see it, many important design issues haven't even been discovered yet. The Pop model had its fundamental problems solved recently, but its nowhere near being finished from my point of view. And the government model/demo you're working on, do you have any overall designs on what is it exactly that you are doing? I know there is the group nteraction thing, but it is only a part of the model. And it has not been discussed much (though I blame myself for not comign up with good enough criticism ).

I don't think the design process can be devided to different stages so easily: though we have an overview of the project in the form of a design doc, so far all the models are underway (except maybe for the econ model) and I believe that the algorithms will evolve as the need for specific algorithms is discovered. It's an iterative process, and some algorithms are more fundamental than others, meaning that they pop up earlier in the design process. Cerain algorithms may prove out to be computationally unfeasible, and thus force a change in upper level design. That further solidifies my belief that a good, consistent and a complete models should be our primary goal rather than bits and pieces here and there. But I'm old fashioned.

(Of course, I wouldn't mind reading whatever government/pop algorithms you had been pondering. I just disagree that this is not "stage 2" but rather a first stage of a bottom-up approach. )

Personally, I'm interested in working on the map algorithms (if I ever get the time), but because that's more programming related I'll leave it to the mailing list.

Leland


[This message has been edited by TempLeland (edited February 12, 2001).]

[VetLegion]

heardie, great link! very useful page.

quote: Huh? The way I see it, many important design issues haven't even been discovered yet.

lol

Well, it is stage two for me. I will be narrowing down areas I will talk about and go code.

Since abstract modeling would take forever (for example, one sentence of misunderstanding may take 3 days or more to clear, at best) I will dive back to coding.

Nice number of problems only occur when coding stuff, so more detailed a model is, more painful it is to completely reshape it when coding

[TempLeland]

There are two ways of doing the design: bottom-up or top-down. Both approaches complement each other and I think the best result are achieved by using both. So sure, I have nothing against thinking of algorithms, it's just that we should not fool ourselves to think that the top-level designs are anywhere near finished.

The danger of using only bottom-up approach is that the overall design gets blurred. The trouble with top-down is, as you mentioned, problems which cannot be seen until the feasibility and algorithmic complexity of the design is evaluated (through *really* comprehensive thought experiments or by just coding and seeing how everything works).

I stress the significance of design documentation because once something is programmed, it's very easy to stick with it even if it's not exactly what is wanted. The further the project progresses the more there will be this kind of "junk" and the higher the threshold to reprogram stuff the right way. So your closing argument works the both ways.

(And personally I quite enjoy discussing the meaning of sentences for days. I get enough programming at work and school, design is much more fun. )

Leland

[amjayee]

I agree with Leland, we need both kinds of design. With the design doc, we have already done some top-down design; and that's good, so the game features remain clear for us. Also we have done some bottom-up work by coding some models, which is also good. So I suggest we continue to work with overall design and individual models, at the same time coding some model things so we see how they work in practice.