• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
JoshuaWaring

Tips for Programming a GUI

15 posts in this topic

I'm about to commence my first GUI, I was wondering if anyone has any times on how I should structure the data and classes? Something that might help me with future issues.

0

Share this post


Link to post
Share on other sites

You could do something like this: make your own GameButton class and have new buttons you create inherit from the GameButton class.

 

To think data structure is to think of object oriented composition. Each button should have some notion of representing itself (i.e: an image,  position(x and y coordinate), have a mouse listener(so the buttons can listen for mouse events). Add these buttons object to the canvas so the buttons can listen the mouse events from the canvas.

Edited by warnexus
-1

Share this post


Link to post
Share on other sites
My GUI is built on top of SDL for a map editor, but I'm writing it to also act as the game GUI. I've got the idea of a hierarchy design and positions to be stored relative its parent entity.

SDL will Handel all my keyboard and mouse events.

I seem to be on the right track.
0

Share this post


Link to post
Share on other sites

The key to a good GUI is your event handling system.

 

When someone clicks on a button, how do you link that to code?

 

There are plenty of techniques depending on programming language, but they basically come down to two core technologies.

 

Callbacks and messages.

 

Callbacks are simple and direct, you link the button to a subroutine which does the real work.

 

Messages are a little more complex, you click on the button. It adds a message to the list. At some point in your code you parse any pending messages and clear the list.

 

I prefer callbacks. They can be called events, signals, callbacks, all sorts of things, but they all work the same way.

 

The only other thing I would advise is that you don't use scaling. I hate the look of scaled graphics. So to draw a button you draw the four corners, draw the sides, then fill the middle instead of just drawing a scaled version of the button.

 

Other than that, have fun. I love writing GUI's, I particularly like making strange effects like circular folding menus, animated buttons, animated transitions.

2

Share this post


Link to post
Share on other sites

The implementation of a GUI system has aspects of input processing, graphical representation, and effect.

 

1.) Clarify whether immediate mode or retained mode GUI is what you prefer.

 

2.) Define how input is handled (fetched, collected, prepared) before it is provided to consumers.

 

3.) Define whether provided input is pushed to consumers or pulled by consumers. E.g. when running down an iteration of the game loop, the various sub-systems are called anyway and hence may investigate provided input whenever they are updated. This is an alternative to the push model which is known from application programs.

 

4.) GUI elements compete with other GUI elements and with game controller objects. Define how routing of input to the various possible consumers is to be done. Is the gameplay view just another widget?

 

5.) Define how the effects of action widgets (e.g. when pushing a button) is processed. E.g. does it invoke a callback, sends a message, or sends a command object?

 

6.) Define how the effects of value widgets (e.g. when dragging a slider knob) is processed. E.g. alter a local value, use a callback, send a message, send a command object, or change the target value in-place (the latter is fine for tweaking).

 

7.) Depending on the targeted platform: Make the graphical rendering resolution (DPI) independent by using scalable graphics / multi-resolution graphics.

 

8.) Even more important (IMO): Make the placement independent on the aspect ratio by using various anchors (horizontally left / center / right, vertically top / center / bottom) and a resolution independent length (e.g. normalized with the display height).

 

 

Hopefully you don't need things like table or outline views and drag & drop, because they make things really complicated.

2

Share this post


Link to post
Share on other sites

Hello there, Gamedev forums! : )

I feel like it is appropriate for me to make my first post in this thread, as thinking about UI/GUI implementations have took up a lot of my free time in the past months, or even a year. (HTML5 indie, refusing to use CSS for "proper" buttons, since I plan on going to mobile as well, and I do not want to be dependant of DOM/CSS in any way whatsoever).

So, I have arrived at a point where my implementations was this:
a. You have a class named uiNode, which has an attached onExecute() function, and has a -initially empty- uiNodes[] array as well.
b. Upon updating your game/scene, you see if you have clicked on one of your nodes. You can do this via just getting the mouseclick and compare it to a list of your nodes (so the click has to be within the boundraries of your virtual button/menu item).
c. Each uiNode of yours can contain more uiNodes (they always automaticallly have an empty uiNodes[] array), and it is possible to have an onExecute() that does nothing else but "opens up" a set of buttons, that were otherwise invisible/inactive before. 

So you have basic elements that are either visible or not, clickable or not (these things are different for a reason - you might have invisible buttons that are tied to pictures, or visible, but not yet clickable buttons that become active when something changes them), and due to the recursive nature of this.uiNodes[n].uiNodes[m].uiNodes[l]...., you can have submenus naturally. Your onExecute either leads to new menu points, or executes the code linked to clicking that particular button.

I found out that while this approach works, sometimes, for easier scenes (and even for something like an inventory screen), it was less of a hassle to just create my click logic independent of this structure. But when real menus are needed, this helped me.

A few pitfalls to avoid, regardless of what language you are aiming for:
- Have a way to dynamically change size/positions - you are not always in this with the same resolutions, after all

- Do not check each button's click state every frame, that can get demanding fast in main menus. Instead, just make a list of your active nodes and cycle through their positions whenever a click occurs. That way, you do not have scenarios where overlapping buttons/texts activate at the same time. You can even define rules like nest levels, click hierarchy, etc.

- What others posted here: define your needs, and do not go overboard with it. I spent way too much time on this, time that should have gone towards the implementations of the game rules, not arbitrary ui structure building. I do not regret it, but it might not be your favorite time spender.

Edited by Sawamara
1

Share this post


Link to post
Share on other sites
You should also look at the "Immediate Mode" GUI talk on Molly rocket (https://mollyrocket.com/861). It's a slightly different way of thinking about GUI development. In my opinion it's easier to use as an end user, but not necessarily easier to build.

It's great for simple in game menus, but apparently can be used In fairly complex systems. Unity uses an IMGUI in their editor.

Cheers,

Bob
1

Share this post


Link to post
Share on other sites

While it's good to figure out class hierarchies and what features you need, don't lose sight of the purpose of the GUI - to allow the user to EASILY input whatever information the program you're writing needs.  This is one of those things that some would dismiss as 'the easy part', but it's not (see: KDE vs Gnome). Incidentally, documentation is another thing that falls into this category - even Eric Raymond once wrote in an 'open letter' to open source developers saying, in effect, "We've done the hard part, now just do the easy stuff and write the manual."  Sorry Eric, writing isn't easy - it's a craft that takes years of hard work, training, critques, and more practice to learn. Design is much the same: it's a separate skillset from what you use when you code the GUI elements.

 

IOW, your GUI code could be the most beautiful, elegant code ever seen, but your GUI could still suck bollocks from the user standpoint.

 

For inspiration, I'll refer you to what may be the most widely used and easily understood GUI ever created: The Denny's Menu.

Edited by Mouser9169
2

Share this post


Link to post
Share on other sites

Hi.

I'm on my 3rd or 4th UI now. Like HawkBlood said, edit boxes list boxes imageboxes, text, dropdowns and contain them all in a dialogbox type class, this is like your window.

Use a 3d model app to create and place buttons then export to your format and load it up.

 

some thing like this

 

Basemenu

               load();

               free();

               render();

              dokeyinput();

              domouseover();

             onleftclick();

           ect.........

 

 

then create a menu say for load screen

class MenuLoadScreen :BaseMenu

{

doo stuff

};

 

basemenu *base = new MenuLoadScreen();

 

then you can have a list of them

vector<BaseMenu*> MenuSystem;

 

and define input elements for the location of the menu

 

#define LOADMENU_ID     0

 

MenuSystem[LOADMENU_ID]->render();

 

or use a CurrentMenuID to change menues.

0

Share this post


Link to post
Share on other sites

One note unless GUIWindow is this I recommend a UIPanel class. This is pretty much just a group of components that has a size and can organize children relative to its position. It lets you anchor points and you will need a margin / anchor property to make sure everything lines up unless you are only wanting to support 1 resolution. Another convenient figure is if you allow it to clip children. Then you can create scroll views. Most gui utilities support panels, grids, and other organizational items but you can get by with just a panel to be honest. Also by supporting children to organizational objects you can build together different parts to make more complicated components.  Also when you create your event system you can search through your items in a tree structure rather then a linear list. Also you NEED events / callbacks. If you are in c++ use FastDelegate as a base for your delegate system and build an event class. Most other languages have some sort of support for that otherwise.

 

Common components I use.

1. Textbox

2. Texture Button

3. Label

4. Progress Bar / Slider (these components internally will be very similar)

5. Scrollview

2

Share this post


Link to post
Share on other sites

That is what the window is, although the idea with the window is to have a border (like a popup) but a Panel could be used as a border less window to go inside of a window.

The generated diagrams don't really show it, but they are working like a tree, also not really shown are the events, if something happens the entity will return a Event which contains a pointer to the entity, event type and the entity type.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0