Map views

[puree]

hi

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

[F_Smith]

I just wanted to take a quick minute to loudly, publicly thank Lee (puree) for taking this on.

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

Yay, Lee!!!

[Mark_Everson]

Thanks for taking this on puree

I'll get something going tomorrow nite on this. Any nominations from the various model leads in the meantime would be appreciated. But please remember to keep the requests simple .

[Mark_Everson]

Puree:

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:

Please comment on these ideas, and throw your own ideas on the pile! Basic things like this are the kind of thing we Need to be focusing on now.

[Chris Wilkinson]

How about testing an octaganol (sp?) map system? that might be interesting...

[Mark_Everson]

Chris:

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.

That objection aside, octagons don't even tile a 2d surface . You'd need to alternate octagons with diamonds or something, which would be pointlessly complicated. And if you are envisioning a 3d map, I think it is another of those needlessly complicating things that we need to avoid.

[Chris Wilkinson]

Erm....when I say octagen I mean hexagen!

[puree]

i knew you meant 6 sided octagons

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

lee

[Mark_Everson]

puree:

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?

I don't think that's the best way to do it. I think clicking is best used for selection of objects (squares etc.), which happens much more frequently than needing to change view position. I prefer to switch the center of the view Only when I want to, not every time I click on something. If you can spare the 30 min or so, I think it would be really helpful in general for you to run demo 4 and skim the d4 manual to get an idea of the state of play of the map interface. That at least has what has been agreed to so far in it. In this case, it would let you play with the select and hit 'x' method for centering the screen that I prefer.

info on how player is interacting w/ interface:
I think you and F_Smith should hash that one out between you. Your approach sounds good to me, but I'm not up on the best way to do such things.

[F_Smith]

Outstanding, truly outstanding.

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?

Also, I was playing with using 'TurnHandler' classes (implement a 'TurnHandler' interface) to do the actual turn logic for each group of game objects. 'CivTurnHandler', 'EthnicGroupTurnHandler', 'ReligionTurnHandler', that kind of thing. So far, I was thinking the turnhandler interface has at least one method -- oneYear(). Does that sound okay?
[This message has been edited by F_Smith (edited October 15, 2000).]

[Chris Wilkinson]

I can't remember who it was, but someone suggested that I have a go at doing the graphics for the interface. Would you like me to have a go?
[This message has been edited by Chris Wilkinson (edited October 15, 2000).]

[puree]

my 3 year old daughter is as good at graphics as i am

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 ?)

puree

[Chris Wilkinson]

Puree,

I'll have a go and doing some graphical tests...

[Mark_Everson]

puree:

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.

[puree]

look and feel

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)?

lee