Microbe GUI Finalisation

@Nick why not? we have been discussing the elements of the GUI and what better way to show progress than a concept? Also, I think that we need a reproduce button because new players won't know. Especially the arrogant ones that skip the tutorial(like me :P)

Well you can if you want, but it doesn't really serve a purpose until it's one that encompasses all the UI elements that are agreed to be necessary. 

Well cell division is an action of the cell anyways, so it would have to be a hotkey the player can use anyways, and I think the player should at least be expected to know how to reproduce. So I don't think we should have one, although I think it's up to debate. 

Also, Oliver, I forgot to mention in my previous post, but mutation points are not collected over time. Rather, every time you enter the cell editor, you begin with 100 MP, no matter what you did during that life, so MP would not have to be shown in the UI.

So you get a mutation budget every time you enter the editor? That could work if you use up reproductose upon enter

NickTheNick wrote:

Well the benefit of having them on an expandable menu as opposed to a pause menu is that it creates a much smaller and less obtrusive UI, in my opinion, because pause menus usually take up the center of the screen.

In that case, we'll need another pause mechanism. Most games do it via a menu, but I suppose that's not the only way.

I'd completely forgotten the statistics option. That's certainly one area currently lacking in detail, both conceptually and in terms of implementation. Are there any other GUI elements that have been overlooked? I'll have a think and edit this post later if I remember any.

TheRabiesGuineaPig wrote:

Also, I think that we need a reproduce button because new players won't know.

Agreed - I feel like entering the editor is too important a gameplay mechanic to leave solely as a hotkey.

NickTheNick wrote:

Also, Oliver, I forgot to mention in my previous post, but mutation points are not collected over time. Rather, every time you enter the cell editor, you begin with 100 MP, no matter what you did during that life, so MP would not have to be shown in the UI.

I wasn't aware of this, but I can certainly see the advantages. Although there will be some caveats to take into account as well - none of the organelles or upgrades can cost more than 100 MP and all MP costs will need to be balanced so that a reasonable but relatively small change can happen each generation, for instance. Entering the editor should undoubtedly require a significant amount of RpAse too, preventing the player from spamming generations at their will (Spore anyone?).

Oliveriver wrote:

I'd completely forgotten the statistics option. That's certainly one area currently lacking in detail, both conceptually and in terms of implementation. Are there any other GUI elements that have been overlooked? I'll have a think and edit this post later if I remember any.

Has a controls menu been discussed?

What do you mean a controls menu? Do you mean an option in the pause menu allowing for the re-binding of controls/hotkeys for the game?

NickTheNick wrote:

option in the pause menu

Not just in the pause menu -- people will want to rebind in the main menu too. As for RabiesPig's question, I don't believe we have, but now's a good time.

NickTheNick wrote:

What do you mean a controls menu? Do you mean an option in the pause menu allowing for the re-binding of controls/hotkeys for the game?

Yes, that is exactly what I mean.  :elephant: 

Ok, so we need to create a decent looking GUI for the game but, as I am not a programmer, most of my skills are limited to the looks department. I have a rough idea of how to place boxes and get the computer to recognize the positions of buttons but I'm pretty much stumped from there. I would appreciate a list of what buttons/menus to add in and also how to program them. Not just for my briefing, but as a reference for whoever is involved. I'm hoping for a lot of input from the skilled developers like Crovea and Oliveriver. As we are yet to establish a concrete design.

Here is where my design ball is rolling towards at the moment:

Could you make it smaller? The image goes off the edge of my screen, and I have a very large monitor.

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.