i appear to have the job of designing and coding how gui will work ( NOT the graphics themselves unless you want 'o' for city, 'x' for army etc )

i know roughly what form the design will take, and it should handle different views without any problem,
what i need to know is what map views are wanted, and what data each view will actually display. - by different views im on about 'normal' view , econmic view , political view etc , e.g. the economic view might display the resources in each square, income from each square, trade routes traversing each square etc, but the political view could show civ boundaries, province boudaries, ethnic groups, loyalty levels etc

thanks

He's a very valuable addition to our team, and I'm hoping to learn a lot from him.

For the "normal" view I envision us starting out with something very similar to what is in demo 4. A picture of what's in demo 4 is shown here . This view presents the map graphics for the square, the military power for any army present in the square, the economic value of the square (let's define it as income for now), and who controls it. I think this is about as much information as we can squeeze into the normal view other than things like roads and province boundaries. The "power rings" that show military power have an area that scales as the military power present. Showing things like military or economic power by the area of an icon or symbol means a wide range of the characteristic can be shown easily. For instance in army with a power ring that has a radius three times as big as another one is nine times as powerful. The squares that show population in the demo 4 graphics should show the aggregate economic value of the square. The plan was that the square showing economic value could actually use scaled building icons or something like that. But squares will do for now.

For all the views below, I think we would want to look at them for individual map squares, but also have an option to show this information just at the provincial or even civilization level. That would be what you would use when you just want to see the big picture.

Economic view:
I think your suggestions are good here. I would want it to show economic specials in the square, income, and possibly trade routes. Trade routes will get pretty messy quite fast, so we might just want a separate view with only trade routes and specials.

Military view:
in addition to the task forces and their power rings, it would contain arrows that show where military task forces are going, and ideally what their missions are.

Detailed political view:
Like you say, civ and province boundaries, ethnic groups or levels of dissatisfaction/revolt

Overall political view:
a zoomed-out view showing mostly the civs, each civs economic and military power in relation to the others, and possibly with arrows or some other features like crosshatching indicating alliances.

Technology:
A map of overall research point generation.

All the specialized maps above could also be used to present information on the Change in a given area. Since the player may want to know for instance what the areas of rapid economic growth are, not just the areas that are most important economically now.... I think we can only assess the importance of this kind of information during playtesting.

I should stress that these are just some ideas for things to try. Some things like a power rings are fairly well thought out and have been tested at least somewhat. But in keeping with the extreme programming/design approach, I don't think we should spec these things out too much. I'm sure we will find lots of particular ideas that don't work, and sorts of interfaces that we won't even know we need until we start playing.

Others:

We Really need to keep a lid on the experiments as much as possible. We must focus on implementing what we've go first, and see how that works. Otherwise we'll never get anywhere.

forget about views as previously requested

I believe i have it so that any graphic item can be switched on or off, allowing total customisation of what you want to see, all i need now is for the views ( say economic ) to set a certain combination of switches.

i can get even totally grey screen with just small colored ownership squares all over, doesnt look pretty but quickly shows who owns what, or i can switch everything off and show just a grey screen - updates fast when scrolling

by the way, i am currently not using scroll bars, cos of the speed issues ( i did get a really quick scroll routine, but this was promptly followed by out of memory error - )and have it so that clicking on an area of a map centers the display at that point, ill link this to an overview map as well. Is this acceptable?

I could also do with some info on how people are expecting to get info on how a player is interacting with the interface, i would prefer no other part of the game had any concept of the interface but just hadd events fired to them from the interface ( e.g. when a square is selected anyone listening to the mainmap would get a squareSelectionEvent - or similar ) - any comments / idea's / already agreed design

Great to see you making progress

no scrolling: That's what I'd done in demo 4 also. I don't think we really need scrolling. Others?

quote: (I) have it so that clicking on an area of a map centers the display at that point, ill link this to an overview map as well. Is this acceptable?

For those of ya'll who don't appreciate this wonkish stuff like I do, let me just point out that guy is 'da bomb'.

Puree, that's perfect.

In the long run, I do worry about the lack of scroll, however. It can make gameplay a bit troublesome. But for now, we'll live with it just fine.

In the game, I assume it'll use a 'mini-map' of smaller scale, as well as a bigger, 'detail' map? Then clicking on that would be just fine.

And event driven is absolutely the way I'd like to build this. Use events and listeners. The data engine completely decoupled from the interface, using 'controller' classes. I agree completely.

Is this right -- the interface fires off an event, the data model handles that event, the interface observes and is notified of any data changes, and then the interface redraws itself?

if you can do graphics then thats ok by me.

mark

if you mean 'x' centers on the currently selected square then ill get that in. as well as clicking on the small overview map centering the main view, but get rid of centering by clicking on the main map itself

f-smith

yes, i am assuming the interface(s) will fire off events to any model(s) that want them , and when they've acted on them will fire off an event back up to the interface(s), if a change has resulted. what we need is to know what events will be needed - ie what info has to be sent to the models.

on another note, how are dialogs/screens for different purposes going to be done - e.g will a city screen be produced by whomever is doing city management ( or the equivalent in clash ) that has the obvious advantage of those people know what they want, but could result in different dialogs being done in totally different ways (design wise). or is someone from each area needing a dialog going to put forward what they need to allow and what info they want back then let someone else do the interface/logic seperatly based on that info.

pure eye candy, and not a priority, but is there any idea about look and feel , i ve noticed a couple of posts about the topic. it's something ive wanted to play around with, but never had time or reason enough to do, i believe there is a fair bit of work involved in swing L&F but i'd like to have a look at it if no one objects ( and some else does the real graphics )
I have this idea of the L&F changing through the game as your tech changes - cuniform clay tablet at the beginng, grimy/riveted steel as a civ reaches the industrial revolution and star trek/IT type look when internet/space tech is reached - plus others in between ( thought about cultural L&F but culture is hard to define, and in hypothetical game how can you say what culture you are ?)

Agree with your current take on map centering. Look & feel would be great. But other than making sure we Can do it I think its far off the critical path for now. Even if we don't fully implement it in the first go-around I'm sure we'll use it eventually. So I'd say design with L&F changes in mind. (Does that require any planning at this point? I thought the Swing stuff automatically supported L&F.)

Chris:

Thanks for being willing to join in on this .

I have written again to Darren trying to get the old HTML stuff on interfaces (and code) from him. Its not a lot, but it may be of use in the forthcoming discussions on interfaces .

F_Smith:

Somewhat picky comment, but it may help avoid confusion later... I think you shouldn't name your main turnHandler method oneYear(). Turns will go anywhere from many years to fractions of a year. To avoid confusion it should be called oneTurn(). It can then implement the appropriate timescale for the period.

Off-hand, I can think of two classes of events that the interface will have to fire off -- when a player gives unit orders, and when a player changes a govt policy/gives govt orders. So something like 'UnitEvent' and 'GovtEvent', for now?

There likely will be others, but for now, these are for sure.

I tend to think that we should have a standard dialog box, but I'll leave that decision to you.

And I love the idea of doing a custom look and feel, like you're discussing. I've used the 'metal/motif/windows' PLAF stuff, and it's easy, but I've never done a custom one. That is a fascinating idea.

* * *

Mark:

yes , its not priority, custom L&F does take a bit of work even in swing, i havnt done any yet, but as i say its something id like to look at( i've been thinking of this creepy crawly L&F for a while but never got round to it)

f-smith

what do you mean by standard dialog - for what ?

actually thinking about it, working out whether a player selects a unit on the main map is probably beyond me ( im not a graphic guru ) , working out the square selected is easy enough - but that the pixel was actually the unit graphic , mmm i know it can be done but not my scene, any hints would be welcome

oh yes, what is the largest map size we'll be looking at (in squares, not pixels)?

I hope I'm not misunderstanding the limited discussion... but I think we need to avoid dialogs per se as much as possible. They really disrupt the atmosphere IMO, especially if a bunch of them pile up each turn. I would rather have events get registered by the relevant advisor, and if they pass a priority level that the player sets, then get presented by that advisor in a relevant news-sheet or whatever. Those that need a response could have checkboxes next to them or something.

Anyone have any bright ideas on this topic? If so they should probably be put in the generic interfaces thread, since this isn't really a map issue.

lee:

"working out whether a player selects a unit on the main map is probably beyond me"
Again, demo 4 already has a solution for this... the 'TFs here' window. We can put other stuff in that window also if it turns out to be needed. Perhaps the TFs here window will turn out not the best in the long run, but its certainly workable for now. Things are already partly set up in the old ClashImage class for figuring out what gets clicked in a given square. But its nowhere near complete. I can help you out with this whenever you get to it.

I'm sorry, not 'dialog boxes' -- I just meant a standard 'frame' that would be a 'detail dialog' or some such.

As Mark said, there should be a small JInternalFrame that is the 'mapsquare detail' info.

One other type of event just occurred to me -- this is a radical idea, but what if we allowed players to click a 'turn' button and take turns!!!

I can't believe I forgot that one.

i had considered the concept of selecting a square and then from a separate window/dialog selecting the units you wish to move, that would be easy enough to do, i was concerned about being able to select units on the main map so that there is not to much moving the mouse to do things.

dialogs to me meant the window/frame to manipulate stuff ie dialog to do city management, govt actions.
i just wondered what was meant by standard dialog ?

in terms of squares i dont mind how many, and it wont matter up to a point, but ( memory aside ) a large map may mean a scrolling overview map or very tiny graphics, i was wanting to work out what the overview map had to cope with

Well, we are going to be able to show at most one TF for each of two different sides in a square. I think some selection from the TF window when there are a lot of troops in a square is going to be unavoidable. If you can think of a way around this, more power to you. I would say for starters, you should do it the way we had in demo 4 for now, and if someone has a flash of brilliance, we'll switch over to the better solution. The logic for my simple TF box is already coded, so that seems like the path of least effort to get things going.

Standard dialog is just the usual little box that pops up saying "Attack the Bignoses?" and gives 'yes' or 'no' buttons for choices for example. Or in more germane cicles "save file?" 'yes' or 'cancel'.