Needed suggestion for tech-screen UI

Development of artwork, requests, suggestions, samples, or if you have artwork to offer. Primarily for the artists.
Post Reply
Message
Author
User avatar
BreadMan
Space Squid
Posts: 88
Joined: Fri Aug 06, 2004 1:37 am
Location: Chico, California

#76 Post by BreadMan » Thu Dec 09, 2004 9:13 pm

No, it's not obvious, because at first glance you don't know which way is forwards. Do you start at the top and go down? The middle and go outwards? If you can't tell at first glance, its not intuitive.
you just need to know, that it's not possible to go backwards
That's a precondition, you're assuming the user will know this, that they'll read the manual before playing the game. In Asian languages they read right to left, how can you know someone will automatically look to the left to begin? It may sound dumb, yes on the second glance they'll probably figure it out, but that's not what's important. The first glance is what's important. I'm talking about basic design philosphy here.

§ Affordances – does it look like it should be used the way it is supposed to be used?
§ Mapping – does the design of the control suggest the effect of its use?

Ok, I'm getting a little too preachy here aren't I :P Anyway, my point is, its pretty damn simple to add arrows, and there's really no reason not to.
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
pd
Graphics Lead Emeritus
Posts: 1924
Joined: Mon Mar 08, 2004 6:17 pm
Location: 52°16'N 10°31'E

#77 Post by pd » Thu Dec 09, 2004 9:27 pm

build into the ui, the tree will have a number of features not shown at this stage, including greyed out boxes(not possible to research yet), marked boxes(possible to research) and full colored boxes(already researched) or something similar... so it will be clear right from the beginning, where it starts and where it goes.

that been said, of course you could add arrows, but they are simply not needed in this case, imho.

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

#78 Post by Geoff the Medio » Thu Dec 09, 2004 11:12 pm

pd wrote:
Why?
i told you... because it's more organized.
How is lines connecting to other lines at seemingly random places "more organized"? (You didn't explain how / why they are connected where they are...) Or, if you mean that it just looks nicer / opener / less complicated, that's more a feature of the example than the system (see below).
actually i've come to the conclusing, it's better to use as few links as possible, because if you link too much you will force the player to research everything. we should allow the player more freedom in the decision which way he chooses to go in the tree.
I didn't mean that a real tree would have more links between a small number of techs so you'd have to research everything. I meant that a real tree would have many more techs, all spread out, and thus more links regardless of how many links there are per tech.

I don't expect a real tree to be so tightly linked as my mockup. The mockup is just to show the various features I proposed, which was easiest to do in a smaller space with lots of links all over the place. Having lots of optional redundant paths is the main reason I want the ability to expand / collapse the tree... so that you can hide the branches you don't care about.

It looks like you've got expand/collapse buttons on your mockup, which are all open... Is that what they're for, and if so, how do they work?
if we don't combine them the tree will spead more and more. we could prevent this with just removing one connection. but then again, you would force the player in one direction...
We could also consider having an "or" connection, so if you research one or the other, you can get the next theory... or make the next theory dependent on a big age-advanccement theory from the "Learning" category, rather than theories from within the category.

But more likely, we can make theories dependent on previous theories, rather than applications. The number of theories would be quite small compared to applications, so researching all theories isn't a big waste of time, and there's plenty of choice of which applications branches to skip.
it would be nice if we could come up with a xml representation of the techtree to minimize the coding effort instead of letting the code build the tree.
That was what I had hoped... to generate it algorithmically on the fly. It'd probably be easier to modify the tree if each tech is just represented by its prerequisites, rather than trying to code the whole tree structure into XML, which probably won't work at all since we can have multiple inheiritance...
BreadMan wrote:@ Geoff's latest diagram
I don't think its so much that people don't understand the expand / collapse idea, I think its just the way you're showing it. Just having a little (+) on the line with nothing else around it isn't very intuitive, and hard to find in that big web of things.
Is there a better way to represent a collapsed section of the tree? The (+) could be to the left of the root tech, and the various lines could connect directly to the tech box, rather than the (+), more like in Windows directory explorers...
I had to look at your two diagrams pretty hard before I could find what was different between the two.
I find this rather hard to accept... there's a big box added right in the middle, and I referred to the purple lines of the first diagram in the explanitory text. You say you understand expanding / collapsing, so this should be clear. I could have made a basic closed / open tree illustration, but that wouldn't serve to illustrate all the details I was suggesting. Also, keep in mind that the expanding / collapsing of a tree would be in response to a player's clicking on a + or - icon, and hopefully animated, so it would be clear where a change has occurred and why. The player could open and close the branch repeatedly if it's difficult to see (which I still don't think it is, aside from the rather busy example tree I've used, which isn't the fault of the system itself)
Needs to be more indication that something will happen by clicking there, like an icon next to it or something.
What more obvious of an icon do you need than a circle with a + or - in it? It would presumably have some mouseover highlighting feedback, if that helps... maybe it'd change into a => arrow to indicate the tree would expand to the right when you click?
Also I think just the way you've got everything arranged is confusing, hard to see any natural progression of things, kinda scattered. Changing the lines to arrows would help immenseley.
I have to agree with pd that it'd be much clearer in a real system with all the researched / available GUI information that's not shown in these basic mockups. That said, I can see some benefit to putting arrows or directed animation (like move orders on the galaxy map), in addition to highlighting and other graphical hints as to what's going on. There's no real reason not to... in the real GUI... but these mockups aren't meant to be final, so it's not necessary to put in all that stuff at this stage, which discussing more fundamental issues.
And also, while many of these diagrams look good, they're still all just small parts of what is probably going to be a huge tech tree. While they may work on a smaller scale, they're gonna get a lot more confusing when you have to deal with 40x the info
40x is a rather low estimate, I'd think, given all the applications and refinements and such. But this is exactly why we need an expandable / collapsable tree... to hide all the extra info that doesn't matter anymore, or info that is not immediately relevant because it can't be researched for some time.

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

#79 Post by BreadMan » Fri Dec 10, 2004 12:17 am

Yeah yeah, my bad, I know they're all just mockups. My apologies, I was getting picky and lost the scope of the assignment. Gotta remember we're all working together on this, not competing for the "best research ui" prize :P. But yeah, you're right, I wasn't picturing things with regard to what they'll look like with a fully flushed out tree with complete techs, etc. Anyway, hopefully I'll get some time to finish up what it is *I* have in mind tonight or tomorrow. I think I'll shut up til then :)
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
pd
Graphics Lead Emeritus
Posts: 1924
Joined: Mon Mar 08, 2004 6:17 pm
Location: 52°16'N 10°31'E

#80 Post by pd » Fri Dec 10, 2004 12:20 am

geoff wrote:It looks like you've got expand/collapse buttons on your mockup, which are all open... Is that what they're for, and if so, how do they work?
of course they are open. i wanted to show the different relations and i hoped everyone can imagine by himself how they work... next mockup will bring clearness.
geoff wrote:We could also consider having an "or" connection, so if you research one or the other, you can get the next theory
actually those 'arbitary, seemingly random placed' connections _are_ logical ORs, thought you know allready.
geoff wrote:But more likely, we can make theories dependent on previous theories, rather than applications.
ok, this is nitpicking. you can do this with my tree pretty easily.
geoff wrote:40x is a rather low estimate, I'd think, given all the applications and refinements and such.
imo it's a good estimate. maybe it's even too high... imagine, my tree mockup has 16 items -> x 40 = 640 items... probably about 300 beeing theories and apps.... i don't know how you feel, but i think this is pretty much.

then again it's not that hard to display since they are fragmented on 5 categories(read 'trees') each having about 130 items. a very rough forcast would say that each category-tree would be about 8 times wider than my current tree... sounds ok to me.

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

#81 Post by Geoff the Medio » Fri Dec 10, 2004 12:53 am

pd wrote:actually those 'arbitary, seemingly random placed' connections _are_ logical ORs, thought you know allready.
By arbitrary placement, I refer to the physical location on the graph where lines connect to other lines, not the meaning of the connections. You disliked having all lines connect directly to the tech, which I preferred, but you have not explained how it will be determined where on the graph your lines will connect. This is what I want to know. If lines don't connect to techs, they have to connect to other lines... So which line and where and why? In your first mockup (p. 4 of thread), the locations, and what lines connect to what other lines when there are multiple options, seem arbitrary.

Whether the connection is an OR or and AND or NOT is (probably) a separate issue...

Also, I suggest using a symbol to indicate OR connections as well as AND connections, to avoid ambiguity (I didn't get that only the specifically marked AND connections were ANDs until now... I had thought all were ANDs and wondered why you put in a few AND connectors in select places... I understand now though...).

Also also, I suggest having the AND (and OR) arrows always point to the right, rather than down or up when a vertical lines meets a horizontal. Different arrow directions suggest different meanings, which (I think) is not intended...

Also also also, I'm not a huge fan of the digital logic / electronics-style AND and OR symbols... IMO more intuitive ones could be found. If you're just using AND and no specific OR symbols, I suppose it's OK to just use the AND ones though...
geoff wrote:But more likely, we can make theories dependent on previous theories, rather than applications.
ok, this is nitpicking. you can do this with my tree pretty easily.
This was not a critcism of, or related to, your or my tree GUIs. It was a suggestion about general tree design... not related to the GUI with which it is represented.

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

#82 Post by pd » Fri Dec 10, 2004 1:02 pm

So which line and where and why? In your first mockup (p. 4 of thread), the locations, and what lines connect to what other lines when there are multiple options, seem arbitrary.
i did this more intuitive, but it's of course possible to describe the line behaviour:

take a look at this in a new window/tab while reading the following, i'm describing the sitiuation in the bottom left:
once, spread out by a splitter the lines tend to go back to their root line. they can go back if there is no tech connected directly to the prior one. as you can see the lines after R1 and R2 join each other, while R3 can't because there is an A following R3. right after this, the line coming out of A joins the root. then, this 'sub-root' line joins the main root which comes out of the first 'splitter'. as you might notice it's pretty hard for me to describe this in english, i hope i was somewhat clear though.
Also, I suggest using a symbol to indicate OR connections as well as AND connections, to avoid ambiguity (I didn't get that only the specifically marked AND connections were ANDs until now... I had thought all were ANDs and wondered why you put in a few AND connectors in select places... I understand now though...).
i'm sorry for this... the OR connection seemed just so natural to me, that i haven't further marked or described it.
Also also, I suggest having the AND (and OR) arrows always point to the right, rather than down or up when a vertical lines meets a horizontal. Different arrow directions suggest different meanings, which (I think) is not intended...
yep, my fault. basicly i haven't thought about the possibility to indicate the direction when i made the first mockup, it's fixed now.
Also also also, I'm not a huge fan of the digital logic / electronics-style AND and OR symbols... IMO more intuitive ones could be found.
ANDs and ORs are the most basic operators, imo they are great for what we need here.(while the usage of ORs is still debatable, since it has some effect on the requirements idea - see below)

as promised here is a view of the tree whith most parts collapsed:
Image

now, back to the ORs. in my last mockup i didn't use them, because it's a design descision.
here are 3 possible ways to continue the tree:

1. the 'OR-way'(i would prefer this one):
Image
it gives a lot freedom to the player and keeps the tree strait, but it would mean, that some techs won't have fixed requirements. this is most likely not part of the v0.3DD. i guess the reason for this is simply, because no one has thought about this before.... so we should do it now.

2. the 'spread-way':
simple, the tree spreads out in multiple roots.
Image

3. the 'kill-one-way'

to avoid spreading and to keep the tree strait we simple kill one root.
Image.

that's it for now. in my next post i will break the tree down to it's ellements and explain how everything works in detail. also i will continue with the actual ui design.

edit:
forgot to mention the fourth way by using an AND of course.

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

#83 Post by Geoff the Medio » Fri Dec 10, 2004 2:03 pm

pd wrote:once, spread out by a splitter the lines tend to go back to their root line.
Ok, that makes some sense now (graphically).
Also also also, I'm not a huge fan of the digital logic / electronics-style AND and OR symbols... IMO more intuitive ones could be found.
ANDs and ORs are the most basic operators, imo they are great for what we need here.(while the usage of ORs is still debatable, since it has some effect on the requirements idea - see below)
I was complaining about the SYMBOLS, not the idea of AND or OR being in the tree. AND and OR are fine... just not the little triangle SYMBOL for AND and the little curley pointed arrow SYMBOL for OR like in electronics designs.

To illustrate a point, I've made there very crude mockups...

First, the tree with applications and refinements shown. (Note: arrows indicate direction of "unlocking" in case of ambiguity where lines meet)
Image

Second, the tree "trunk", with just theories.
Image

Key ideas:

The main tech tree trunk is composed of theory techs (only). All appliations and refinements (and perhaps some theories as well) branch off from the main theories trunk, forming "subtrees".

Rather than researching a theory, then one of three techs unlocked by that theory, in order to get the next theory, you just research the first theory and can immediately get the second theory. The unlocked applications and refinements (subtrees) from the first theory may be reserached or not, but doing so is not necessary to progress through the main trunk of the tree. Subtrees are optional.

The player's choices would be mostly which main branches of the tree to research, and which subtree(s) to research, and how far into those subtrees to research before switching to a subtree sprouting off a later (better) theory.

Theories can unlock refinement in subtrees of other theories, allowing some degree of synergy between two theories. These techs should mostly be optional within their subtree, however.

There should be multiple independently viable paths through the main tree trunk. Probably, ever so often, a big age advancement theory in the learning category will unlock new theories in the other categories, which act as the start of a new tree trunk. Researching theories in previous trunks may or may not be necessary for theories / applications in the new trunk.

If possible, I'd like to avoid all "OR" connections, but in order to make separate main branches of the trunk independently viable, it may be necessary / desirable to have "OR" connections in the trunk every so often, in order to bring the separate branches back together to a common result, without forcing the player to research all the theories in both branches.

Edit: Also, regarding pd's mockups only using right angles for lines, as opposed to my older mockup's using 45 degree angled lines... I find the latter to be much more attractive. All right angles seems boxy and clunky, while angles seem more elegant and... not sure what word... not organic... not "high tech"... just... I like it better with angled prerequisite lines... m'kay?

User avatar
noelte
Juggernaut
Posts: 872
Joined: Fri Dec 26, 2003 12:42 pm
Location: Germany, Berlin

#84 Post by noelte » Fri Dec 10, 2004 3:34 pm

1 - Make's it really sence to have OR condition?? To be honest i don't like this idea.

2 - IMO, symbols from electronic designs shouldn't be used at the tech tree (for instance AND)
Press any key to continue or any other key to cancel.
Can COWs fly?

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

#85 Post by pd » Fri Dec 10, 2004 3:38 pm

i just finished some minor updates on the ui
Image
- added a button to jump right into the encyclopedia(opened in a new window or entire screen)[/list]
btw, we could add a third tab here called 'picture/icon'. this way we gain more space for the description. but since you can easily access the encyclopedia now, a short description is enough imho.

- changed the queue and removed the overfunding possibility
noelte wrote:small issue, i would like to see a progressbar behind currently reseached techs.
does this make so much sense in a turnbased game? since everything works with turns, it's logical to provide the turn number left...

@geoff: i'm in a hurry atm, will comment your post tomorrow.

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

#86 Post by utilae » Fri Dec 10, 2004 8:07 pm

pd wrote: btw, we could add a third tab here called 'picture/icon'. this way we gain more space for the description. but since you can easily access the encyclopedia now, a short description is enough imho.
I don't think we need a third tab, it looks fine the way it is with the pic and text side by side.
pd wrote:
noelte wrote:small issue, i would like to see a progressbar behind currently reseached techs.
does this make so much sense in a turnbased game? since everything works with turns, it's logical to provide the turn number left...
Yeah, I think it would be better to show 'turns left', although I guess it is ok to have both a progress bar and turns left.

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

#87 Post by LonghornXtreme » Fri Dec 10, 2004 8:50 pm

I wouldn't mind a very slight semi transparent progress bar either... Since the game is in openGL there should be an easy way to code it in that still looks tasteful... that would help someone remember just how long they've been working on a tech... etc...

User avatar
Ablaze
Creative Contributor
Posts: 314
Joined: Tue Aug 26, 2003 6:10 pm
Location: Amidst the Inferno.

#88 Post by Ablaze » Tue Dec 14, 2004 9:14 am

The whole game is in openGL and you are still using 2D images for practically every UI in the game? You people amaze me.
Time flies like the wind, fruit flies like bananas.

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

#89 Post by utilae » Tue Dec 14, 2004 9:50 am

Ablaze wrote:The whole game is in openGL and you are still using 2D images for practically every UI in the game? You people amaze me.
I think a UI looks better in 2D then in 3D. In the end I would like to be able to move through the UI quickly, rather then stop and look at the stars.

drek
Designer Emeritus
Posts: 935
Joined: Thu Jun 26, 2003 8:07 am

#90 Post by drek » Tue Dec 14, 2004 3:39 pm

pd wrote:i just finished some minor updates on the ui
Looking pretty good to me pd.
does this make so much sense in a turnbased game? since everything works with turns, it's logical to provide the turn number left...
Progress bar could be just a couple a colored bar underneath the 10/34 turns text.

Post Reply