Video game GUI?
Author
I'm trying to think of a GUI system that would be versatile enough to be used for any menu system a game would ever need. I was thinking of doing it similar to html <div> tags but I never really felt html was very logical. How can I position and align gui elements in the most logical way?
Author
Are you talking about GUI scripting?
No, I'm trying to figure out how to position and align elements in a logical way. For example you would define the height and width of a div and then tell it to float left, right or centered. I never liked this design since it was limited to horizontal alignment. It also makes many things difficult to do.
Well, anyway you like/you need/what's feasible etc.
You can have absolute positions, you can have relative positions (relative to parent).
You can have positions as pixels, or as normalized positions (0..1 relative to screen or parent).
"I was thinking of doing it similar to html <div> tags" this implied scripting to me. you just use a bunch of ints/floats to store the data.
This really is a design decision, depends of what behaviour you want, is the app resizeable windowed or full screen, do you really want to have a versatile/customizable GUI. Game GUIS usually don't really have to be versatile and customizable, unless of course there's a very strong emphasis on the menus (for example a very fancy tech-three thingy). But even then, maybe only a few elements have to be customizable.
As far as I saw (okay, I'm not really in touch with the latest games), game menus are pretty simple and "wooden" compared to any other GUIS.
Because of this rigidity (usually you don't want to resize and rearrange game widgets/windows), many alignment questions become irrelevant for the game's point of view. I think the only exception is ext, where alignment does matter.
Alignment can be relevant from a GUI editor's point of view.
Maybe I still misunderstand. I don't see how div comes to play. you store a bunch of datas, anyhow you like it. I guess you are over-engineering the thing.
A GUI widget has a parent, has states, has functions (callbacks maybe), has positions, sizes, you can have some whatever flags, like alignment, absolute/relative position indicator, normalized or non-normalized coordinates indicator, whatever you need.
Most of the times, for a game you can get away with an immediate mode GUI.
You can have absolute positions, you can have relative positions (relative to parent).
You can have positions as pixels, or as normalized positions (0..1 relative to screen or parent).
"I was thinking of doing it similar to html <div> tags" this implied scripting to me. you just use a bunch of ints/floats to store the data.
This really is a design decision, depends of what behaviour you want, is the app resizeable windowed or full screen, do you really want to have a versatile/customizable GUI. Game GUIS usually don't really have to be versatile and customizable, unless of course there's a very strong emphasis on the menus (for example a very fancy tech-three thingy). But even then, maybe only a few elements have to be customizable.
As far as I saw (okay, I'm not really in touch with the latest games), game menus are pretty simple and "wooden" compared to any other GUIS.
Because of this rigidity (usually you don't want to resize and rearrange game widgets/windows), many alignment questions become irrelevant for the game's point of view. I think the only exception is ext, where alignment does matter.
Alignment can be relevant from a GUI editor's point of view.
Maybe I still misunderstand. I don't see how div comes to play. you store a bunch of datas, anyhow you like it. I guess you are over-engineering the thing.
A GUI widget has a parent, has states, has functions (callbacks maybe), has positions, sizes, you can have some whatever flags, like alignment, absolute/relative position indicator, normalized or non-normalized coordinates indicator, whatever you need.
Most of the times, for a game you can get away with an immediate mode GUI.
Author
Well, anyway you like/you need/what's feasible etc.
You can have absolute positions, you can have relative positions (relative to parent).
You can have positions as pixels, or as normalized positions (0..1 relative to screen or parent).
"I was thinking of doing it similar to html <div> tags" this implied scripting to me. you just use a bunch of ints/floats to store the data.
This really is a design decision, depends of what behaviour you want, is the app resizeable windowed or full screen, do you really want to have a versatile/customizable GUI. Game GUIS usually don't really have to be versatile and customizable, unless of course there's a very strong emphasis on the menus (for example a very fancy tech-three thingy). But even then, maybe only a few elements have to be customizable.
As far as I saw (okay, I'm not really in touch with the latest games), game menus are pretty simple and "wooden" compared to any other GUIS.
Because of this rigidity (usually you don't want to resize and rearrange game widgets/windows), many alignment questions become irrelevant for the game's point of view. I think the only exception is ext, where alignment does matter.
Alignment can be relevant from a GUI editor's point of view.
Maybe I still misunderstand. I don't see how div comes to play. you store a bunch of datas, anyhow you like it. I guess you are over-engineering the thing.
A GUI widget has a parent, has states, has functions (callbacks maybe), has positions, sizes, you can have some whatever flags, like alignment, absolute/relative position indicator, normalized or non-normalized coordinates indicator, whatever you need.
Most of the times, for a game you can get away with an immediate mode GUI.
I'm working on a game engine which really needs to be able to do anything. What it will be exactly used for is not clearly defined. CEGUI seemed like a good solution but it won't work with my project for various reasons.
Still, And engine know-it-all GUI doesn't mean a specific game GUi has to be know-it-all.
By that I mean you can threat things separately: Game GUI and GUI editor GUI. You can make a versatile, know-it-all GUI Editor that represents data, alignments any way you want (I still think it's a design decision, and your decision, there's not really "the way" to do it). Then just save the data as it will be used in the specific game.
It really depends on what YOU want. I still don't quite understand the div thing. Do you want to represent the GUI with a big text file and you want to find out how to represent the GUI data in the file? That is pretty much scripting.
Well, maybe you could use a normalized float value for the vertical and horizontal alignment. As far as I can recall, I used something similar. 0 is left, 0.5 is center, 1 is right. Then another value that represents an offset (in pixels) relative to this alignment.
I hope it makes sense, maybe it's just my fault that i don't see clearly what the problem is.
By that I mean you can threat things separately: Game GUI and GUI editor GUI. You can make a versatile, know-it-all GUI Editor that represents data, alignments any way you want (I still think it's a design decision, and your decision, there's not really "the way" to do it). Then just save the data as it will be used in the specific game.
It really depends on what YOU want. I still don't quite understand the div thing. Do you want to represent the GUI with a big text file and you want to find out how to represent the GUI data in the file? That is pretty much scripting.
Well, maybe you could use a normalized float value for the vertical and horizontal alignment. As far as I can recall, I used something similar. 0 is left, 0.5 is center, 1 is right. Then another value that represents an offset (in pixels) relative to this alignment.
I hope it makes sense, maybe it's just my fault that i don't see clearly what the problem is.
Hmm, maybe things will be more clear if you tell us what you don't find logical in the <div> thingy and why.
Author
Yeah a relative position with a pixel offset would work for most situations. However, what if I want to insert widgets between other widgets or if I want to expand a widget? The problem with an html <div> is that it does not allow you to align to bottom. Once a horizontal row is filled it will stack things below that row. This is why gamedev and many other websites use a fixed horizontal width.
You can use other values than 0/0.5/1. That is the advantage of normalized coordinates. If you resize the parent widget, its children will be repositioned with the parent, and will always sit on the 0.2 0,.86, wherever part of the window.
With offsets combined with the normalized coordinates, you can have your widgets to "stick" wherever you want them.
It shouldn't be hard to work out the maths for YOUR needs.
<div> um.... so what if it doesn't support vertical alignment? Yours will. I don't see it as a major disadvantage of div, and I still don't get why do you care about how <div> does its stuff.
Or are we talking about html programming?
With offsets combined with the normalized coordinates, you can have your widgets to "stick" wherever you want them.
It shouldn't be hard to work out the maths for YOUR needs.
<div> um.... so what if it doesn't support vertical alignment? Yours will. I don't see it as a major disadvantage of div, and I still don't get why do you care about how <div> does its stuff.
Or are we talking about html programming?
Ok, here's a phrase for you: "Program into the language, not in the language." Decide what you want to do, outside the constraints of how you will do it, then figure out how to do it in a programming langauge.
div tags work, in your theoretical GUI, however you program them to work.
div tags work, in your theoretical GUI, however you program them to work.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
