MapSquare Class OO discussion

[F_Smith]

I'll reply fully in the 'Basic OO design' Thread.

[Beör]

Why not make a new class zone, and have the five _zone integers replaced by a Zones (vector)? This would give flexibility if we later decided to add more zonetypes (I think Mark mentioned the possibility of this somewhere). BTW why did you call it zones instead of sites? The zones should in my opinion be in the terrain object, since now that I've studied the site_concept it is clearly equivalent to natural ressources.

OTOH it might make sense to treat sites as if they were infrastructure. Given the proper tech new sites could be constructed/developed/discovered just like what happens with infrastructure objects. If handled this way I think sites should stay here in the mapsquareobj

Another option is to move the _zone variables to a separate class ProdZones and point to it from here or the terrain object. Then changing the number of zonetypes would only mean changing code in this class and in the economy class (I think)

[F_Smith]

Beor:

[*]The 'GameData' class holds collections of all the game objects -- 'civilizations', 'gamemap', etc. Tonight from home I'll post the exact list of items.
[*]'Extending' a class is how Java handles inheritance. The 'subclass' inherits all the variables and methods of the parent class. 'Canvas' is a class that provides drawing capability. So extending Canvas means that the subclass (in this case, the mapsquare) has the ability to draw itself automatically when added to a GUI object like a 'Frame'.
[*]'M-V-C' is the 'Model-View-Controller' architecture. This is the standard approach to writing complex systems like this. The idea is that all code can be broken into 3 parts --


[*]The 'Data Model' -- classes/objects to hold all the game's data.
[*]The 'View' -- GUI objects to hold and display the data objects.
[*]The 'Controller' code -- game/business logic and program flow code. In our case, the 'turn handlers' and 'IO' module.[/list]
[*]That was a convenience. Mapsquare must have methods 'getControllingProv' and 'getControllingCiv' anyway, and as you pointed out we can either aquire it every time, or just store a pointer locally. That could go either way.
[*]The mapsquares in Demo 4 are stored in a 2d array. I'd prefer to use a collection, but that's up in the air. The code won't care -- it'll access mapsquares thru the method 'getMapSquare(int x, int y)'. But using a collection would also allow us to easily include a method 'getAllMapSquares', which we'll need for turn logic. There is a speed difference, but in testing it was negligible. But this can easily be switched back and forth in the code without affecting the rest.
[*]Yes, so far, the 'military units' object is currently called 'Task Force'.
[*]That is the way it is, with one added layer -- I've put a 'Terrain' between the two. To allow for a mapsquare with multiple 'terrains', later. So a 'mapsquare' "has a" 'terrain'. A 'terrain' has a 'task force'. And 'infrastructure' belongs to 'terrain'. An 'ocean' terrain holds the 'fishing fleet' infrastructure object, while the 'port' infrastructure object can be part of the 'shore' terrain object in the same square. That infrastructure object will have a mobility variable, and a carrying capacity. It can be immobile, as in a Military fort. 'Task Force' objects will hold pointers to the infrastructure they use (forts, tools, weapons, etc).
[*]Absolutely correct, 'Zone' or 'Site' info must be a vector within the 'Terrain' that holds them. And 'sites' are not a type of infrastructure, since they are by definition not improved.
[/list=a]

Did I cover everything?

[Mark_Everson]

Hi All:

F_Smith, please keep the 2d array nature of the map square container . As you point out that and a generic continer aren't fundamentally different. But much of the existing AI code assumes a 2d array, and it would be easier to get it going quickly if that assumption were held at least in the intermediate term. The implementation of a method 'getAllMapSquares' is Absolutely trivial, something like 5 lines, and should Not be used as a reason to decide to go one way or the other!

[F_Smith]

Mark:

We'll actually need methods in the GameData class to do that -- something like 'getAdjacentMapSquares(MapSquare msq)'. It will have to return a collection.

This is actually a perfect example of why we must code this way. As you said, changing the existing map implementation will currently require code changes all over the place.

Well, all that code absolutely will have to be rewritten, I'm afraid, and it's best to do it right away. Saving time up front by not changing it will almost always cost us more time later.

I doubt it will take too long. You can just replace those routines with this simple one --

Iterator it = data.getAdjacentMapSquares(mapsquare_x);

while(it.hasNext())
{
    MapSquare msq = (MapSquare)it.next();

    doWhatever(msq);
}

It should be a simple matter of copy/paste. And that way, all collection code everywhere is the same. And then we can play with a hundred different ways to store the map, without ever having to change the code outside GameData.

[This message has been edited by F_Smith (edited September 26, 2000).]

[Mark_Everson]

ok, sold

[Beör]

F_Smith

I thought Terrain was an object that described various default terrain types (dessert, farmland, prairie etc). I see now that it is in fact the result of a division of the mapsquare into two layers - funny, where did I hear that before? Multiple Terrains - multiple Habitats. No wonder you thought the Habitat thing was superfluous - you have almost exactly the same structures in your code, they're just divided between the Terrain-object, the EG-object and the TaskForce-object you proposed in the other thread. This way it is obviuos that infrastructure and sites should be in the Terrain object. But why not taskforces and EGs then? Why are they in the mapsquare - I should think that the terrain would be interposed between the mapsquare and these objects as well. This may be details, but I would really like to know your reasoning.

BTW I do find the name Terrain a bit confusing (probably a civ2-damage), could we call it something else (no, not habitat ), Surface perhaps. Maybe not so good if we want more than one 'Surface', but how about Location or Landscape. Or Locus (plural Loci) for latin freaks like me? If we were modelling different species of animals I would suggest Ecological Niche or the H-word. This would make it clearer that we are in fact talking of the top of two layers or one of many possible locations in the top layer..

Would there be a point in making a class that holds default terrain types like I mentioned? The class would hold something like: Graphics, default site numbers, movement costs, defense multipliers, and methods for improving the terrain. They would be an option when designing the map. All values could be overridden in every square, and specials would have to be added manually, randomly, by some algoritm or by a combination of the three.

When you are talking about adding a z-loc, this is not a way of making multiple layers, is it? Then I suggest that you name it differently from the x_loc and y_loc. Something like Altitude.

We can make off-map squares in a jiffy, right?

More on sites in the other thread , let's keep that thereBasic OO Design...

[This message has been edited by Beör (edited September 26, 2000).]

[F_Smith]

Beor:

You have a very good point about EGs possibly being in the terrain object.

I'll explain what I was thinking, and why I didn't do that, but I'm not sure I'm right.

'Terrain' objects are not really 'layers', they're actually areas of 'terrain'. A mapsquare can have more than one because a square can have more than one type of terrain in it. For example, a mapsquare can have one 'terrain' object of type 'forest' and one terrain object of type 'lake'.

This is not going to be in the basic game, as I understand it, it's just there for later.

My assumption about EGs was that the people will not be tied to the terrain, but move about freely across all terrains. I only encapsulated things in the 'terrain' object that were specifically related to one terrain/place. So 'infrastructure', 'resources', that kind of thing.

I like 'terrain', to be honest. I think it describes exactly what it is. It will hold all those properties -- it's own 'graphics', movement cost, defense modifiers, etc.

I do agree, 'z_loc' should be altitude. Consider it changed.

'Off-map' squares? We can make them easily, sure. Why do we need them again?
[This message has been edited by F_Smith (edited September 26, 2000).]

[alms66]

It seems that the map code is being rewritten completely here so I'd like to make a suggestion that I had made previously, but it was rejected:

have a "donought" shapped world ala, CTP

we can easily skip the realism issue of traveling over the poles, as they did. I just find it makes more sense to be able to travel east-west and north-south, rather than only east-west.

If this is totally undoable do to AI problems or translating current code, it's cool, it's just a suggestion.

[Lord God Jinnai]

That's the way it is with all of them and i really HATE that approach. Anyway i think some of the people doing Openciv3 were trying for a way similar to my suggestion i posted earlier, but i dunno and i also dunno if any of the coders here would be able to convert it either, but plz, lets go beyond the donut shape which is used in all the civ games.

[Richard Bruns]

Is it possible to add the cube option? Six normal flat maps connected at the edges would make the world look and act right. Distortion would be minimized and accurate polar movement would be possible. And the AI should be fine since we are not really changing much. The AI would just see this:

_O
OXOO
_O

and it would be undistorted so the flat map AI should do just fine for determining the best path to a place on the other side of the world.

[F_Smith]

Any map layout that identifies mapsquares with an x and y coordinate will work.

If ya'll are just thinking ahead, great. But that stuff has to wait for later. We'll just be working with a square map, for the very first alpha prototype.

[F_Smith]

Mark:

If you're talking about looping thru all the mapsquares in the code, then we really should use the 'getAllMapSquares' and loop thru whatever collection we decide to have 'getAllMapSquares' return. It is considered a big faux pas to require the code outside the Map to have to know how the map is stored. All you should return is an 'enumeration' or 'iterator' of all the mapsquares, so that looping thru this collection isn't any different from any other collection. This will make it much easier on the programmers, and eliminate a big potential point of code failure.

We really should not have the code do a --

for(int x=0; x "less than" mapwidth; x++)
  for(int y=0; y "less than" mapheight; y++)
    doXToMapSquare(mapsquare[x][y]);

That's completely unscalable. That should be done with a collection, derived from the GameData 'getAllMapSquares()' method. As I said, which should return either an 'enumeration' (Java 1.x) or an 'iterator' (Java 2).

Java 2 makes it easy to get an iterator from a multidimensional array, so it won't be a big deal if yo want to store it that way, but I don't see the point. And using an actual collection allows us later to scale the map for non-square 'mapsquares', Risk-style.

P.S. -- It wouldn't let me use the 'less than' sign, above, so I just wrote it.
[This message has been edited by F_Smith (edited September 26, 2000).]

[Mark_Everson]

F_Smith:

No, its not for that... Its for looping over neighbors and next-nearest neighbors of squares etc. And again, this is only a medium-term issue. At some point in the future it will all be rewritten to be more flexible. But it could make a month's difference in getting a crude military AI going if I need to start from scratch not using the 2d stuff.

[Beör]

Do you know the feeling: Click 'Submit reply', and get the feeling that something you said weren't accurate or that something was missing. I had that feeling last night re the position of taskforces and maybe EGs.

And of course F_Smith put his finger on it, before I had a chance to redeem myself: I knew he would.

While having TFs and EGs in the terrain when there was just one terrain made sense, having more than one terrain changes things. If TFs were kept in terrains then the player or the AI would have to decide where to put a TF when it was created or moved into the square. Imagine a square with two terrains: A city and the surrounding plains. It is like them old board games where you had to decide whether the 5th cavalry brigade was inside or outside the fortress of Ulm. If they were outside you placed them on top of a fortification counter, If they were inside you placed them beneath the counter. AND I ALWAYS HATED THAT! I even remember games where you had to consider whether to keep the units by the banks of a river or move them further inland. While it made for realistic gameplay with sieges and specialised bridgehead combat, it was not very playable to say the least, And the same thing goes for EGs: We really don't want to micromanage where in the hex they are at any given point in time. So lets keep TFs and EGs in the mapsquare.

But that brings me back to infrastructure and rivers. Do we really want factory to be present in one terrain but not in another. And rivers: If there are rivers in both terrains flowing NE, what does that mean? Or we could have one terrain linked to the neighbouring sqaure by a road while the other is not. Since many infrastructure objects will interact with either EGs or TFs, they should probably be where they are - in the mapsquare.

If we decide at one point to include more than one terrain in a square, I think that EGs or TFs should be allowed to choose the terrain effects that are most beneficial to them in a given situation. After all one turn in the default scenario equals one year - so it is reasonable to assume that they will have the time to do what's best for them.

Thought: It would however be nice to have sieges. Defenders behind the city walls, attackers in the surrounding terrain. Maybe we could have the player/AI choose if he wants to enter the city, when a square with city-terrain is attacked? Have a fieldbattle or face a siege?