MapSquare Class OO discussion

[Lord God Jinnai]

One thing I still have a problem with is the percentages because I believe this will cause people to haveto micromanage each square to make sure they are getting the most out of every percetage possible. This also tends to detract from what the tile itself is suppose to represent, a broad generalization of what is in the area. Sure its not going to be 100%, but what Beor proposed is I think too much. I'm only saying this because once again I believe you are getting too detailed here and we want to stay away from getting too detailed if possible. I don't mind there being minor variations posibble for the edges, but the tile iself should represent a signifigant and therefore overwhelming representation of what will be possible within the square. If any variation is possible it should be based on the surrounding tiles and be at most 10%, thus not enough to warrent extreme micromanagment of each tile.

[Beör]

LGJ

This is programming - not gameplay. In my opinion the player should rarely have to deal with these different locations - and in the default scenario. not at all. But if we want to be able to do it the object-model should be geared to handle it. Even the max 10% you mention require an objectmodel of this sort. Actually the Terrain type and Groudn Cover type objects are both ment to minimize micromanagement even from the scenario designers point of view. By doing it this way, the scenario designer would only have to genertae a general map, and then pinpoint some differences from the typical.

[Lord God Jinnai]

I know this has to do with programing, but the way you are planning to program it has multiple terrains per square such as mountains, forested hills, swamps, plains, etc. which cannot be easily done without making tons of tiles which i doubt you'll find too many people willing to do, and the majority of the people will look for the tile itself to display the overall, ie clear and signifigant majority of the landtype for that square, something that your model by trying to be more realistic doesn't seem to be caring about.

[F_Smith]

Hi, Guys:

Um, 'groundcover'? I'm not sure that works, to be honest. Can't much spend time thinking about it right this second, tho.

The basic game architecture is in place, and ready.

I've defined all the classes, put them in packages, jarred them all up, and now I'm building the GUI. The GUI is coming out far better than I had hoped, too -- the 'Java2' classes called 'swing' have really helped to no end.

So anyway, we should be able to start running a few test cases after tomorrow nite.

For the moment, it'll be the previously mentioned 'mapsquare'/'terrain'/'resource' and 'infrastructure' hierarchy.

So don't think I've vanished permanently -- I'll be here to chat this stuff up again.

[roquijad]

Some questions:

1) Are you guys considering to split infra into immobile and mobile? If so, where in the data structure mobile infra would be?

2) What's the gain in game terms about having mapsquares with more than one terrain?

3) I know the thread about animals (horses, elephants, etc) was put on hold, but maybe this is the time to think where they should be in the data structure. Any thoughts?


Congratulations to you all on your job. Things sound reasonable so far!

[Beör]

LGJ

I have the same concerns as you have regarding the interface. But, as far as I can tell, all along it's been planned to have more than one location in a square: Particularly it was supposed to be possible to have units inside or outside a city. The object model we are constructing at the moment is really just a generalisation of this plan. It makes it possible, but not mandatory, to have these multiple locations. Most probably the default game will not make use of anything but the most primitive of these facilities.

So, why bother?

Because it helps defining the underlying object structure, making the scaling of the game a piece of cake. It gives structure and flexibility to the code. The relatively small effort will repay itself several times before we've got a finished product

Back to the interface. This is probably the major practical problem associated with multiple locations. How do you render a square that is 50% lowlands (partly grass, partly forrest), 25% hills (almost entirely forrest) and 25% mountains (barren). And how do you make it clear that this square has a different site composition, different combat modifiers and different movements costs from the neighboring square, where there's 45% lowlands, 35% hills and 20 % mountains of the same vegetation compositions. The difference in resources has to be handled anyway, because of the ecology model. This model will give very different outputs for squares that have exactly the same terrain: Production depends on terrain, water resources and climate. There's room for creative thought here. In the default game I think there will only be one terrain + one vegetation + maybe a city. And this could be handled by using the usual approach of showing the basic terrain + a city icon.

Now I'm just throwing some wild ideas as to the rendering of the map with multiple locations. As far as I can see the combined terrain and groundcover will mainly have interactions with the player in the following areas: Movement, Combat, Production, Beauty. When a player looks at the map he is interested in: How far can his units move, how well protected are they in case of attack, how much is produced in a square, and is the map artistically beautiful (this last part should not be overlooked: Playing an uggly map will quickly break even the most enthusiastic Civer). The problem with multiple locations is that what's important in one of these areas might not be important in another. The movement cost might be decided by the grass-lowlands, the combat by the forrested hills, the production by a combination of all terrains, andd the beauty by personal preferences. Maybe we should have parallel maps, one for movement, one for combat, one for production, and a beautiful one. A little like the variuos maps in SimCity (land value, crime, police cover pollution etc). Another possibility is small icons or signatures along square sides designating various forms of info.

What about the micromanagement with multiple locations- if we decide to use them. We've discussed it a little bit in this thread, and I think there's a general agreement that it should always be possible to play the game without having to decide which of the locations in a square a unit is in. The AI should handle the positioning of units on an as needed basis. If it doesn't matter wher the unit is, it will just be in the mapsquare. You could also say that it is in all locations at the same time, and if needed one of these locations is chosen by the AI - or optional by the player.

The same goes for EGs, who most of the time will just be in the mapsquare.

Infrastructure is a little more tricky, since some kinds of infrastructure only fit in some of the terrains present (shipbuilding in the Himalays). If the infrastructure is only allowed in one type of terrain, there's no problem: It will just be placed there when built. But if the infrastructure is appropriate in several types of terrain a choice has to be made. Most of the time this could probably be handled by the AI, but sometimes the player may have to be asked. This problem might not be so great if the no-buildings approach is adhered to strictly.

Assuming the no-buildings approach most likely will be placed simply in the mapsquare (I think?!), the handling of multiple locations gets much easier AI-wise. Otherwise, the AI would have to take fractional squares into account when deciding what should be built where. Of course the player would have the same difficult decisions to make.

[Beör]

BTW did y'all notice that when there are multiple, different-sized locations in a square the previuously abolute number of sites becomes relative: a site density. So we're really stuck with a landyield-per-acre kinda measure. Funny how things turn out in the end.

[Beör]

F_Smith

I'm not saying it cannot be done from a programming point of view- off course it can. It's relatively simple using the approach you have proposed. What I am a bit worried about is how to cram so much information into such a little space, and have the player comprehend it. This is really not an OO subject, rather a graphical one, so I suggest further discussion on the subject should be done in another thread.

IMO it is not a pressing demo5 issue, so we can do that later.

Had a look at your working prototype. It's a bit slow, but otherwise very nice - unless it's supposed to do anything, other than handling the three windows.

All

We've mentioned infrastructure objects quite a bit, and given lots of tangible examples. But IIRC the infrastructure model is more on the line of no-buildings, where infrastructure is modelled as infraclasses. Are we going to have a dual approach here, making the object model capable of handling both?

[F_Smith]

Beor:

I had noticed the slow speed, too. It's those swing components, 'JInternalFrame'. The repaint on them seems very slow. Altho I'm not double-buffering the images yet, and haven't over-rided 'update'. So I know a few ways to handle that. But I'm only drawing a simple rectangle in each square . . . if worst comes to worst, I won't be able to use these 'JInternalFrames'. Altho that would be too bad, I think they look pretty good, and would make gameplay a snap.

That's all there is to see, right now. Check again about midnight my time (central standard time).

P.S. -- I was under the impression that the 'no buildings' infrastructure classes were in addition to the necessary infrastructure classes that *have* to be on the map (roads, forts, factories, etc).

So the 'infraclasses' are, I thought, on top of the 'infrastructure' objects we're talking about.

[Mark_Everson]

F_Smith:

Roads and forts need to be explicit objects. Factories are infrastructure that will be handled in the standard system with a no-buildings infra approach. Why would factories *have* to be on the map?

I second Beör's comment about trying to cram too much on the map, and as he says its really a graphics, not an OO issue. There has been some talk around these ideas already, some of it going waaaay back. So when we get to it we should discuss it in a grapics/interface thread.

Will check out your toy when I get a chance at home. (At work now)

[F_Smith]

Mark:

As it currently is, 'roads' and 'forts' are explicit objects -- subclasses of 'infrastucture'.

I was just assuming 'factories' would be also. This might be my mistake. I was thinking that a 'factory' had to be something the enemy could destroy (or possibly capture?). So I thought it had to be on the map.

I do agree that other people should determine what goes on each map 'view'. There will certainly have to be a bunch of different 'views' or 'looks' for the map, 'Caesar3' or 'SimCity' style. You'll have to be able to view all the resources in a square, all the military units in a square, all the economic output of a square, etc. This can be done in a variety of ways, of course, from numbers and text to layered grafix.

As you said, it's a grafix issue, not a programming one. Because certainly we shouldn't restrict the detail in a game function?

I think you'll like the JInternalFrame look, by the by. I'm trying to duplicate your original 'Clash' gui. More on that tonight, tho.

Right now, I've got to figure out exactly how to 'componentize' an isometric gamemap. That is *not* turning out to be easy . . .

[Richard Bruns]

I couldn't get the prototype to do anything, but it looks like a good setup. I had to resize my desktop to fit the thing in, however. We need to think about how to handle different desktop sizes.

Could you leave the option for displaying normal squares? There are a few times where they are better than isometrics.

[Mark_Everson]

Richard:

Once a map is designed for isometrics it looks bizarre as squares. If you are happy with diamond shapes, then that can be done easily.

F_Smith:

Tried out the toy. The general layout looks ok. IMO the frames need to be resizeable, tho I'd guess that's just a detail. Took about 30s to download, and not very long to run.

On factories... Sorry I didn't get your original meaning. Lets back up a bit. All infra is associated with a mapsquare (or I guess some part of it), so I don't understand the distinction you were making between roads and the no-building infra, like educational infra. At least in the current model, factories are the capital associated with the production sector, and not technically infra in the model at all. But 'factories' can be strategically bombed etc since capital in the sectors is also associated with a square.

All no-buildings means is that the infra is not built in big all-or-nothing lumps like in civ. That means you don't get the big non-linear effects you get in civ. Roads are pretty much all-or-nothing, although they should be in several flavors (packed dirt, cobblestone, etc) so they are indeed discreet like buildings are in civ.

[F_Smith]

Rodrigo:

[*]Yes, 'infrastructure' objects will have 'mobility' variables. So in the data structure, 'infrastructure' (both mobile and stationary) will be stored in 'terrain' objects (which are in 'mapsquare' objects).
[*]Mapsquares that must have more than one terrain type, like a coast (part ocean, part land). Like the edge of a vast desert. Also for terrain contained within a mapsquare which isn't the 'base' or 'main' terrain -- Like a desert square with an oasis. Or a prairie square with a lake. That kind of thing.
[*]'Horses' and other animals will be 'resource' objects, stored at the same level as 'infrastructure'. So a 'terrain' object holds 'infrastructures' and 'resources'.[/list=a]

Just off the top of my head, anyway.

* * *

Beor:

I'm confused -- what's the problem with the interface?

Had planned to use a standard 'layering' approach which is used in games -- the terrain with the largest % will be the 'base' terrain. We draw that terrain graphic first. Then other terrains get drawn on top, one after another. Then the 'resources' get drawn. Finally the 'infrastructure' gets drawn.

There are a number of strategies we can use to organize this in the mapsquare -- four corners, etc.

Just like 'the beast' -- I drew the basic terrain (just a green or blue square), then draw the 'vegetation' (stupid little squiggles suppose to be trees), then draw the 'infrastructure' (the little 'castle' line drawing), then drew any task forces. The graphics have 'transparent' backgrounds, so they can be layered at will.

I do not see a problem with micromanagement. I think in practical use the AI will always be able to determine the best disposition of a unit.

If a square has 'forest' we overlay a 'forest' graphic

[F_Smith]

Richard:

It'll detect screen size, when done, and adjust itself accordingly. Sorry about that. That's life in development.

Mark:

Yeah, that's actually just a paramater I set to false, as it. They can be resizable, maximizable, minimizable, etc.

Okay, I'm sorry, but I need more clarification on this.

I don't fully understand -- and I'm coding exactly that part next (whenever I finish this IsoMapPanel). Please be patient with me!

Give me a 'test case' kind of explanation -- the player is going along, it's his turn. He wants to build an airplane factory to build fighter planes. How does he do this?