Needed suggestion for tech-screen UI

Development of artwork, requests, suggestions, samples, or if you have artwork to offer. Primarily for the artists.
Message
Author
User avatar
Bastian-Bux
Creative Contributor
Posts: 215
Joined: Fri Jun 27, 2003 6:32 am
Location: Kassel / Germany

#31 Post by Bastian-Bux » Tue Dec 07, 2004 5:20 pm

There is no overfunding in that way. That is especially why we have a turn limit on research. If we would allow overfunding this turn limit would be senseless.

So to say it clearly: Each research needs x RP for y turns. There is no way to decrease Y, but it will increase if you underfund a project.

Reason behind this is to allow for a true research strategy. More info can be found in the old threads.

LonghornXtreme
Space Floater
Posts: 31
Joined: Fri Jun 11, 2004 1:54 am

#32 Post by LonghornXtreme » Tue Dec 07, 2004 6:41 pm

Sorry, just heard 'overfunding' and assumed that was what it meant.

User avatar
BreadMan
Space Squid
Posts: 88
Joined: Fri Aug 06, 2004 1:37 am
Location: Chico, California

#33 Post by BreadMan » Tue Dec 07, 2004 8:15 pm

tzlaine wrote: The biggest problem is that you didn't provide a tree, which is the really difficult bit. The "tree" is really more like a graph, as in graph-theory, not as in a graph of x vs. y. The graph is acyclic, meaning that there are no loops in the dependencies in the graph, but there can be lateral dependencies. For example:

A has no requirements
B requires A
C requires B, D
D requires B

Code: Select all

A --> B ---------->  |---> C
      |              |
      ----> D -------|
Ok, so here's where I keep running into trouble: what about dependencies on multiple categories? Above example looks fine, as does something like this:

Code: Select all

A --> B ---------->  |---> C
      |              |
      ----> D -------|
                     |
X --> Y ---------->  |---> Z
But then what happens when you have more than two categories? Say for instance, Category Q, which has an application S that is dependent on theory B:

Code: Select all

A --> B ---------->  |---> C
      |   \          |
      ---->\D -------|
            \        |
X --> Y -----\---->  |---> Z
              \
Q --> R -------------> S 
Where do you put the line? You have to draw it across categories, there's no other way, and that just looks dirty. That's what's been holding me up.
Good afternoon! This is the Earth Alliance embassy diplomatic office. My name is Alex. How may I assist you?
HUMANS! BLAUGHRAN EMPIRE CLAIMS PLANET KREIGHTON! YOU GIVE RAY GUN SCIENCE OR BLAUGHRANS DESTROY HUMANS ON KREIGHTON!!!

dstjames
Space Floater
Posts: 24
Joined: Fri Dec 12, 2003 3:31 pm
Location: Detroit MI USA

dstjames

#34 Post by dstjames » Tue Dec 07, 2004 10:05 pm

What about dividing up the tech tree in tabs.

Something like this:

Physics:

A-----B------ |
| |D
C-------|

Laser Tech:

E-----F------|
| |
G------|H
|
A----- |


Edit Sorry dont know how to add the image correctly.
Last edited by dstjames on Tue Dec 07, 2004 10:09 pm, edited 1 time in total.

User avatar
Tyreth
FreeOrion Lead Emeritus
Posts: 885
Joined: Thu Jun 26, 2003 6:23 am
Location: Australia

#35 Post by Tyreth » Tue Dec 07, 2004 10:07 pm

pd wrote:
When talking about "overfunding" are we referring to excess PP being put into a project to underfund it? Or something else I've missed?
with overfunding i meant putting more RPs into a project than necessary to accelerate researching.
Ah, in that case there is no overfunding in 0.3, and no plans to introduce it. As someone else pointed out, it would defeat our purpose for a fixed number of turns cost.

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

#36 Post by pd » Wed Dec 08, 2004 1:06 am

there are still some problems with it, but here is my first try:
Image

techs with the same category are always in the same row.

i decided to put the refinements in the same container as their parent application to avoid a third container type and therewith a complete mess.

to keep the connections abit more organized, they are build of lines only using 0°, 45°, 90° and -45° just as in world machine.

to keep the containers organized, they are only placed on fixed grid-like positions.

i'm eager for your comments.

i'll change the queue and remove the RP assignment arrows tomorrow.

User avatar
tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

#37 Post by tzlaine » Wed Dec 08, 2004 1:29 am

That looks pretty good. I'd still get rid of the quick-selection area, and expand the description and effects panel to fill that space. That way, you'd have enough room to show most or all of the description and effects at the same time.

The Tech tree area looks good as well, but I have a question. What makes the Applications line up the way they are? Why aren't the first four Apps all in one column? Is it based on something like total RP cost?

Also, there is a small problem with attaching the Refinements to the Apps as you have done. This implies that Refinement 2 requires Refinement 1, but we may have a situation in which there is a subtree of Refinements, with more than one Refinement available at a time. We need a way to show dependencies for Refinements as well, so they should be separate, like just cheaper Applications.

EDIT: Since Refinements can potentially choke the display, maybe we should have a "Show Refinements" checkbox or something.

User avatar
BreadMan
Space Squid
Posts: 88
Joined: Fri Aug 06, 2004 1:37 am
Location: Chico, California

#38 Post by BreadMan » Wed Dec 08, 2004 2:10 am

Yeah, that's one of the solutions I was thinking of, though I hadn't thought of grouping refinements in like that.
While the little circuit-board connections look cool, they're horrible in a usability sense. I had to look at it for a few minutes before I could figure out which side was the theories and what was depending on what. Just make them arrows, and ditch the little bullets on the ends.
You may just not have gotten this far yet, but the more info you can get at a glance the better. Give each category its own color, possibly an icon, and make any arrow leading out of something in that category the same color. This would solve situations like in the middle of the pic where the two dependency lines cross; it looks like its one line curving back on itself at first glance.
Also, I'm still seeing a lot of text in there, and cliche as it may sound a picture really is worth a thousand words.
Last edited by BreadMan on Wed Dec 08, 2004 2:14 am, edited 1 time in total.
Good afternoon! This is the Earth Alliance embassy diplomatic office. My name is Alex. How may I assist you?
HUMANS! BLAUGHRAN EMPIRE CLAIMS PLANET KREIGHTON! YOU GIVE RAY GUN SCIENCE OR BLAUGHRANS DESTROY HUMANS ON KREIGHTON!!!

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

#39 Post by Geoff the Medio » Wed Dec 08, 2004 2:10 am

tzlaine wrote:EDIT: Since Refinements can potentially choke the display, maybe we should have a "Show Refinements" checkbox or something.
Hence my ruminations on expandable / collapsable tree levels for refinements / appliations... An application could have an expand tree button that shifts everything else to the right to make space for the tree of refinements that sprouts from it. Similarly, a theory could have an expand tree but that shift everything to make space for the tree of applications and other theories that sprout from it. To show prerequisites that are hidden in a collapsed tree, we could have a special connector icon for the line linking the two techs to differentiate between requiring the root of the collapsed tree, and something hidden in the tree. When you expand the tree, the connector would move from the root to the specific tech that it requires (or the root of the newly unveiled application whose collapsed tree hides the refinement you need...)
pd wrote:techs with the same category are always in the same row.

...

to keep the containers organized, they are only placed on fixed grid-like positions.

i'm eager for your comments.
How do you deal with additional theories? You only have one for each category shown...

What is the significance of the horizontal position of the applications? What if there are several applications of a certain tech level (whether "tech level" is a specific in game term or just a rough sense of where something is)... you've put all the theories on one page, so there's no vertical space to put applications / other theories in parallel... everything in a given category is lined up linearly. This seems like a bad idea to me... (hence I resuggest tabs for each category).

User avatar
utilae
Cosmic Dragon
Posts: 2175
Joined: Fri Jun 27, 2003 12:37 am
Location: Auckland, New Zealand

#40 Post by utilae » Wed Dec 08, 2004 3:29 am

MULTI CATEGORY LINKS
I think that there should be a seperate tech tree shown for each category (ie tabs).

Also linking one application to another across category's is too complex imo. Really we just need to say what this application requires. Maybe you could hover the mouse over the app and it would say:
prerequisites
-'requires Mega guns lv3 [found in category weapons]'
-'requires Laser Propulsion lv1 [found in category engines]'

When you look at the tech you would see a description and that would tell you what prerequisites are needed. This would be simpler than looking through a web of techs to see which way the arrows go, etc.


REFINEMENTS
I think we can do this a few ways:
1)
Application(Laser)
------------
|.............|_Refinement(autofire)
|
Refinement(continuous)

Here as Tzlaine stated, refinements are smaller applications.

2)
Application Lv1
|_refine to level x

The application starts at level 1 (unrefined). You can refine the application (increasing its level). At certain levels refinement techs become available.

We can emulate multiple refinements (like in 1 above) by having multiple refinements unlocked at certain levels
eg
Laser level 2 unlock-autofire, unlock-continuous
Laser level 3 unlock-shield piercing+10%
Laser level 4 unlock-damage+10%, unlock-SplashAtTarget

Both 1 and 2 do basically the same thing, though I think 2 does it in a more simple way.

User avatar
BreadMan
Space Squid
Posts: 88
Joined: Fri Aug 06, 2004 1:37 am
Location: Chico, California

#41 Post by BreadMan » Wed Dec 08, 2004 5:43 am

utilae wrote:MULTI CATEGORY LINKS
I think that there should be a seperate tech tree shown for each category (ie tabs).

Also linking one application to another across category's is too complex imo. Really we just need to say what this application requires. Maybe you could hover the mouse over the app and it would say:
prerequisites
-'requires Mega guns lv3 [found in category weapons]'
-'requires Laser Propulsion lv1 [found in category engines]'
Yeah that's the other solution. After playing around I think that's best. Since I beleive we're planning on having each tech have its own icon, just have a smaller version of the icon in the corner of the dependent tech in it's category's color, with a hyperlink to that tech. Actually what I was thinking in my first mockup, though it was so dark you couldn't really tell. Arrows are just going to get messy, take a look:
Image
And that's really with a minimum of interdependencies. Think of what a full end-game completely unlocked tech tree would look like.
Good afternoon! This is the Earth Alliance embassy diplomatic office. My name is Alex. How may I assist you?
HUMANS! BLAUGHRAN EMPIRE CLAIMS PLANET KREIGHTON! YOU GIVE RAY GUN SCIENCE OR BLAUGHRANS DESTROY HUMANS ON KREIGHTON!!!

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

#42 Post by Geoff the Medio » Wed Dec 08, 2004 6:23 am

BreadMan wrote:Since I beleive we're planning on having each tech have its own icon, just have a smaller version of the icon in the corner of the dependent tech in it's category's color, with a hyperlink to that tech. Actually what I was thinking in my first mockup, though it was so dark you couldn't really tell. Arrows are just going to get messy
[image]
And that's really with a minimum of interdependencies. Think of what a full end-game completely unlocked tech tree would look like.
The massive complexity is why I suggested having the collapsable subtrees, as you've done, and having hidden prerequisites shown with a special connector, so it's clear that the tech to which the line connects isn't the actual prerequisite, but rather it's a tech in the tree branching from that tech. The idea would be to show all (backward) prerequisites lines for techs that are visible, however not necessary all (forward) lines to techs unlocked by a visible tech are shown... only those lines going (forward) to currently visible techs. Thus you only see the connector lines going (forward) to techs you can currently see... allowing the complexity to be adjusted to show only what you need to know (lines (backwards) to what you need to get all visible techs). (I hope that was clear...)

We could also add an option to only show lines (backwards) for prerequisites that haven't yet been researched... so if you research something, all (forward) lines leading out from it are removed (unless its tree is collapsed, and the prerequisite (forward) lines connect to the stub of the tree (the researched tech), but that would be indicated with a different connector).

Otherwise, I rather like your mockup...

My only major concern is whether it's possible to program all this, and how to represent the tree in a compatible way. It might be possible to work out a few rules to locate prerequisite lines and move them around to account for expanding and collapsing trees...

User avatar
BreadMan
Space Squid
Posts: 88
Joined: Fri Aug 06, 2004 1:37 am
Location: Chico, California

#43 Post by BreadMan » Wed Dec 08, 2004 7:19 am

Yeah I've decided the "windows explorer," expand and collapse system that you have always argued for and drek had in his first mockup would probably work best. Another solution for reducing complexity is to only show the connection lines for whatever node it is you have selected, but then that also means more clicking to see what you want.
As to removing the "up arrows" (up being forward along the tree) as I think you're suggesting, I think its important to always be able to see the next steps in research so you can plan ahead. You know, cases where you may not need refinement H, but its a prereq for application R a little way down the tree so it might be worth getting now.
Good afternoon! This is the Earth Alliance embassy diplomatic office. My name is Alex. How may I assist you?
HUMANS! BLAUGHRAN EMPIRE CLAIMS PLANET KREIGHTON! YOU GIVE RAY GUN SCIENCE OR BLAUGHRANS DESTROY HUMANS ON KREIGHTON!!!

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

#44 Post by Geoff the Medio » Wed Dec 08, 2004 7:45 am

BreadMan wrote:I think its important to always be able to see the next steps in research so you can plan ahead. You know, cases where you may not need refinement H, but its a prereq for application R a little way down the tree so it might be worth getting now.
In that case, you'd open up the tree for application R and note the displayed prereq for the refinement... It's a tradeoff, but we'll probably need to keep the number of lines down as much as possible...

User avatar
Tyreth
FreeOrion Lead Emeritus
Posts: 885
Joined: Thu Jun 26, 2003 6:23 am
Location: Australia

#45 Post by Tyreth » Wed Dec 08, 2004 7:58 am

Another option is to do it how SMAC did it. Show the tech description and icon. From that show the prerequisites and techs it leads to as boxes linked to it with just their name. These boxes are all clickable to view the techs the currently viewed one links to. That way you never see the full tree, but you can follow the path of a technology.

The downside to this is it is not immediately obvious how far down the tree you are, or just how much a given tech requires. The advantage is that it conserves space and is much easier to navigate for limitted uses.

Post Reply