FreeOrion

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.


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.

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy
—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—

Here's roughly how i see the sidebar



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.

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy
—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—

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)

Nice work eleazar. I love the giant star.


No problem, I've taken care of this. All 'roids are cropped to 128x64.

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

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



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)

To clarify, the idea was that any sidebar panel could collapse down to whatever size is required to contain the info.



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.

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy
—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—

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.

Done...

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?

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.

sounds wonderfulli 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.i am sorry for offtopic, but what is the "FleetWnd"???and that doesn't sound good to me

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.

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.


* ignore the position of the mouspointer



Short for fleet window(and possibly the internal name for it in code?).

Yes.

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.