Microbe GUI Finalisation

I am not sure how to make it smaller. Do you mean the actual file?

No just the resolution.

Here is an annotated version as I felt it needed some explanation:

Spoiler:

Seregon wrote:

What to do about changing compound capacities is still an unsolved problem.  There are a few options for representing it graphically though:


1 - Have a single bar showing how the overall capacity of the cell is occupied by different compounds, something like the image above.  This clearly shows how both the concentrations of each compound, and the overall available space, change.  However, it may be a little difficult to read, especially if there are many compounds, some with relatively small concentrations.

2 - Have each compounds bar show how much of the total storage its using, and also show how much storage is available, either with a vertical line on the bar, or by greying part of it out.  Using the above image as an example again, imagine that the green part is that used by a particular compound, the yellow part is space available (to this, or any other compound), and might be colored white, and the red + white parts are space occupied by all other compounds, and colored grey.  This is a little clearer than the above method, but will have the result that most of the bars are mostly grey, with low compound levels, and the same information is duplicated many times (most of the bars will have the same amount of grey).

3 - Show compound levels as an absolute measure, instead of relative to available storage.  Or somehow show both an absolute level and some measure of the space still available.  I'm not sure how this would work graphically though.

I think the best approach to dealing with this will be to just have a bar for each compound, and colour in the bar to show how much of the total space of the cell is held by that compound. Free space could be its own bar. If we try this and find it doesn't work, we could try some other methods.

Sorry to double post, but here is my idea of how to minimize the UI, based on what we know we need to include.

Concept:

Also I was thinking that instead of going for a solid dark grey coloured UI as some earlier images showed we go for more of a transparent grayish blue (this image does not convey that). Also, the shapes are not meant to show the final shapes, only where the shattered styled shapes should be located.

Also, the top left UI element and the bottom left I think should be independent, so that when the player drags the cursor to the bottom of the screen the bottom element slides in but the top doesn't, and vice versa. In the game's options the player should be able to lock the bottom and top left separately so they are always shown on screen.

Those positions look pretty good.
I have an idea on how to display organelle health and compound capacity very intuitively.
Using a Radar Chart we can show the levels of many compounds simultaneously and it becomes very obvious when compound balance is disrupted. it also will most likely save on screenspace, since we could easily overlay compound level and organelle health diagrams onto one chart using two different line colors.

Technical discussion on this thread.

A radar chart sounds really great for compound stores, and pretty good for organelle function; but I'm not too keen on having them overlap -- chances are good that organelle-type count and compound-type count within a cell won't always be the same, so we'll have misaligned axes, which gets ugly.

One great extension I can think of for a compound-store radar map is displaying some measure of projected compound levels -- perhaps using a gradient on each line to show where it's tending (a stronger, farther-leading gradient indicating faster change), or more clearly but maybe more confusingly, another fainter line for projected stores. Or perhaps even a faded hue gradient, so you can look however far into the future as you like easily, by looking at a different color.

Another useful feature would be to scale the axes logarithmically -- to cover a wider range of useful data.

moopli wrote:

A radar chart sounds really great for compound stores, and pretty good for organelle function; but I'm not too keen on having them overlap -- chances are good that organelle-type count and compound-type count within a cell won't always be the same, so we'll have misaligned axes, which gets ugly.

One great extension I can think of for a compound-store radar map is displaying some measure of projected compound levels -- perhaps using a gradient on each line to show where it's tending (a stronger, farther-leading gradient indicating faster change), or more clearly but maybe more confusingly, another fainter line for projected stores. Or perhaps even a faded hue gradient, so you can look however far into the future as you like easily, by looking at a different color.

Another useful feature would be to scale the axes logarithmically -- to cover a wider range of useful data.

I think a simpler method of visually showing projected levels would be color. For example, when compound levels are projected to rise, the node is more blue, when they are projected to fall, the node is more red. That means that at a glance one can tell if the computer thinks they're headed for a catastrophe if one node becomes very red.
Also, what's your opinion on showing current trends vs projected trends? It would be easy to just show the color based on the momentary derivative of concentration, but I suspect we'll want a more subtle indication of where your cell is headed.

Anything more than momentary derivative requires either a higher-order extrapolation or actual simulation. While the computer will be able to handle some calculations, predicting the behaviour of a chaotic system (correctly) quickly becomes intractable. Of course, since we can't easily predict player behaviour (and even if we could, we wouldn't want to incorporate that data as it would violate the implicit contract between UI and player), then we would never want to predict too far ahead.

I think, unless for actuarial purposes (ie getting microbe health, so the GDD thread), we'll be safe with linear extrapolation.

moopli wrote:

Anything more than momentary derivative requires either a higher-order extrapolation or actual simulation. While the computer will be able to handle some calculations, predicting the behaviour of a chaotic system (correctly) quickly becomes intractable. Of course, since we can't easily predict player behaviour (and even if we could, we wouldn't want to incorporate that data as it would violate the implicit contract between UI and player), then we would never want to predict too far ahead.

I think, unless for actuarial purposes (ie getting microbe health, so the GDD thread), we'll be safe with linear extrapolation.

Sounds good to me.

Ninja'd edit: 
Oh wait, make that decaying exponential extrapolation -- process speed scales with reactant concentration (do we also scale it against product concentration? Not familiar with that part of the code yet); which makes for exponentially decaying quantities.

Of course, since exponentials are linear to a probably-good-enough degree, we can save ourselves trouble and stick with linear.

moopli wrote:

Ninja'd edit: 
Oh wait, make that decaying exponential extrapolation -- process speed scales with reactant concentration (do we also scale it against product concentration? Not familiar with that part of the code yet); which makes for exponentially decaying quantities.

Of course, since exponentials are linear to a probably-good-enough degree, we can save ourselves trouble and stick with linear.

I believe we're not using backwards reactions so there's not plan to scale rate against product concentration. But I could be wrong.

From your concept, Nick, I have made some quick adjustments to the image. Unfortunately, the spore graphics style doesn't do it much justice:
https://imgur.com/mZgIWFy
If we are still going with the shards theme, to what extent? Should it be really shardy or more simple like my concept?

Firstly, I agree that transparency is the way to go, seeing as it adds to the overall style of fragility which so far the microbe concepts and music have been heading towards. Not sure about having blue as the main colour, but that might be because I'm still slightly partial to the earlier GUI concepts.

Radar charts look viable as an alternative to compound bars (how they'll fit in with Nick's default compound display customisation I'm not sure), but the technical discussion of them is largely beyond me it seems.

The general layout may require a little more thought, though. Ideally the total area covered by GUI elements should be as minimal as possible. The location of the GUI, even if it is partially transparent, should be taken into account - seeing as the most important game information tends to be in the upper-left corner of the screen (because Westerners' eyes move from left to right when reading so will instinctively start there) it might be a good idea to follow this convention with the pause button/extendable panel and ATP/RpAse stores, with the button to open the panel in the top left corner (with the options extending along the top to the right) and the major compound stores just below it. Also, should possible screen clipping be considered when placing elements at the top of the screen? Until now every button has extended off the screen in some way, whereas it may be possible to have it contained completely within it (though this has the unwanted side effect of appearing to squash the game screen). The overall compound stores I imagine would be positioned similar to the panel in RabiesGuineaPig's image (though obviously retracted as default) to balance out the top-left corner with something in the bottom right.

The list of on-screen GUI elements to take into account has been largely finalised as:

Spoiler:

That list sounds right, Oliveriver. Going with a radar map means we won't need to include Nick's choose-default-bars idea -- his suggestion was to avoid clutter by reducing the number of variables visible, but using a radar map will allow us to show (likely) all the compounds we'll ever need (~10) together without cluttering. Then again, since we'll likely have many agents, we might need Nick's (or another) solution for agents, as the radar map would get too cluttered with all of them.

I do hope we'll be going with the shard theme though -- the current placeholder UI doesn't do the shard theme justice, but shards would afford some very pretty transition effects (which, coincidentally, I've been looking into doing with CEGUI). Since a lot of the UI is meant to hide out of the way unless the player triggers its appearance, we need to consider how it appears. So what would be nice is some rough sketches like this:

This one's a quick idea I had some time ago for making a side menu (or for a floating menu, with centre simply appearing instead of sliding in).

Finally, what do you mean with the screen clipping? I'm confused with "contained completely within" and "extending off"; as all the buttons, just as anything else, are contained within the game window, but I may be missing the point.

The shard theme is something I want to see continue to be implemented as well. If I recall correctly, the pause menu concept mentioned on the first few pages of this thread was meant to appear in the centre of the screen with its options spiraling out, basically what you meant by floating menu. Obviously with an extendable panel there's little need for a pause menu as well, so we'll have to rethink it somehow to fit in.

What I meant by having the GUI contained within the screen is this:

Spoiler:

In the first example, the GUI seems to continue off-screen, as if it has only portions of it poking in. For the second, the shards (currently modeled by exciting grey rectangles) are within the bounds of the screen. Clipping would occur if a screen had the wrong resolution and some parts of the second example were cut-off as well.

Ah, that's an important consideration - one way we could easily avoid that (and keep GUI minimal) is to have each GUI element tied to a corner/edge-middle or similar. In terms of GUI seeming to extend offscreen, I'd definitely prefer a GUI that does so.

We can use the floating-unfurling-menu idea for the AI microbe pop-up panel. I assume, whenever you're not interacting with the panel, it would shrink to a minimal display of some vitals, and then clicking could unfurl the extra info/options. 

Perhaps the extendable pause pane can be something like this:

Red marks probably-static panels (or maybe when the gui is set to "unobtrusive", they appear when you hover in the corner). Click green, and the green-arrow panels unfurl for the pause menu. Hover blue, and blue panel stabs into the screen. Note, this isn't meant as a new UI idea, just as some more ideas for UI dynamics.

Now, since it seems we'll be using the mouse a whole lot to interact with the GUI, I have to wonder how much it'll interfere with using the mouse to steer. I know I, for one, have already gotten frustrated. But that's OT

As soon as I get some time I will try to freshen up my concept into a more shard-y design. Will post later.

Oliveriver wrote:

The general layout may require a little more thought, though. Ideally the total area covered by GUI elements should be as minimal as possible. The location of the GUI, even if it is partially transparent, should be taken into account - seeing as the most important game information tends to be in the upper-left corner of the screen (because Westerners' eyes move from left to right when reading so will instinctively start there) it might be a good idea to follow this convention with the pause button/extendable panel and ATP/RpAse stores, with the button to open the panel in the top left corner (with the options extending along the top to the right) and the major compound stores just below it. Also, should possible screen clipping be considered when placing elements at the top of the screen? Until now every button has extended off the screen in some way, whereas it may be possible to have it contained completely within it (though this has the unwanted side effect of appearing to squash the game screen). The overall compound stores I imagine would be positioned similar to the panel in RabiesGuineaPig's image (though obviously retracted as default) to balance out the top-left corner with something in the bottom right.

Well the species name and reproductase and ATP bars could be in the top left corner, but to also put the expandable menu there too would clutter that corner too much. I think it fits better below in the bottom left corner. That would leave compound levels to the bottom right corner. Also, I think we can get around having to have an icon specifically for compounds by making a click on the species name or on the microbe itself open a panel on the microbe, which would have a compound sub-panel (not really sure about the hierarchy of panels).

Also, I don't think UI clipping is a problem, because most games have the UI touch the edge of the screen and it looks strange to have it isolated.

maybe both expandable panels could be on the bottom right corner and you can either bind them both to their own hotkey or click the top or the bottom of the sidebar to open the selected one. In the settings players can choosewhich expandable menu is the default one to be open on startup. Thats just my ideas dump.

I don't think putting both expandable panels on bottom right is so great -- probably linked to what I'm imagining the compound panel will work like: I'm thinking the compound panel, when hidden, will have a little corner poking into the screen at the bottom-right corner; and when you hover over the corner (one of the easiest places on the screen to hit, since you can just slam your mouse in the general direction), the panel slides in. We could have a little compound icon on the always-visible corner -- note, not a button, since you never click. The panel would retract once the mouse moves far enough away.

then, we could do something similar on the bottom-left or top-right corner for the options menu -- slam your mouse however uncoordinatedly as you like in the general direction of the options menu, you hit the corner, the options menu buttons unfold out from the corner.

When my heart is racing and my microbe is in mortal peril and I need to know if I have enough ATP to sprint away, I don't want to hit the options menu by mistake and lose precious moments. I want to hit an infinitely large open-compound-viewer-hover-thing.

Actually, now that I think of it, it is pretty flawed. Currently playing around with a more detailed skinning.

Oliveriver wrote:

What I meant by having the GUI contained within the screen is this:

Spoiler:

I have to disagree with the second option in the GUI since it leaves considerable dead space in between the GUI and the edges of the screen. I'm pretty sure almost every game i've played has kept their GUI's as close as possible to the edge with the exception of a few small health bars which had a little bit of distance. It would be a waste of valuable screen space especially since a lot of the GUI will be expanding. to have small cracks at the top and bottom (which are essentially useless as far as gameplay).

Oliveriver wrote:

Clipping would occur if a screen had the wrong resolution and some parts of the second example were cut-off as well

Well the goal with most people is to actually play their game in the right resolution. Also, even if say they were a bit off in resolution, the text shouldn't be bordering the edge of the screen either ways, so they'll be able to see most of it. My point is, we should be assuming everybody is in the right resolution.

Ok guys, we really need to fine tune this discussion to a concept that we should start coding. The GUI is on the to-do list so let's get on it!
|My suggestion for a plan of action|
-take all the GUI concepts and ideas together into one super concept
-bring some of the talented coders over here
-get this thing made!

TheRabiesGuineaPig wrote:

Ok guys, we really need to fine tune this discussion to a concept that we should start coding. The GUI is on the to-do list so let's get on it!

Don't worry that's what everyone is trying to do on this thread. I think we're approaching some general consensus, just a few things like the radar chart instead of nick's default bars, or how the menus are going to pop up (shard or pop out, etc)

I'm thinking if we're ready to start putting together the GUI we could do a really simple one using all of Nick's default options. I know it wont be as intricate and informative as the ideas suggested by scio, moopli and oliver, but wouldn't it be better to have a GUI that's ready to go? It'll be simpler to program and design and that way you can be one step closer to a big release. In the meantime you can work on a fancy GUI and use that in a later update.

I have a two concerns for the shard design though.
-Moopli mentioned this, but the user friendliness of the shard GUI is a concern. I know a lot of GUI's that are a pain to handle because of disappearing and reappearing icons, especially when youre about to click on an icon and it disappears.
-Shards look nice, but it looks like the GUI will be needing some detailed information (especially words or icons with information) and from the looks of it, the shards take up too much space to show that info because of their asymmetrical design. So unless you want words written diagonally so they can take less space, you need to find a good solution.

So in the meantime, would it be practical to put together a simple default GUI? Sure, youll be missing a lot of information you'd want to include in your original plan, but it gets things started.

TheRabiesGuineaPig wrote:

-take all the GUI concepts and ideas together into one super concept

Uh, I don't think that works here. We need an ongoing conversation where we suggest and eliminate suggested ideas. Putting everything together into one super concept sounds like it's out of some anime.