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 )

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());
                }
            }
        }        
    }

---

So the paintTerrain method in IsoMapCanvas would do the painting at the relevant x and y location, while the mapsquare would hold the information on what get's painted.

Does this seem okay, or would you completely remove the grafix data from the mapsquare? I was thinking along the lines of 'AbstractTableModel', which has a 'getColumnCount', 'getRowCount', etc. The table model holds the data on what get's drawn, while the view draws only what it wants -- there-by easily allowing multiple views of the same data. And the renderer just draws columns and rows.

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 )

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.
  

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.

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.

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.

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.

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.

That's the goal. You will have that choice.

Mark:

Just saw your comment about SMAC's AI. I've never been able to win on the harder settings. The AI is excellent . . .

The top 3 difficulty settings ("Librarian" and above) are *very* good.

f-smith

if you can create a seperate controller package then excellent, as i said earlier its very hard to seperate controller from view ( or maybe even model to an extent) and is rare to find mvc in its form. i seem to remember microsoft ditched it in favour of 'document'-view , ie a 2 component model ( its a long time since i looked at their architecture though, and i didt get that involved then - i just pulled out me visual c++ stuff, yep document-view)
Therefore i would say dont get overly worried about that level seperation.

the renderers are really the biggest part of the view, so strictly speaking they dont belong in controller, but as said above its likely theyll end merging to an extent anyway.

if you want each square to be represented by a canvas of its own, then yes the renderer will return a canvas every time it is asked to render a square.

TerrainRenderer mmmmm .. what do you mean by that, one renderer would be used to paint a square - terrain, armies the lot ( or whatever is to be seen anyway ), there probably shouldnt be a renderer painting the terrain , another the armies etc.

if i get time this weekend ill knock up a simple demo version of a mapview/mapmodel/mapsquare/renderers to provide a better idea of how i think they hang together, if you want any help coding , or whatever drop us a mail.

beor

changing to hexes would i assume mean some minor changes to the model, something has to deal with adjacent squares/hexes which are now 6 instead of 4.
I say minor as i assume anything relying on looking at neighbours is using arrays or collections in a loop, and not hard coded to expect 4 neighbours, so none of that would need changing - but other stuff to do with AI might.

1. Hex allows 6 way movement and attack. While better than 4 ways of squares normally allowed, the diagonale cost equation now allows for accurate attack and movements in 8 directions which then is more accurate.

2. With the 6 possible directions, Hexes don't allow for direct east/west movement, but do allow it for north/south movement. Thus it favors one type of movement (up/down) as apposed to the other because you cannot move straight left or right, but much choose to move diagonally up/down one way then back and this can have important consiquences if you want to move and get stuck inbetween. (Also it'd be impossible to move exactly along the equator as you keep going above and/or below it and then back on the center of it).

3. It doesn't allow for ness anything to go straight, espically left-to-right. Esp. if you want rivers along the boarders which it wouldn't look to good in a square map. Not major, but still....

4. It puts off a lot of non-wargamers also who don't like hexes because they aren't wargamers. On the other hand, wargamers will play (most will anyway) ones basef on square tiles if done descently. Final Fantasy Tactics is a good example. It is a square based tactical game and is one of the hottest strategy/wargames of all time (and among the hardest to come by as the price for used copies is $50 and up in places).

Anyway if i can get a descent program I am willing to work on the map graphics for the square based tile system (not units...unless you want anime units), but not hexes. That's alot more work.

Yes, yes, yes -- please. Any help you can offer would be appreciated. I'd love to see anything you code up. It would help move the game along tremendously.

I can also guarantee you will get full credit for your contributions, which so far have been weighty enough to deserve that and more.

Let me ask you something -- one thing I would love to do is draw the map in a 3d 'wireframe' approach. Have you seen the maps in 'Railroad Tycoon 2' or 'Alpha Centauri'? RR2 is the most outstanding map I think I've ever seen.

But anyway, do you have any ideas or suggestions on rendering such a map?

* * *

Lordy:

don't worry, hexes is a distant thought right now. We're just talking scalability.

P.S. -- Microsoft about 2 years ago switched to the m-v-c approach. Only, in typical MS fashion, they renamed it and claimed it as their own.

Have you heard the term 'Windows DNA Architecture?

MS says the perfect architecture *they've* developed has 3 tiers --

quote: Windows DNA is Microsoft's platform for building and deploying Web-based applications . . .

It's short for Windows Distributed interNet Applications Architecture.

Surprisingly enough, they only believe in using Windows-specific technology for each of the tiers -- Active X, Com, and DHTML.

Isn't that a shock?

The MS people were kind enough to give a 'free' seminar on how to leave behind that 'Sun Owned Franchise' of Java and program the "modern" way.

I'm there, too. I'm hopeless at doing the actual grafix. I do use Paint Shop Pro, tho, but only for converting grafix for one format to another!!! But it makes me feel like a 'pro' . . .

I'm mostly talking about drawing a wireframe of the landscape's changing altitudes, then painting the 'terrain' .gifs.

Yes, please contribute in any way you can!

F_Smith:

Wireframe??? Um, uh, don't take this the wrong way, but can't you just shoot to implement the existing graphics first? The nature of the graphics is something for the whole team to discuss. And not in an OO thread. The choice of graphics implemetations has far-reaching implications. Since we don't even have artists currently working on the project, this seems an extremely premature time to investigate this...

So although your 'contract' says you can try whatever options you want to, I really thing it would be best to at least do the simple iso graphics that are already available first. YMMV, but this approach makes a lot more sense to me. The good OO nature of the code should allow retrofits fairly easy later to wireframe stuff if we decide that's the way we want to go (but We needs to include artists first...)

I am talking about using the existing grafix. I'm only talking about drawing them in the 'SMAC'-style, on a 'wireframe' 3d grid instead of on a flat plain.

Just using transforms on them, to show altitude.

It is only a programming issue.

Wireframe: Oh, didn't realize it was just as simple as a transform. If it doesn't require add'l artwork then I have no problem with it.

TK:

Magnus hasn't taken off, but he hasn't even had enough interest to post on the forum. So it is just my guess that we shouldn't count him as really committed.

Actually, yes, this is done for now.

The basic architecture has been laid out, coded and delivered to Lee (puree). He's building a GUI for it as we speak.

The next questions of OO design will be on the specifics of 'terrain', 'infrastructure' and 'resource' classes.