Welcome, Guest. Please login or register.

Pages: 1 ... 3 4 [5] 6 7
Print
Author Topic: WIP - HUD and the GUIs, feedback needed !  (Read 50817 times)
Gaspard
Community member

Posts: 479


The Blackest Heart


View Profile
« Reply #60 on: January 04, 2011, 08:52:36 PM »

Blah from IRC:
The fading away
, if it can be made to work - then you can actually see the numerical values and do your calculations (if need be)
When you sort an item by bulk - for a few seconds after the "sorting" action, the bulk is shown and then fades away again.
Bulk and/or weight or quantity etc
Logged
Technomage
Admin
Community member

Posts: 80



View Profile
« Reply #61 on: January 05, 2011, 05:03:06 AM »

The inventory concepts look great! I was talking with barra today and he suggested that I collaborate with y'all to get some of the inventory mockups in-game for a more thorough analysis.

I'm not too familiar with Pychan and its XML scripting, but if we can agree upon a set of functional requirements I can start implementing it in-code.
Logged

"There are more atoms in the period at the end of this sentence than you can count in a lifetime." Science is awesome.

mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #62 on: January 05, 2011, 06:55:12 AM »

I've written down some starting points for the GUI designers how to work with Pychan. Still heavy WIP, but it's a start:
http://wiki.parpg.net/How_to_script_the_ingame_GUI
Logged
Q_x
Admin
Community member

Posts: 553



View Profile
« Reply #63 on: January 05, 2011, 09:19:36 AM »

Pychan... Uhh...

Inventory is mostly text driven now (plus icons and bars).
Just few things to clarify:
"Belt" should have few more slots?
We are going to give up with drop-down menus for sorting and use left/right arrows to Filter/sort? (how about just left-right clicking the text there?)
Would we need a dummy there in the middle? (http://www.nlm.nih.gov/exhibition/historicalanatomies/browse.html have some decent old anatomy books, Gautier's is my faved one since years  Cheesy)
« Last Edit: January 05, 2011, 05:28:18 PM by mvBarracuda » Logged

mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #64 on: January 05, 2011, 05:35:48 PM »

Pychan... Uhh...
We spoke about the topic with technomage last night, as it wasn't really sure who would be responsible for which parts of the GUI design workflow.

We agreed upon trying out this workflow:
1. Mechanics department designs mechanics
2. GUI designer creates GUI screen mockup based on mechanics
3. Graphics artist creates interface art
4a. GUI designer implements GUI screen via pychan's XML-based GUI scripting
4b. Programmers assist with GUI creation where necessary; especially if specific Python code is needed beyond the XML-based GUI scripting

So far the plan is to provide documentation that is easy enough to understand for the GUI designers so that they can implement large parts of the GUI via pychan's XML-based GUI scripting. I'm not too sure how well this will work out, but leaving all the GUI scripting work to the programming department is not really an option either. The programmers already got their hands full with work right now and pychan's XML scripting isn't that hard to get started with.

I propose to check out the wiki article linked above to get started with pychan. Please let me know what kind of additional information about working with pychan would be needed/helpful to get the GUI designers started.
« Last Edit: January 05, 2011, 06:07:15 PM by mvBarracuda » Logged
qubodup
Admin
Community member

Posts: 261



View Profile Email
« Reply #65 on: January 06, 2011, 12:08:57 AM »

Looks good!  I don't have a preference for hover vs. non hover.  Although I am generally a "hover" type guy.
I'm sorry, I was in a hurry and didn't clarify: The non-hover mockup is while the mouse/cursor does not hover an item, the hover mockup is the same situation but with the mouse/cursor hovering an item.

The two images are showing the same design in two states (mouse is not hovering icon, mouse hovers icon)

The inventory concepts look great! I was talking with barra today and he suggested that I collaborate with y'all to get some of the inventory mockups in-game for a more thorough analysis.

I'm not too familiar with Pychan and its XML scripting, but if we can agree upon a set of functional requirements I can start implementing it in-code.
Great! I'm experienced in coding XHTML, so I'll probably be able to help setting up the static screens. Hopefully I'll learn quick enough to aid in scripting!

1. "Belt" should have few more slots?
2. We are going to give up with drop-down menus for sorting and use left/right arrows to Filter/sort? (how about just left-right clicking the text there?)
3. Would we need a dummy there in the middle? (http://www.nlm.nih.gov/exhibition/historicalanatomies/browse.html have some decent old anatomy books, Gautier's is my faved one since years  Cheesy)
1. It's the actual belt item I was thinking of. The belt slots would be below the notebook I thought, as they would appear during 'normal' gameplay. (This is what I thought. There's enough space to place all belt slots in the notebook as well). Alternative are possible too.
2. the arrows indicate more that you can change filtering. I think click-action arrows are 'nicer' than a drop-down menu, which requires click-mousemove-click-action.
3. Not sure. Perhaps in the background? It shouldn't be an anatomical drawing since inventory has nothing to do with anatomy though, maybe a human outline like in drakensang ( http://alturl.com/xn6mj )?
In case you or anybody else would like to make modifications to the latest mockups I made: xcf: http://www.box.net/shared/lzcngfqrvx
« Last Edit: January 06, 2011, 11:01:53 AM by qubodup » Logged
Q_x
Admin
Community member

Posts: 553



View Profile
« Reply #66 on: January 08, 2011, 06:50:45 PM »

I was going to start some drawing today. I have done nothing yet. So I may ask a question. Or two. Simple.
50x50 or 64x64 for inventory cell size? (we may use smaller icons, just the grid size matters)
do we want to have a row of buttons to change between wearing, barter and container view?
Logged

qubodup
Admin
Community member

Posts: 261



View Profile Email
« Reply #67 on: January 09, 2011, 03:32:20 AM »

1. Size: I'm for 64x64 px.

2. Switch wear/barter/container: I'm for separating the views (no buttons) and while in barter/container view, worn items are shown in the inventory but marked 'worn' or have a body icon over them. Like in Morrowind (boxes around worn items).
Logged
Q_x
Admin
Community member

Posts: 553



View Profile
« Reply #68 on: January 09, 2011, 07:48:53 PM »

Something wicked, but lemme straighten things.
Its a mockup.
It shows roughly what should go where. How much things would fit (both inventory cells and text quantity).
It also shows latest graphics I've done, committed to the code tree.
It also shows and describes what is what.

It is messy. Sundays are always messy. Otherwise it wouldn't be Sunday today.


* notebook_with inventory copy.jpg (249.22 KB, 780x545 - viewed 664 times.)
Logged

qubodup
Admin
Community member

Posts: 261



View Profile Email
« Reply #69 on: January 13, 2011, 03:02:02 AM »

I see some problems:
P1. bars have no label
P2. difference between broken and broken, worn item can't be seen
P3. selection of item is hard to notice, so is hover

I have some questions:
Q1. multiple items can be selected? (wood, plastic bag are both selected?)
Q2. I find stats more interesting than a drawing and would rather see the stats next to worn items, rather than use the space for the drawing. What do you think of having stats in foreground and a silhouette in the background?

Sorry for taking so long to reply Smiley
Logged
Q_x
Admin
Community member

Posts: 553



View Profile
« Reply #70 on: January 13, 2011, 09:28:22 AM »

I see some problems:
P1. bars have no label
P2. difference between broken and broken, worn item can't be seen
P3. selection of item is hard to notice, so is hover

I have some questions:
Q1. multiple items can be selected? (wood, plastic bag are both selected?)
Q2. I find stats more interesting than a drawing and would rather see the stats next to worn items, rather than use the space for the drawing. What do you think of having stats in foreground and a silhouette in the background?

P1 - there is no text in place on that mockup. I simply presented only the things that I have done with a kind of description. Showed how they fit our small background and so on.
P2 - this was my intention. If its bad idea, I can add one more set of stuff. We can also stack this bitmaps.
p3 - selection is a simple frame, but pretty visible, and hover could be maybe even weaker, at least my taste says so.
I wanted, in general, to make this graphics not too absorbing. So that player focuses on icons rather than on those features.

Q1 - Selecting multible items is a must, I think
Q2 - snowman is a joke there, really. I'm for having stats on top.

To summarize state of things:
UI elements are ready, stored in our trunk.
Inventory grid cells are stackable. I will add/correct it without problems. Also .psd files are in our media branch.
Fixed size notebook is in trunk
Scalable notebook is there as well, with some description, because it is messy without one.

Also, I have forgotten to produce tabs sticking out of the paper. Since we are currently making only one piece I don't know how urgent it is to have them, or how many should I prepare. I have awful lot of work, it will have to wait until weekend.

After tabs (which are I think a feature to be implemented later, material for it sits in media branch, hidden in notebook.psd, just in case I would die), I'm pretty much out of  ideas what could I make to ease and speed up things.
Logged

qubodup
Admin
Community member

Posts: 261



View Profile Email
« Reply #71 on: January 13, 2011, 03:07:41 PM »

P2 - this was my intention. If its bad idea, I can add one more set of stuff. We can also stack this bitmaps.
p3 - selection is a simple frame, but pretty visible, and hover could be maybe even weaker, at least my taste says so.
I wanted, in general, to make this graphics not too absorbing. So that player focuses on icons rather than on those features.

Q1 - Selecting multible items is a must, I think
[...]
Inventory grid cells are stackable. I will add/correct it without problems. Also .psd files are in our media branch.
Also, I have forgotten to produce tabs sticking out of the paper. Since we are currently making only one piece I don't know how urgent it is to have them, or how many should I prepare. I have awful lot of work, it will have to wait until weekend.

After tabs (which are I think a feature to be implemented later, material for it sits in media branch, hidden in notebook.psd, just in case I would die), I'm pretty much out of  ideas what could I make to ease and speed up things.
Thanks for the answers!

P2. One should be able to tell the difference unless we agree that broken items can't be worn.
P3. "Focus on icons" because it looks nice and immersive? I'd say yes, but the selection must be noticeable enough for easy use. I guess we should talk about this when playtesting and if we notice that we are constantly searching for what the item is we selected last.
Q1. Multi-item-select would be useful if complex item management was part of the game. We want to avoid this, so perhaps we don't need multi-item-select?

@Stackable: I don't understand what "Stackable" means
@Tabs: Yeah, I think they're not too important right now but it would be good to know where they are, so space can be planned for them when doing a first gui implmenentation.
@WhatNow?: I'd say we should try implementing the new inventory. What programmers would like to help with pychan/xml files?
Logged
Q_x
Admin
Community member

Posts: 553



View Profile
« Reply #72 on: January 13, 2011, 03:48:01 PM »

@ multi select - Icon background will work no matter it is one thing selected or many.

@ "stackability" - the grid cells I have prepared are simply transparent. So, if you are pixel-perfect in placing them, you can layer as many as you want. Or you can use them as "flat" grid (so no stacking).

@ tabs and place for it. In all borders I left consistent space of few transparent pixels as a place for tabs. It was so also with non-scalable notebook. This may ease things when designing scalable gui, as all the elements (tabs, grid) will fit into the background tightly (or may be totally irrelevant as well).
Logged

qubodup
Admin
Community member

Posts: 261



View Profile Email
« Reply #73 on: January 14, 2011, 05:15:54 PM »

@ multi select - we should discuss what multi-select could be good for
@ stackability - I think I don't understand what you mean by stacking
Logged
Q_x
Admin
Community member

Posts: 553



View Profile
« Reply #74 on: January 14, 2011, 07:26:10 PM »

stacking - in this case - is placing one bitmap over another, like layers.
Logged

Pages: 1 ... 3 4 [5] 6 7
Print
Jump to: