GUI scripts

P

ph101

Guest
Hi there,

I had a quick look on the market place but didn't really find what I was looking for. I'm hoping to find some simple user interface scripts - like a collection of different types of toggled buttons, scroll bars, tabs that I can learn from or adapt. Does anyone have any pointers?

Thanks.
 
P

ph101

Guest
Hey - thanks. I will take a look. Problem is this seems to be based on multiple objects. I might be wrong but it doesn't look ideal for integrating into complex menu set ups where the script will handle changing or returning values. I was hoping for more of something along the lines of this:

draw_get_button(x,y,str,width,height,color,hover,bgcolor)

But it seems like there are not many of these out there really. Does everyone just code their own buttons or other UI elements from scratch generally?

edit. more detail: I'm aiming for one menu object, it handles drawing a series of buttons that open windows, featuring more buttons, pop ups, interactive elements. I'm not certain building an object for each item is the best solution really.
 

GMWolf

aka fel666
Look for the zui engine. Its great.
Also, using multiple objects to represented to each element is recommended. It allows you to more abstractly represent your GUI. And actually make script callback much easier.

Having a single object represent a bunch of menus is generally a bad thing. It leads to very poor design and makes it very hard to work with.
 

Juju

Member
I'm not certain building an object for each item is the best solution really.
One word: inheritance. If you're designing a load of buttons, you want to be able to share basic functionality without getting into messiness. GUIs aren't typically expected to be fast so object overhead isn't a concern. The main production issue with GUI is actually designing and implementing the bloody things so anything that can be done to make that less of pain is a Good Thing.
 
P

ph101

Guest
One word: inheritance. If you're designing a load of buttons, you want to be able to share basic functionality without getting into messiness. GUIs aren't typically expected to be fast so object overhead isn't a concern. The main production issue with GUI is actually designing and implementing the bloody things so anything that can be done to make that less of pain is a Good Thing.
Ok, can I quiz you? Imagine you are making an RTS like C&C, or a builder like simcity - and have for example a 'ribbon' of buttons at base of GUI, you want to click on each to say open a scrollable panel which contain a bunch of units/items to build. Other times it opens a pop up with info and also buttons. Are you saying you would have a seperate object for each button there? And a seperate one to place them initially/remove them when you close a panel ? I would normally make a controling object that has states, a loop that draws each button, detects a click on each, draws the panel if in that state etc. That way you can control the spacing easily and not have to coordinate between objects, and think about creating and destroying them. Doesn't using code like that mean you have more control, and less messiness? I may be missing something, no doubt I am, but surely using a scripted appoach is "inheritable" - your button script all has same functionality and can return a value/modulate a variable just as easily or more so right? And I don't need to jump into other objects to look at that codenad what it does?

It allows you to more abstractly represent your GUI. And actually make script callback much easier.
What does the callback script do? The action on click for example? How is that more abstract and more useful?
 
Last edited by a moderator:

YanBG

Member
I'm making my own UI. Having one object for the persistent bars(health, mana and other icons) works fine, but i have few more objects for the different menu sheets that are closed most of the time like inventory, journal etc(you could probably go without them it's just the old way i was doing things...)

I based the code on this tutorial, it's a draw_text script that you call for each line and you can click on the text itself, hovering will color it etc.


For icons the mouse coordinates part is the same but you need to get the size of the icon's sprite.

I haven't get to bars and scrolling yet, but draw_healthbar might be used for that?
 

Juju

Member
Are you saying you would have a seperate object for each button there?
Yes.

And a seperate one to place them initially/remove them when you close a panel ?
The panel would be another object (in this case, it'd use a surface to clip the buttons' graphics, whose sprites would be drawn to that surface).

That way you can control the spacing easily and not have to coordinate between objects
You don't have to coordinate between buttons at all - the panel object does all the spacing, creating, and destroy.

surely using a scripted appoach is "inheritable"
You're trading inheritance in objects for inheritance in scripts instead (e.g. a specific button snippet/script calling a common "handle mouse over" script).

And I don't need to jump into other objects to look at that codenad what it does?
I prefer to conceptualise buttons as objects here because I can do animations and graphical effects inside the same container as the logic. If I were using scripts to control each button, I'd need to store a lot of information manually (probably inside a JSON) and then deal with that myself. GM's objects do a lot of the thinking for you... creating a parallel system to replicate behaviour isn't a great use of your time.
 
P

ph101

Guest
Thanks, I appreciate the input and feedback. I do get what you mean about using GM logic when there.

The panel would be another object (in this case, it'd use a surface to clip the buttons' graphics, whose sprites would be drawn to that surface).
Ok just to delve deeper if I may - yes, I totally plan on using surfaces that way, but this is where I start to have a problem with buttons. THere's going to be a load of them, they will be labelled according to text in an array, they need to sort themselves in a list depending on which ones are available in which panel, and they need to be within a scrolling surface panel. So for this I can't get my head around objects. Here I use a for loop to draw a button at regular points, and the related text from array type deal. So I was looking for a script instead of drawing. Not done a surface part yet. But I can't envisage objects here, its why I worry about Zui although I will have a look. Perhaps its a combination of both, but on big GUIs with many series' of buttons, i'm not sure objects are going to work for me here. I'm just exploring options to improve my system here, and hoping to learn from people's experience with these kinds of more complex GUIs.
 
Last edited by a moderator:

Juju

Member
I've resigned myself to the "fact" that GUIs require an awful lot of hand-coding in any situation. Whilst there is some stuff you can automate, if you want to make your transitions really flash and swishy, you're gonna need per-button states and timers and other widgets and doo-dahs. Objects seem, to me, to be the fastest way in.
 
Top