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:

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.

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

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.
  

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.

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

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.

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?

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:

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,

1. What methods should 'field of knowledge' have?
   
2. What methods should 'application' have?
   
3. What methods should be moved up to the 'technology' abstract class?
   

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.

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.

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.

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:

I think I have already mentioned the only thing that is really locked in by the map AI, which is that the map should be cylindrical. MCA, who did the coding for the previous model, disappeared a long time ago, and the links to his site with the code are no longer functional. It is possible that Paul Crocker or Henrique Duarte have copies of that.

Actually, given that you are interested in learning Java, I think going ahead learning how to program, and getting the technology model going is vastly more important to the project than anything you could possibly do in this area. IMO this model could lay dormant until well after demo 5 is out and it would not hurt the project one bit. Whereas getting the tech model basically up is one of our vital issues.

BYW, Mark:

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

I recently joined the Clash Project and volunteered to code the Map Generator. I chose it, because it is not so tightly integrated into the project and I am not so experienced in Java, yet.

Since I agreed with Mark to start the whole Map Generator anew, I think I will begin with coding a heightmap generator, using the model depicted at the beginning of this thread, or something similiar. After having calculated the height of each map tile one could set the "water height", resulting in every tile with lesser height beeing covered with water. I might do it so, that you preset the percentage of the surface of the world, which should be covered with water, and the model derives therefrom the necessary water height.
Determining the ecological properties of the map tiles would follow thereafter.

I do not know yet if I can do it that way, but what do you think about it?

--------------------------

Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to build bigger and better idiots. So far, the universe is winning.

Well, the person doing the work gets the most say in how things get developed. So why don't we think about this for a bit, and then we can decide what the best direction to go in is. I'm going to try and get into contact with Paul Crocker, and see if I can interest him in contributing to this discussion.

On the continents looking too geometric, I raised that issue before with MCA, but he assured me that that was due to a bug (or perhaps lack of refinement in the code). I think another problem may be with initialization. By starting everything as a big continent, fracturing it, and only letting it evolve a bit from there, you will tend to get compact things like are shown in MCA's examples. It may be much better done with a cylindrical map with a few large starting continents.

So I advise giving this a few days to talk over before we make any decisions. But you could certainly investigate other possibilities during that time. You could also try some simple modifications to MCA's code along the lines of what I suggested, or let it evolve longer and see if it doesn't look better.

I heard from Paul on the subject I posted above. He's really busy so he thought it might take a bit for him to get back to the forum. But he said that mca's code output has many limitations that are simply the result of not enough iterations and other factors. So pending Paul's re-emergence I'll again suggest that playing with the old demo code with more iterations or different initial landmass distributions seems valuable to me. BTW, It looks from the results that the map may not be cylindrical either. That would be another thing to look into changing, since plates might tend to spread out more given the extra freedom.

What do you think?

Hi LGJ:

I understand working on the cylendrical first, mainly cuz its easier since its been done before. I'm just saying that if clash is going for realisn where it doesn't interfer with player fun, i don't see how my idea interfers with it as it would be totally optional.

Since I will rewrite the whole Map Generator I will change a few things, that aren't ideal in the old code. But I'll stay with the concept from the beginning of this thread.

--------------------------

There are a few flaws in your last statement, but nothing to worry about for game dynamic purposes. Its just that when attempting to model plates like that, you must also be aware of the fact that the magma also can suddenly (in geologic terms) switch directions, even 180 degrees and also do so mid-plate so you'd have 2 smaller plates.

Ok, the way I described it was a bit oversimplyfied. I dind't want to go to the extend as you described it, I just liked the general idea. I definetley don't like randomly moving plates.

All:

I actually started coding yesterday and I'm slowly getting a grip on Java. Swing is still a little unusual to me, but I'm getting along. I hope I have something to show the people, tonight. Though it will only model the height of the tiles, and it uses only simple models. But from there it shouldn't be to hard to add some water to get land and sea. And then an ecology simulation can start, determining the type of the tiles.

Do you like the quotes I add to my posts, or do you think I should stop adding them? Just wondering...

--------------------------

Personal Web pages are the '90s equivalent of home video, except that you don't have to visit someone else's house to fall asleep - you can do so in the comfort of your own home.