0.3 graphics summary / sidepanel revision

Development of artwork, requests, suggestions, samples, or if you have artwork to offer. Primarily for the artists.
Message
Author
User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: 0.3 graphics summary / sidepanel revision

#256 Post by Geoff the Medio »

eleazar wrote:I think the most traditional method would be to have the << & >> scroll through systems in order of the date of the founding of your first colony in that system.
I think the order is by increasing internal object ID number, which usually means the first system created during universe generation will be first, and others later. I don't think the turn on which a colony was founded is recorded.
As for the drop-down list it pretty silly to use that in that way in FO, since the list will be many screen-hights long in any but an unusually small or sparsely explored galaxy.
There is a maximum height of the droplist, and I believe a scrollbar if there are too many to fit into the available space. The same mechanism is used for the empire colour picker on the galaxy setup screen when starting a new game.

User avatar
eleazar
Design & Graphics Lead Emeritus
Posts: 3858
Joined: Sat Sep 23, 2006 7:09 pm
Location: USA — midwest

Re: 0.3 graphics summary / sidepanel revision

#257 Post by eleazar »

Geoff the Medio wrote:
eleazar wrote:As for the drop-down list it pretty silly to use that in that way in FO, since the list will be many screen-hights long in any but an unusually small or sparsely explored galaxy.
There is a maximum height of the droplist, and I believe a scrollbar if there are too many to fit into the available space. The same mechanism is used for the empire colour picker on the galaxy setup screen when starting a new game.
Sorting through a list of 16 items when about half is visible at once, is a vastly different proposition from sorting through hundreds of items when only a small fraction of the list is visible at once.

Using that dropdown under normal conditions will be a huge pain. But if this is not self-evident, try it out in a medium to large sized, fully explored galaxy. Try to find a few planets chosen at random from the galaxy map.

User avatar
eleazar
Design & Graphics Lead Emeritus
Posts: 3858
Joined: Sat Sep 23, 2006 7:09 pm
Location: USA — midwest

Re: 0.3 graphics summary / sidepanel revision

#258 Post by eleazar »

Here's roughly how i see the sidebar
sidebar.jpg
sidebar.jpg (148.44 KiB) Viewed 3072 times
I'm not really sure how much junk we need in the system part of the sidebar... thus i'm not sure if a full-width sun as in this example, or one in the left column like the planets is best. I'm not happy with the selection, but it's the general idea i'm going for.

Note the hight of the asteroid panel. I don't see any reason not to shrink the hight of panels that have free space on both sides.
Last edited by eleazar on Fri Jan 30, 2009 11:04 pm, edited 1 time in total.
Reason: spelling

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: 0.3 graphics summary / sidepanel revision

#259 Post by Geoff the Medio »

eleazar wrote: Note the hight of the asteroid panel. I don't see any reason not to shrink the hight of panels that have free space on both sides.
There actually isn't any free space on the left side of the asteroid planet panel. The asteroids animated image is a series of 128x128 png files, which are shown at (by default) 128x128.

I don't think the code should be second-guessing what aspect ratio to show this sort of art at, so if you want a less tall asteroids panel, I'd like to have some edited asteroids images that are similarly less tall.

After that's done, I can make sure the planet render / icon display sizes itself appropriately for the aspect ratio of the input image(s) when not showing a textured sphere, if it doesn't already (I don't know off the top of my head, and all of our current test cases have aspect ratio 1:1)

User avatar
pd
Graphics Lead Emeritus
Posts: 1924
Joined: Mon Mar 08, 2004 6:17 pm
Location: 52°16'N 10°31'E

Re: 0.3 graphics summary / sidepanel revision

#260 Post by pd »

Nice work eleazar. I love the giant star.
I don't think the code should be second-guessing what aspect ratio to show this sort of art at, so if you want a less tall asteroids panel, I'd like to have some edited asteroids images that are similarly less tall.
No problem, I've taken care of this. All 'roids are cropped to 128x64.

User avatar
The Silent One
Graphics
Posts: 1129
Joined: Tue Jul 01, 2003 8:27 pm

Re: 0.3 graphics summary / sidepanel revision

#261 Post by The Silent One »

Yes, good job! I like the borders as well as the reduced panel size for asteroids. The way selection is shown appears intuitive. I also like the planet caption (ignore the ones in my mockup).
Eleazar wrote:It's kinda weird to have just a bunch of floating panels, controlled by a scrollbar at their side. I'd rather put all the panels in the box to bind everything together visually, and also so there's a logical place to put something to grab to resize the sidebar width.
I'm not convinced that the border of the sidepanel is necessary nor visually appealing. Maybe it's just because I don't like the double border of the sidepanel / planetpanel. It seems ...heavy, I guess. I understand that the sidepanel border can be used to resize the sidepanel, but so could the planet panel's border, and while the sidepanel's border might bind the individual elements together, the shape of all the panels taken together should convey the same. Take this unfinished mockup as a further example how the sidepanel would look without border (the scrollbar lacks a border):

Image

Another unresolved issue is the system panel. What I wanted to illustrate in my previous post is that while the system panel needs to be distinguishable from the planet panels, it should also follow the same design scheme - which I find impossible with the sun in the top-right corner. While Eleazar's most recent concept succeeds in being distinguishable, the (currently missing) system info might obscure large parts of the star image and thus make it less easy to tell the system panel apart. For this reason I think that the sun should rather be moved to the left, if we don't find a better alternative.

Minor points are:
- fixed sizes for "planet windows" (see mockup) to save map space when lots of info boxes are uncollapsed
- dark grey background for info boxes (consistent with drop-down edit boxes)
- black transparent background for planet graphics (80% Opacity)
If I provided any images, code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0.

User avatar
eleazar
Design & Graphics Lead Emeritus
Posts: 3858
Joined: Sat Sep 23, 2006 7:09 pm
Location: USA — midwest

Re: 0.3 graphics summary / sidepanel revision

#262 Post by eleazar »

Geoff the Medio wrote:After that's done, I can make sure the planet render / icon display sizes itself appropriately for the aspect ratio of the input image(s) when not showing a textured sphere, if it doesn't already...
To clarify, the idea was that any sidebar panel could collapse down to whatever size is required to contain the info.
small planet.jpg
small planet.jpg (37.32 KiB) Viewed 2990 times
Small planets take up about the same vertical space, tiny planets even less. Unless they are colonized, and thus take up more space in the right column, there's similarly no visual reason to make the panel take up the whole ~128 vertical pixels.

More, later.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: 0.3 graphics summary / sidepanel revision

#263 Post by Geoff the Medio »

eleazar wrote:Small planets take up about the same vertical space, tiny planets even less. Unless they are colonized, and thus take up more space in the right column, there's similarly no visual reason to make the panel take up the whole ~128 vertical pixels.
I worry a bit that having a different small panel height for each planet will look a bit odd. It's probably a lot more noticable and potentially odd-looking than different size large panels, since you can see more small ones close together to make comparisons, and there's no informational reason to have them be different sizes.

It's probably a relatively easy options to make toggle-able, though.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: 0.3 graphics summary / sidepanel revision

#264 Post by Geoff the Medio »

eleazar wrote:Note the hight of the asteroid panel. I don't see any reason not to shrink the hight of panels that have free space on both sides.
Done...
Attachments
smaller asteroids panels
smaller asteroids panels
Shrink-Fit-Asteroids.png (83.61 KiB) Viewed 2894 times

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: 0.3 graphics summary / sidepanel revision

#265 Post by Geoff the Medio »

After numerous posts about it, I've decided to add functionality to let players order buildings or ships to be scrapped, or destroyed, if the player owns the building or ship. In order to use this, though, we need a way to order it, a way to show that it's been ordered, and a way to cancel the order in the GUI. I'd like some graphics input on how to do these...

I have some ideas:

To order a building or ship to be scrapped, the player could right-click on the building icon on the sidepanel or on the ship in the fleets window. There is already a "Rename" menu option for ships, and it would be simple enough to add "Scrap", and to add a menu with just "Scrap" in it to buildings. Buildings and ships ordered to be scrapped would stay on the sidepanel or fleets window, but would have a large X over their icon. To cancel the scrapping, the same right-click menu could be used. Some problems with this are that the large X over the icon might not be clear, and it's not clear what would or should happen if a ship is ordered scrapped and then its fleet is ordered to move somewhere... Does the fleet move and then the ship gets scrapped, or does the ship stay behind?

A separate or possibly combined possibility is to have a "Scrap Fleet" in which all ships ordered to be scrapped are placed. This ship wouldn't move anywhere, and scraping could be cancelled by removing the ship from the fleet. The Fleet's row in the FleetWnd could also indicate "Ships Being Scrapped" or somesuch, to clarify what's going on with them. (Individual ships don't have orders status indicator like fleets do)

Another option is to involve double-clicking to order buildings to be scrapped, and perhaps ships as well. This is consistent with how techs or production items are removed from the queue, and could be particularly good for buildings, as in-progress buildings show up on the sidepanel, and being able to double-click to remove them, or double-click completed buildings to order them scrapped would be nicely consistent. This probably isn't practical for ships though, as having double-clicks on fleets open up a sub-window for them, but double-clicking ships cause them to be ordered scrapped might be confusing.

Thoughts?

User avatar
Bigjoe5
Designer and Programmer
Posts: 2058
Joined: Tue Aug 14, 2007 6:33 pm
Location: Orion

Re: 0.3 graphics summary / sidepanel revision

#266 Post by Bigjoe5 »

I'm all for adding scrap to the right-click menu. Ideally, this menu would be where most interactions that don't occur on a turn by turn basis occur (since anything more common would be important enough to have left-click UI elements). So rename, scrap, and possibly additional building/ship specific options should probably go in the right-click menu, IMO.
Warning: Antarans in dimensional portal are closer than they appear.

mZhura
Space Kraken
Posts: 168
Joined: Sun Sep 27, 2009 10:51 am
Location: Moskow, RU

Re: 0.3 graphics summary / sidepanel revision

#267 Post by mZhura »

Geoff the Medio wrote:To order a building or ship to be scrapped, the player could right-click on the building icon on the sidepanel or on the ship in the fleets window. There is already a "Rename" menu option for ships, and it would be simple enough to add "Scrap", and to add a menu with just "Scrap" in it to buildings. Buildings and ships ordered to be scrapped would stay on the sidepanel or fleets window, but would have a large X over their icon. To cancel the scrapping, the same right-click menu could be used.
sounds wonderfull
Geoff the Medio wrote:Some problems with this are that the large X over the icon might not be clear, and it's not clear what would or should happen if a ship is ordered scrapped and then its fleet is ordered to move somewhere... Does the fleet move and then the ship gets scrapped, or does the ship stay behind?
i think ships and buildings must be scrapped at the start of turn processing immediately after pressing "turn" button, i.e. that they doesn't produce any more effects after ordering to scrap and likewise doesn't do anything at all - just go to scrap, but with one exception - if the fleet/ship currently in starlane, then it will be scrapped by arrival to nearest system on it's path and again - without any more actions like battle for example.
Geoff the Medio wrote:The Fleet's row in the FleetWnd could also indicate "Ships Being Scrapped" or somesuch, to clarify what's going on with them
i am sorry for offtopic, but what is the "FleetWnd"???
Geoff the Medio wrote:Another option is to involve double-clicking to order buildings to be scrapped, and perhaps ships as well.
and that doesn't sound good to me

User avatar
pd
Graphics Lead Emeritus
Posts: 1924
Joined: Mon Mar 08, 2004 6:17 pm
Location: 52°16'N 10°31'E

Re: 0.3 graphics summary / sidepanel revision

#268 Post by pd »

Pretty straight forward. The images show exactly what you were describing. I favor a right click menu, because it allows for a textual description of what is going to happen. Double clicking(for buildings) could work, if they would disappear instantly(as queue items and ship parts do), but with a delay, a red mark as in my mockup could be confused with disabling or something like that.
Geoff wrote: it's not clear what would or should happen if a ship is ordered scrapped and then its fleet is ordered to move somewhere... Does the fleet move and then the ship gets scrapped, or does the ship stay behind?
For simplicity reasons, I would just treat a going-to-be-scrapped ship like any other and then scrap it, when turn processing happens.

I've also included the possibility to scrap entire fleets, which wasn't mentioned, but could be useful.

Image
* ignore the position of the mouspointer

i am sorry for offtopic, but what is the "FleetWnd"???
Short for fleet window(and possibly the internal name for it in code?).

User avatar
OndrejR
Space Dragon
Posts: 339
Joined: Thu Oct 02, 2008 11:00 pm
Location: Slovakia

Re: 0.3 graphics summary / sidepanel revision

#269 Post by OndrejR »

pd wrote:
i am sorry for offtopic, but what is the "FleetWnd"???
Short for fleet window(and possibly the internal name for it in code?).
Yes.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: 0.3 graphics summary / sidepanel revision

#270 Post by Geoff the Medio »

Some recent changes have made some meters have target values rather than max values. Now, the "target" value might be lower than the actual value of the meter, and the actual value will decrease towards the target value, or the target might be higher, and the actual value will increase like current meter values would increase previously.

This change means that the current meter bar graphical element on the sidepanel is incomplete. The problem is that it can't show changes to a target meter that decrease its value below the actual meter value. In the attached, the orange meter (second from bottom) has a actual value shown by the brightly-coloured region, an expected increase in the actual value shown by the green increment above the brightly-coloured region, and a dark background showing the target value. The yellow meter at the top has a actual meter value that is larger than the target value. The actual meter value is seen to be decreasing, but the target value can't be seen because the darker bar (like seen in the orange meter) is obscured by the bright actual value.

So, we need a way to show target and actual values that can be higher or lower than eachother. I'd like some graphics suggestions for this.
Attachments
meter status bar as of this post
meter status bar as of this post
MultiMeterStatusBar.png (1.1 KiB) Viewed 2393 times

Post Reply