Qube's Game Framework - The dreaded GUI

[Qube]

After doing a few games for the comps here the time has come to rewrite my very cheap and cheerful tools into something more productive and useful. I've been tinkering with extending my game framework and tools over the months but the underlining core was always the brute force quickest coding method used to initially create them due to the game comps time length.

So it's out the window with a shed load of code / tools and time to do things in a more orderly fashion \o/

It occurred to me that I'm going to need a GUI, arrrgggghhhhhh. I don't need a huge sophisticated GUI but I do need one that has all the basics that work well. Tonight I started on such GUI... More \o/ blah, I hate GUI's but it's needed.

I thought I'd chart my progress through the creation of the GUI and forthcoming tools in a worklog.

Without further ado, here's day one's progress. Which shows multiple windows and then selection of said windows ( very boring but GUI coders may appreciate it, honest! ). The goal of the GUI's side is to be very performant and I've tested it with 200+ windows and the frame rate remains super smooth.

Next step is to move the Windows around with the mouse. I bet ya can't wait for that video?

[blinkok]

What language are you using? Blitz, AGK etc

[Matty]

For a game....(not an editor...a game) - most guis probably just needs buttons, text fields, labels, editable text fields, panels and borders, and that's about all really isn't it?

[blinkok]

Maybe listbox, radio button and checkbox as well
I'm not sure i've ever seen a game that uses drag able windows though. Not that i've seen many games

[Qube]

What language are you using? Blitz, AGK etc

It's AGK as when I get around to doing the tools like the tile map, level editor, sprite / animation editor, particle editor, etc. I want so see exactly how it'll look in the game. The idea is to have hot keys in the game to bring up certain tools so I can make changes, save and continue on testing in a live environment.

My goal here is to finally do a complete game dev toolset framework.

I'm not sure i've ever seen a game that uses drag able windows though. Not that i've seen many games

Me either but at this stage it's for the tools which will be accessible during development and not an in-game GUI. Having said that the GUI will be multi-skinable ( as in multiple skins with the same GUI code base simultaneously ) so the more game based basic features can be used in a game if needed.

For a game....(not an editor...a game) - most guis probably just needs buttons, text fields, labels, editable text fields, panels and borders, and that's about all really isn't it?

I've worked out for the tools I'll be needing moveable windows, buttons, edit boxes, text areas, scroll bars / areas, radio buttons, tick boxes, dropdown boxes, list boxes, toggle switches, main menu, popup menus, progress bars. I don't need things like tabbed groups or multi column lists but if the need arises I'll add them in.

I'll also be doing a GUI designer so I'm not doing boring slow GUI stuff via code all the time. All the tools will be outputting source code and not just some markup language to parse through so for example in the level editor if I setup a sprite to move / animate around then it'll output source code rather than a script which then gets interpreted.

[blinkok]

If you are going to have content outside the size of the window, which can be accessed using a scrollbar ie. clipping, I would suggest you do some extensive testing on the scissor commands.
In my experience this is the only way to clip the contents of the window other than rendering to a canvas (which would mean handling all the inputs independently).
For one i have noticed that the EditBox only clips the text, Not the background or outline.

[Qube]

If you are going to have content outside the size of the window, which can be accessed using a scrollbar ie. clipping, I would suggest you do some extensive testing on the scissor commands.
In my experience this is the only way to clip the contents of the window other than rendering to a canvas (which would mean handling all the inputs independently).
For one i have noticed that the EditBox only clips the text, Not the background or outline.

Never fear, I'm an expert with scissors and having them cut at any location with any dimension

[blinkok]

lol

[Derron]

Next to standard stuff my framework has...as it is used in my games:

Slider
SelectList
SlotList (empty slots can be replaced with items...predefined list size)
Modal Window (disabling underlaying stuff)
ScrollablePanel

Some elements use other base widgets to fullfil their task (scrollbar: two buttons plus interactive click area. Etc.).

Also the lists etc have dragndrop support between the widgets.

Bye
Ron

[Qube]

Also the lists etc have dragndrop support between the widgets.

Yeah, I’ve thought about drag and drop stuff but at the moment I can’t see a good reason for it to speed up dev during game development. Time will tell as the GUI becomes production ready and tools are created. I may need more than anticipated.

Very early days yet but I hope the initial thoughts and pre planning work out

[Derron]

Dunno much about AGK but as widgets need to inherit functionality you need to think about such stuff before if you cannot simple extend a type from another in your language.

My widget system also based on events to allow loose coupling (A doesn't need to know about B to still receive the information about an action in B). This might not be needed in AGK as you include everything so A knows about B,C,D ....


And I forgot about a "textarea" widget - which means blocktext, scrolling - and in a later incarnation maybe even a caret/cursor for editing. Where do you use it? Map editor: "description block" or ingame-script-edits.
If you do not need that, then your "label" widget must allow multi-line.


bye
Ron

[Steve Elliott]

Good luck with this addition to your framework.  It might not be as interesting as game making, but will facilitate quick production when these features are required for a project.

[Qube]

Finally spent some more time to make a little progress on my GUI. I can now move windows around, set text labels and hover over buttons in active windows, thrilling

Still loads to do yet adding in all the gadgets but I'm glad I have the basic underlying code up and running. I would like to say all the hard work is done but being a GUI I just know it's going to kick me when ever it gets the chance to throw in bugs

The GUI is skinable but as this is only for me and will be used in a dead of night then I've gone for a dark basic look over a happy shiny one.

Video goodness :

[Qube]

The GUI is coming along well and I've not much more to do now *finally* - I can then move onto the GUI designer and then start on a shiny new map / level maker \o/

Quick performance test with 24 active windows which is about 1000+ sprite draws to make up the GUI elements + background logic and running at a silky smooth 60fps. Who said AGK was slow?

( scaled down image )

[Steve Elliott]

Looking very swish, and other coding software to follow.  Cool.