02-10-2000 05:00									#61
	Increase the size of your Attachments

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.

	02-10-2000 16:21									#62
	Inflate your Upload Space

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.

	03-10-2000 02:13									#63
	Support Apolyton, buy Galactic Civilizations: Deluxe Edition

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.

	03-10-2000 07:19									#64
	Inflate your Upload Space

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.

	03-10-2000 10:50									#65
	Support Apolyton, pre-order Civilization IV

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!

	03-10-2000 15:41									#66
	Support Apolyton buy from Amazon

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.

	03-10-2000 18:23									#67
	Support Apolyton buy from Amazon

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.

	04-10-2000 09:01									#68
	Support Apolyton, buy Civilization 2

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

	04-10-2000 09:22									#69
	Browse Apolyton AD-FREE

P.S. -- if anyone wants to keep an eye on coding progress, the working version will be kept Here.

This is a glance into the internal development of a piece of software, so if you're expecting polish and shine you'll be disappointed. But feel free to make any comments, just don't be too harsh in your judgment, not yet. There's a fully working datamodel underneath, you just can't see it yet!

But you can get a look at the style of the GUI I'm building. I'm working on integrating the 'real' map grafix right now.

	03-10-2000 23:41									#70
	Help yourself to an AD-FREE life

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?

	04-10-2000 00:34									#71
	Suffering from ads?

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.

	04-10-2000 02:48									#72
	Remove this text

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)

	04-10-2000 03:49									#73
	Support Apolyton, pre-order Civilization IV

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

	04-10-2000 05:20									#74
	Increase Your PM Length

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.

	04-10-2000 05:56									#75
	Put an end to popups!

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.

	04-10-2000 09:11									#76
	Support Apolyton, buy Galactic Civilizations: Deluxe Edition

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?

	04-10-2000 16:06									#77
	Remove this text

re m-v-c and map squares

im no expert but this is my view on the subject,

first pure m-v-c is hard to find , I think controller is a bit of an ambigous term and is not always easy to seperate from the view

i would agree with marks post on objecting to squares extending canvas ( not that im involved in the project , yet) .

re: jtable and m-v-c

data objects should not draw themselves, A model contains or knows about data, and the view draws the model. in a jtable the TableModel knows about the data (leaf/nodes) as represented by seperate objects/primitives, it is the renderer that is responsible for the actual drawing of the data( and there can be multiple renderers, one for each column , or even cell). the TableModel does not know how to draw itself, it knows things like how many columns the data represents, but leaves it to the renderer to actually draw each column/cell, it is this renderer that will extend a visual component( eg JPanel , JLabel etc), not the model and certainly not the data. Note that the model does not even know about renders, they are registered with the table not the model, you can change the renderer for a model on the fly, getting different views of the same data.

I would class the parts as follows
JTable = 1 part of view ( and controller in that it reorders columns etc)
Renderer = other part of view
TableModel = model (contians data ) ( also controller, in that table sorters are implementations of models, plug a sorter between THE model and the table)


If mapSquare extends canvas then this is not possible ( or much harder ). consider the diffrernt views of a square, the obvious one is when it is just a square on the main playing map, but i may be able to select a square for a more detailed view the square, this appears in a differnt window which gives more detailed information in a totally different display format. both views however are looking at the same object - the square.

I went down the route of squares extending panels when i first got into OO game writing and regretted it , believe me it is better to divorce the view/gui from the model/data. having the map square extend some visual component will make it hard to make changes to the way the game model and the game view work.

Although i'm not sure it is the best way, i currently work with a front end that observes the model, the model fires changes to the frontend which decides what to do based on the change, if a map square has altered then the model passes the square to the front end as a parameter when it fires the change off. the view can then change the display of just that square if it deems it necessary. different views act as observers, each displaying the square ( or whatever ) in their own way, eg the main map view , the detailed square info view etc

	04-10-2000 17:19									#78
	Avatar Enlargement: We've got the solution

Hi Puree, welcome to the forums . The more minds we've got working the better, especially ones that happen to agree with me (and can back up the position better than me)!

F_Smith:

Building an airplane factory, etc.

As a design issue I don't want to get into hundreds of dedicated facility types to build different things. I don't think the player gets much out of it. And it makes the AI's job that much harder to site all these things, balancing threats against ideal production locations etc. Now your OO model can have it the way you picture it, so long as it can accomodate whatever agreement we finally reach for the standard model.

I had intended to handle everything abstractly but ports/shipyards which pretty much Have to be in sensible places. By abstractly I mean that production capacity is plain vanilla production capacity, and can be re-assigned at will to produce whatever. The current plan is to have two modifiers of this simple scheme to get some important real-life features in the model. The first is to have a production ramp-up when you are building new things. Take last turn's production of fighters and call it X. You can build up to X fighters this turn at the base cost for fighters because the factories are already in place. Any more than X up to 2X would cost double. That's because you are reconfiguring factories and building the new planes. 2X-3X would cost quadruple, 2^(lower multiple, 2 in this case). This mechanism of course introduces nonlinearity by itself, but I think we need something like this to prevent countries switching over to total war production from peacetime production in a single month. Perhaps just a smoother function would help. The second modifier might be one awarded for 'centers' of production for certain things that could get arbitrary bonuses. A certain city, because cannon foundry and related industries really took off there might be able to make cannon for 2/3 the usual cost. This would be handled as a special just like iron ore.

	04-10-2000 18:37									#79
	Tired of ads?

Puree:

Hi! Glad to have your comments, I need all the help I can get on this.

We are using observers too -- I think it is absolutely the right way to go about it. My comment above about a mapsquare 'redrawing' itself was a reference to that, in fact. I was speaking about 'functionally' redrawing itself -- in other words, the square is redrawn when the data changes and the data object fires the 'hasChanged()' method. The use of extending Canvas was simply a convenience, since otherwise the data object will have to have methods to define what gets painted. Extending Canvas provided all the methods I would otherwise have had to add -- getMinimumSize, getMaximumSize, paint, update, etc. I then used the 'MapSquare' in exactly the same way you'd use a 'ListModel', adding it to a 'MapPanel'.

The way I seperate the 'data model' and 'view' in my mind is that the 'data model' holds the information on what gets painted, while the 'view' component paints whatever the data model defines. Does this seem right?

* * *

Mark:

I'm sorry, I still am not clear. More stupid questions to ask. I'm going to have to build a Gui with this functionality, so I probably better ask questions until I understand it!

So --
When a player has just learned how to build fighter planes, how does he go about building them? Is it 'SMAC' style, where he can build those at any base? Including a 'prototype'-style first-build cost?

Can a player can build airplanes at any of his mapsquares? Or just in his capitals? What about 'specialization'? Can a player 'improve' his fighter plane factories seperate from his other industry, not counting new technologies? Do I understand correctly that a 'factory' can't be specifically destroyed/sabotaged/dismantled and moved on it's own? Is there then a 'factory' object at all, or just one 'infraclass'? If no 'factory' object, is there any specific game representation of a squares industrial capabilities?

It sounds to me very much like the 'SMAC' system. If I code along those lines, will I be close to what you want?

	05-10-2000 01:29									#80
	Support Apolyton, buy Civilization 2

I know I should contribute to this thread more often, specially since infrastructure is already discussed in here. But I am really overwhelmed by the new semester that has just begun. It has left me timeless and exhausted. Some brief comments though:

Whenever this is required by a certain model, the generic infraclasses can be related to specific objects. These can be military units, wonders, even the civ2-styled city-improvements. See the infra thread for further explainations - I know that since you are discussion the OO structure of the game here, this is the best solution. Only if this approach is in contrast with some model features (f.e. Mark dosn't like military units having logistics based on # of "shields" that the unit costs) should we detach the cetrain objects out of the infrastucture system (this can be claimed for food, kapital and military units).

About factories (or the kapital infra units) being specialised to a certain type of production, I think that we could add a nonlinear factor to input cost of infra units, one that depends on the difference between this and the previous turn's input. The same can be done with the infraclass unit costs of all real infrastructure objects that we will decide to add. IMO this is easy enough.

	05-10-2000 02:30									#81
	Lose 30 kilos (of popups)

The mapsquare is the model of an area and everything in it, ie. it knows directly or indirectly what the terrain is , the units in it the cities in it , the resource values etc etc. It has absolutely no idea of how it will be displayed, nor does it know which data elemnts will get displayed. From that point it does not represent what will be painted, however what gets painted will ( one would hope ) will be based on the mapsquare and its data. the model should not be defining nor constraining what gets painted.

the methods you mention : getxxxSize, paint update etc, should not be in the model ( mapsquare ), even the min/max size are not part of the models responsibilty, they belong in the view( each view may have different size constraints). the view should be working something along the lines of not production code, just idea of the process )

if( square.getTerrain().equals( "forest" ) )
{
// paint some image , its size based on factors
// that square knows nothing about nor cares about
}
if(square.getArmies() != null)
{
// paint some army image over the terrain image
// may paint one icon no matter how many armies
// are in the square or paint a stack of armies
// but again this is view dependent, the model
// nether knows nor cares
}
if(square.isSelected() )
{
// paint white border round square
}

..... etc

another view, eg the detailed square information view
would have different code, it might go

if(square.getTerrain().equals("forest") )
}
// display in different window a big image of a tree
// and paint in the corners the resource values for
// forest ( or the squares resource values )
}
if(square.getArmies() != null )
{
// get a collection of the armies, and for each
// add a panel in a scroll pane , and paint on the //panel an image specific to the army, with its //combat values
}

// ignore selected value

.... etc

the important point is both views are referencing the same mapsquare, one view is ignoring half the data, the other uses it all but displays everything in a different way.

also important is that the code for each possible view is in a different class, I may be wrong but it looks like extending canvas would mean the various views are coded in the one paint method!.

extending an object should not be used to save time coding some methods, short term gain - long term problem, the data for a mapsquare is not a type of gui object. code the extra methods you need ( but not the ones you mention )

if you decide to change the view ,e.g. dont like the scroll pane put the armies in a table , then nothing needs to touch the model ( or its sub/superclasses ) only that specific view needs changing.

the swing components you mention ( table list tree etc) dont work the way I think you are saying, JList contains a model and a renderer, the renderer paints the various elements of the model. the model does not extend any nor contain any visual component , and knows nothing about renderers as they are registered with the JList not the model. the list pulls out each element of the model then passes it to the renderer, which can do what it wants with the object representing the element after which it returns the component ( the jlabel in the default ) to the Jlist, which then paints the component. ( i believe the default renderer is a JLabel with the toString() method of the element displayed on it , but ive used JPanels painting icons depending on the class type of the value object, and text for the data )

	05-10-2000 02:36									#82
	Enter the AD-FREE zone

cool, how did that (not)smiley get there,


ps TheadInterruptedException in my orignal post, tables dont deal with leafs/nodes, i had been reading up on tree structures and the reference to them must have slipped in to the table thread of thought

	05-10-2000 03:32									#83
	Increase the size of your Attachments

Hi, Puree:

I was thinking more along the lines of the code in the view (class IsoMapPanel, in this case) saying --

code:


public void paint(Graphics g)
    {
        Iterator it = gamemap.getAllMapSquares();
        
        while(it.hasNext())
        {
            MapSquare msq = (MapSquare)it.next();
            
            if(mapSquareOnScreen(msq))
            {
                if(view_selections.viewTerrainOn())
                {
                    paintTerrain(msq.paintTerrain());
                }
                
                if(view_selections.viewResourcesOn())
                {
                    paintResources(msq.paintResources());
                }
            }
        }        
    }

	05-10-2000 04:26									#84
	Remove this text

no the model should have no grapgics data, just the data of the objects it contains - terrain, armies etc
( your earlier posts had a model of sorts for what a square would contain ).

this is how jtable ( and list etc work ) as well, the model contains no graphics details at all. the getcolumnCount() etc are not graphics data, they are there to provide anything using the model with basic info what the model contains. the model can say to anything else i have 10 rows and 5 columns, this is not graphics/view data, just as saying i (square ) contain 5 armies, 1 city and a river is not graphics info.

In a jtable the table view takes the counts to paint the basic frame for the table and then asks the model for each cell value in turn(which could anything practically, model.setvalue takes an object), passes it to the renderer which passes the table view back the component (to paint at the appropiate position)

analogy, mapsquare has methods like getArmies , getTerrain - but these return collections or Strings or Terrain data not graphics. the view ( say MapView ) asks the mapModel for each square, which it passes to a square renderer, the renderer passes back a component ( canvas ?) which the view uses to visually show that square.
The renderer will create the 'canvas' then paint what it needs to on it before returning it to the view, this is done by calling getTerrain , getArmies on square and painting grahics accordingly, ( the renderer will probably be what extends the component, so its painting on itself )

There can be multiple renderers all dealing with square objects, MapView might use different ones at different times or other views unrelated to mapview might use other renderers eg the DetailView uses a different renderer which returns a JScrollPane displaying a scrolling list of everyitem in the square.

Possible renderers could be
UnexploredRenderer - which just returns a black fill

MyEmpireRenderer - returns a 'canvas' with piccies of the armies latest city size etc,

OtherPLayersEmpireRenderer - returns piccy of city size but not the armies displayed,

ExploredButFogOfWarAppliesRenderer (well not a name that long but you get the picture) - returns piccy with a tint over it

If you wish to display the unexplored squares differently from last version just change UnexploredRenderer, the model does not need any changes, nor does the master mapview

The renderer does not have to return a component , it might return an Image instead, depends on how the Graphics are being done, everything one one JPanel , or a panel per square ?

The renderer only needs one method

public Component/Image(?) render ( MapSquare square );

(plus any other parameters deemed necessary)

add its noddiest the MapView has some method to "paint" itself like this :

public void display()
{
setLayout( new GridLayout(x,y) );
removeAllComponents();
SquareRenderer renderer= new SquareRenderer();
MapSquare[] squares = map.getSquares();
for ( int i = 0 ; i {
add( renderer.render( square[i] );
}
}

wouldnt set its layout everytime ( once in constructor will do , but again you get the idea)

P.S im not a graphics guru , but i dont think you should use a canvas or panel for each square, the renderer should return an image which the MapView paints at the correct point - saves on memory for one thing, saves on performance cos less object creation going on , and makes it easier for displays which arn't totally square based ( ive not tried sometric 'diamonds' on seperate panels but i doubt its that easy )

	05-10-2000 05:00									#85
	Support Apolyton, buy Civilization III: Complete

Puree:

Your input is being *very* helpful. Thank you so much.

I'm a database programmer -- I normally just build boring, basic 'Corporate' style front ends for my middleware. So I've never done this kind of grafix drawing before.

I think I'm beginning to understand. But it's still fuzzy. My thick skull can really get in the way sometimes.

So -- I need a 'renderer' between the 'view' and 'data model' object? And the 'renderer' assembles the canvas/component? Would the 'renderers' belong in the 'controller' package?

This sounds like I absolutely need these objects:

[*]IsoMapPanel
[*]MapSquarePanel
[*]TerrainRenderer, etc.
[/list]

Does this sound correct? I'm still uncertain . . .

	05-10-2000 05:34									#86
	Support Apolyton, pre-order Civilization IV

Axi:

Sorry to hear things suck timewise for you .

Thanks for the reminder of handling capital as infra, I'd forgotten about that completely. That part should work.

I still don't like treating military units as infra of any sort. But we should discuss that in the infra thread when you have the time.

F_Smith:

Yep, we've gotta reach understanding on this now, or the whole thing will be screwed up...

"When a player has just learned how to build fighter planes, how does he go about building them? Is it 'SMAC' style, where he can build those at any base?"
Basically

"Including a 'prototype'-style first-build cost?"
Not really, the expanding production cost is more than just a prototype cost. We might have prototype costs also, but I haven't gotten that far. Essentially we will have a function that increases the cost to the treasury of building fighters if you build more than the previous amount. This cost would just be paid by the central treasury.

"Can a player can build airplanes at any of his mapsquares?"
Yes, at least if we run the econ model at the mapsquare level.

"Or just in his capitals?" only with prov-level econ things would all be built in the provincial capital.

"What about 'specialization'? Can a player 'improve' his fighter plane factories seperate from his other industry, not counting new technologies?"
Not in the way you are thinking, I think! You can increase the capacity to build fighters using the function that takes money from the treasury above. Other than that factor production capital is the same for toasters and tanks (famous error made by the German general staff in assessing US war capacity at the beginning of WWI was that the two were not interchangeable over year-long periods of time )

"Do I understand correctly that a 'factory' can't be specifically destroyed/sabotaged/dismantled and moved on it's own?"
No, any of these can happen. Only quibble is 'factories' can't move themselves, would need a merchant/transport unit to move them.

"Is there then a 'factory' object at all, or just one 'infraclass'?"
Infraclass dedicated to production is our equivalent to a factory in civ.

"If no 'factory' object, is there any specific game representation of a squares industrial capabilities?"
Yes, infra in that square representing production capacity.

"It sounds to me very much like the 'SMAC' system. If I code along those lines, will I be close to what you want?"
I don't know. I didn't play SMAC for more than a few hours. Just long enough to tell the AI wasn't much better than in civ... If you want to cite examples Civ2 is the one to use for me when possible.

Hope this helps...

	05-10-2000 15:52									#87
	Support Apolyton or Terrorists Win

I'm not a programmer, but...

I think puree's making a lot of sense. Separating the graphical representation from the mapsquare data is logical.

FE this would mean that, if we decided to change the squarebased game into a hexbased game we would not change the mapsquareobjects, only the view/renderer or whatever. Right?

The reason I'm asking this is that I'm an old boardgamer, very fond of hexes . While rambling on in the map graphics thread, it crossed my mind that the hexbased map would give the opportunity to have rivers on hex-edges rather than inside the hex. Of course if we wanted to include this functionality, the objectmodelling of the map'square' would have to be changed, maybe by having an object for each 'square'-edge.

Just wild thoughts.


BTW - I just knew I'd hit a nerve when mentioning infrastructure
[This message has been edited by Beör (edited October 05, 2000).]

	05-10-2000 16:48									#88
	Support Apolyton, buy Alpha Centauri

All:

I'm outa here till saturday evening, so please don't expect fast answers to any questions.

Beör:

I also go way back with hexes in wargaming. But computers being able to figure correct movement distances of 1.41x larger for diagonal moves eliminates a lot of the advantages that hexes had in board games IMO.

Putting rivers on tile boundaries can be done with squares also, so I don't get the connection of that topic with hexes. Rivers going down the center of tiles makes somewhat more sense from an economic perspective (cities, generally assumed to be at square center, are on the rivers). But of course from military and transport infrastructure position you are right that putting rivers on tile edges makes more sense. If you want to take this further, most of the previous discussion of this sort of stuff (though not necc. this particular topic) is in the most recent map generator model thread. That's IMO where we should continue this topic.

	05-10-2000 16:53									#89
	Enter the AD-FREE zone

Off course it is possible to have rivers on square edges, they just don't look very cool, always bending at 90 degrees.

It's not my intention to change the basic maplayout. It was really just curiosity as to whether the separation of view/renderer from data would make such a change easier.

And since I'm not a cat...

	05-10-2000 20:54									#90
	Lose 30 kilos (of popups)

Mark:

I think I've got it. I'm ready to code it, altho first I've got to finish this IsoMapPanel. That's taking a little bit of learning (as you can see), so give me a few more days.

* * *

Beor:

Absolutely, the gui components must be seperate from the data model components.

I usually accomplish this by using the predefined 'Swing' classes, but those won't work here for a variety of reasons. So I'm having to build custom classes I've never had to before.

It's a matter of *how* to seperate the code. What architecture to use to best achieve that seperation.

And I can think of two reasons off the top of my head for this -- hexes, and 'provinces' like risk. That's one reason the gamemap can not be stored as a multidimensional array, by the by.

Personally, I love hexes, I feel like there's more choices in mobility. I would not like to run the rivers between the two, but putting the river on the edge of a mapsquare would be fine, graphically. But all rivers must be 'on the map', which means they'll have to be in a square.