Welcome, Guest. Please login or register.

Pages: [1]
Print
Author Topic: GUI Architecture  (Read 7404 times)
saritor
Guest
« on: November 02, 2009, 02:44:23 PM »

Heya, I am just posting here because I know its rather difficult to get in touch with b0rland on IRC.

@b0land: I know you mentioned at the meeting last weekend that you were working on some GUI code. Would it be possible for you to throw what you have up on trac for now as I am looking in to what we are going to need to do to get the title screen in the game and just wanted to make sure that we didn't start duplicating efforts on some of the higher level GUI code necessary for that to be implemented.

~Saritor
Logged
saritor
Guest
« Reply #1 on: November 04, 2009, 03:33:17 PM »

Talked to b0rland and I am going to go ahead with a major refactor of the GUI code base. This is probably going to have an effect on the way other GUI's will be implemented in the near future so as a warning to those who are working on something in game gui related this will probably change your code a bit. I am going to post a proposal of the new layout for our GUI code on the wiki and link it here. Also plan on making a branch of the codebase since this may take a couple weeks to get implemented once it gets rolling.
Logged
saritor
Guest
« Reply #2 on: November 04, 2009, 08:51:49 PM »

Proposal which is a WIP: http://wiki.parpg.net/Proposal:GUI_Architecture

Feedback is welcome though it is still a WIP.
« Last Edit: November 04, 2009, 08:59:05 PM by Saritor » Logged
saritor
Guest
« Reply #3 on: November 10, 2009, 03:00:55 PM »

I completed the proposal and would definitely like to hear any feedback on it before I start coding a bunch.
Logged
b0rland
Community member

Posts: 105



View Profile Email
« Reply #4 on: November 10, 2009, 08:56:11 PM »

Couple of notes/questions.
1) I don't think "widgets" is the correct term to use. Correct me if I'm wrong, but seem to use it in the sense "dialog boxes", whereas traditionally I think it means "controls" (i.e. the parts that dialog box consists of).
2) "Blocking object", "Blockable object" -- will those be true/false properties or more complicated entities?
3) "Dictionary of module names to the module objects that are currently loaded in the game. " -- can you elaborate on that a bit?
Logged
saritor
Guest
« Reply #5 on: November 10, 2009, 09:18:15 PM »

Thanks for the feedback. Smiley

1) GUIWidget is intended to mean any sort of GUI that we are going to throw in the games. So a dialog box would be one kind of Widget, while the HUD would be another separate widget and so on and so forth. Maybe we should call them modules?

2) Blocking and Blockable are just true/false booleans that will be used when you call the GUIManager's show/hide methods to make sure the proper GUIWidgets are being displayed. I don't really think they need to be more elaborate than that.

3) Basically this dictionary is going to be a table of all the GUIWidgets we need to load in a game. So something like the following
Code:
self.gui_widgets = { "hud": HudWidget( /*list of arguments */), ... etc. }

Where HudWidget is inheriting from GUIWidget.
Logged
Kaydeth
Community member

Posts: 185



View Profile Email
« Reply #6 on: November 11, 2009, 02:31:10 PM »

Do we need a more fine grained control for some widgets beyond blocking/blockable?

Take the HUD for example. Generally, I think, the HUD will always be visible no matter what menu is open. However we probably want to disable the HUD when things like the Main menu are open. So will we be able to manage this? Will pausing the game disable the HUD?

EDIT: Also how will we tell the GUI manager which widget to open? Will we passing a String or some other identifier?

Thoughts about the current_widget value. How will this work when multiple non-blockable widgets are open? Which will be the current_widget? How will we manage that?
« Last Edit: November 11, 2009, 02:33:58 PM by Kaydeth » Logged
saritor
Guest
« Reply #7 on: November 11, 2009, 10:55:52 PM »

Do we need a more fine grained control for some widgets beyond blocking/blockable?

Take the HUD for example. Generally, I think, the HUD will always be visible no matter what menu is open. However we probably want to disable the HUD when things like the Main menu are open. So will we be able to manage this? Will pausing the game disable the HUD?

EDIT: Also how will we tell the GUI manager which widget to open? Will we passing a String or some other identifier?

Thoughts about the current_widget value. How will this work when multiple non-blockable widgets are open? Which will be the current_widget? How will we manage that?

Good questions. Some things that I hadn't actually thought about yet.

We may down the road need a finer grained control for the widgets besides blocking/blockable but at this point the need is rather minimal. However to address your thoughts about HUD being displayed, but disabled if a different blocking widget was called I would add another state to GUIWidget itself called locking. This would be a true/false value. When set true it would disable any widgets which were currentl in the view, not blockable, and not the current_widget.

So for example we have the following widgets made viewable in the following order hud -> main menu -> dialog box
Where the following are the properties of each widget.
hud:
blocking = false
blockable = false
locking = false

main menu:
blocking = true
blockable = false
locking = true

dialog box:
blocking = false
blockable = false
locking = true

(This may also answer some questions about current_widget as well)
The following would occur when getting to this dialog box:
1. hud is just being displayed on its own and is able to be used and is the current_widget.
2. the main menu button is pressed causing the hud to still be viewable, but it locks the hud from being used. then is set as the current_widget
3. the man menu has an button that creates a dialog box and that gets pressed.
4. this sets the dialog box as the current_widget, then locks all other (unblockable) widgets this forcing the user to deal with the dialog box before anything else can be done.

I think this may address your question about multiple non-blockable widgets that are open simultaneously as well. Since the new locking method should provide us with a way (if we want) to limit user interaction with other widgets that may be open. So current_widget should always should be considered the top of a widget stack, where when a widget is opened it is made the current_widget (placed on top of the stack), and it order for a new widget to be made current we either open a new one (thus adding to the stack) which becomes the new current_widget, or we close the current_widget (removing from the stack) making the previous widget the current_widget.
Logged
amo-ej1
Community member

Posts: 80


elie@de-brauwer.be
View Profile
« Reply #8 on: November 12, 2009, 08:32:54 AM »

My comments on this thread so far:

-> GUIWidget isn't a very suitable name, GUIModule or something would be more suitable I guess. But what you are saying here is that there will be a class per gui module. E.g. one for main menu, one for hud, one for inventory, ...
-> Regarding the stacked approach, I still think there are some leaky things there for example:
--> Sometimes two windows have equal priority (depending on game implementation), e.g. in  a shop you typically have your own inventory and the shop inventory without one being more important than the other one.
--> The stack approach is in my eyes not compatible with the pychan approach. At this point when several windows are open you can select any window you want, and raise this. E.g. open the main menu and open the options dialog, move the options dialog and press the quit button. Things like those should be forbidden (read: you should have a strict stack approach there. However, when an inventory window, a quest log and a map could be open (depending on how we implement this) this order of opening/closing should be completely independent of each other. With this I mean that sometimes you have a strict stack-based approach, but in other situations  all you have is just a mess.

Well basically this is a chaotic version of what you wrote in your last post.  

edit: perhaps it's not a bad idea to add some practical examples to the wiki page with some image or so.  Since the example in your last post contains a rather interesting use case which makes the GUI proposal a bit less abstract.
« Last Edit: November 12, 2009, 08:34:29 AM by amo-ej1 » Logged
saritor
Guest
« Reply #9 on: November 12, 2009, 06:48:10 PM »

Alrighty, so I made a branch (<parpg>/branches/gui_overhaul for those who want to check it out, though its obviously not modified a bunch yet) and I am going to start implementing a few of these features just to see what we actually have to work with. After looking through pychan docs it may not be directly possible to "lock" a viewable GUIModule (new terminology for GUIWidget) so we might be forced into a different model rather than stack and locking methods.
Logged
Pages: [1]
Print
Jump to: