Jump to content

  • Log In with Google      Sign In   
  • Create Account

Which will be better for gui?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
27 replies to this topic

#21 Nathan2222_old   Members   -  Reputation: -400

Like
0Likes
Like

Posted 14 December 2013 - 12:04 AM

Does a game engine have a UI like blender (since that's what i'm trying to do)

UNREAL ENGINE 4:
Total LOC: ~3M Lines
Total Languages: ~32
smile.png
--
GREAT QUOTES:
I can do ALL things through Christ - Jesus Christ
--
Logic will get you from A-Z, imagination gets you everywhere - Albert Einstein
--
The problems of the world cannot be solved by skeptics or cynics whose horizons are limited by the obvious realities. - John F. Kennedy


Sponsor:

#22 JTippetts   Moderators   -  Reputation: 8508

Like
4Likes
Like

Posted 14 December 2013 - 08:39 AM

There are a number of different ways you can approach the UI problem for a game.

 

1) Use a large toolkit of general-purpose 'widgets' for users to use, and remove from the users any responsibility for implementing the actual widgets or having to deal with them in any way outside of usage. Users only wire up various pre-determined widgets together to build a UI. This is the approach that toolkits such as Qt use. They often do provide the ability of allowing the user to build custom widgets via plug-in. The problem with this approach is how heavyweight it is. There may be a lot of features and tasks going on that you just don't need in your game engine. Also, many of these toolkits want to handle everything, including rendering using their own rendering process that stands outside your game pipeline. In the case of Qt, I believe that is where a lot of the performance hit comes from. These general-case UI frameworks tend to be mostly designed for standard document and UI models such as you see in non-game applications, in order to give users a familar-feeling interface; think "File Edit View" menu bars and docking toolbars.

 

2) Use a general-purpose widget toolkit as above, but impose on the user the requirement of supplying a front-end for the toolkit to use to handle some jobs, such as rendering and input handling. I believe this is how CEGUI works. The user must provide functionality to allow CEGUI to render itself, using the user's own rendering framework; additionally, the user must gather inputs from their own input system and inject those into CEGUI. This can provide performance bonuses, since the user can ensure that the UI rendering routines are optimized for their particular framework, rather than relying on whatever rendering engine the UI framework developer wants to use.

 

3) Write your own. General-purpose toolkits, I've noticed, tend to include lots of the "standard" types of widgets: radio buttons, list views, etc... Lots of things that games don't necessarily need. Additionally, they often don't have direct analogues for things like Skill Icons with a cooldown sweep, drag-and-drop inventory slots, health globes with swirly, multi-layered animated textures and perhaps a custom shader (think Diablo 3 health globes here; for all the flaws of that game, those health and resource globes are awesome; but you won't find a widget for them in Qt, no sir).

 

 

There needs to be a difference between the UI that you use for the game proper, and the UI that you use for editor and tools. There is no reason your editor needs to have a swirly layered health globe widget in the interface, and there is no reason that your game needs to have a listview box rendered in default Windows style. Game UI and tool UI are just too different.

 

My personal preference is to use 1 for tools. When your task is to build a tool, you don't want to get bogged down in the messy details of implementing UI from scratch. At worst, I would go with 2 and use CEGUI, if Qt just wasn't going to work for me. For the game, I almost always go with 3.

 

Now, many engines provide UI capabilities themselves, and if the engine was built with games in mind then a few of the widgets might be suitable for game use. But even so, I typically expect to have to do a lot of work implementing the things like swirly health globes, things that it just isn't practical to expect the engine developer to provide, since such widgets are so dependent upon the style and feel of the game itself.

 

As far as a Blender-like interface, you're not going to find such a thing built into many engines, since Blender's interface was tuned and tooled with Blender's needs in mind. Games typically require other styles. You might conceivably find game tools built with such an interface in mind; and, in fact, Blender itself is both a game engine and a game tool. But as far as standalone engines go, you might have your work cut out for you trying to find an engine whose packaged editor tools use an interface like Blender's. You might end up having to write that UI yourself.

 

The take-home message here is that everything is so highly dependent upon the engine framework that you choose. Also, expect to have to do a lot of tedious work to tweak any pre-built UI libraries to your needs, since flexibility equates to complexity, and no framework can possibly take everyone's needs into account.



#23 Nathan2222_old   Members   -  Reputation: -400

Like
0Likes
Like

Posted 14 December 2013 - 09:48 AM

There are a number of different ways you can approach the UI problem for a game.
 
1) Use a large toolkit of general-purpose 'widgets' for users to use, and remove from the users any responsibility for implementing the actual widgets or having to deal with them in any way outside of usage. Users only wire up various pre-determined widgets together to build a UI. This is the approach that toolkits such as Qt use. They often do provide the ability of allowing the user to build custom widgets via plug-in. The problem with this approach is how heavyweight it is. There may be a lot of features and tasks going on that you just don't need in your game engine. Also, many of these toolkits want to handle everything, including rendering using their own rendering process that stands outside your game pipeline. In the case of Qt, I believe that is where a lot of the performance hit comes from. These general-case UI frameworks tend to be mostly designed for standard document and UI models such as you see in non-game applications, in order to give users a familar-feeling interface; think "File Edit View" menu bars and docking toolbars.
 
2) Use a general-purpose widget toolkit as above, but impose on the user the requirement of supplying a front-end for the toolkit to use to handle some jobs, such as rendering and input handling. I believe this is how CEGUI works. The user must provide functionality to allow CEGUI to render itself, using the user's own rendering framework; additionally, the user must gather inputs from their own input system and inject those into CEGUI. This can provide performance bonuses, since the user can ensure that the UI rendering routines are optimized for their particular framework, rather than relying on whatever rendering engine the UI framework developer wants to use.
 
3) Write your own. General-purpose toolkits, I've noticed, tend to include lots of the "standard" types of widgets: radio buttons, list views, etc... Lots of things that games don't necessarily need. Additionally, they often don't have direct analogues for things like Skill Icons with a cooldown sweep, drag-and-drop inventory slots, health globes with swirly, multi-layered animated textures and perhaps a custom shader (think Diablo 3 health globes here; for all the flaws of that game, those health and resource globes are awesome; but you won't find a widget for them in Qt, no sir).
 
 
There needs to be a difference between the UI that you use for the game proper, and the UI that you use for editor and tools. There is no reason your editor needs to have a swirly layered health globe widget in the interface, and there is no reason that your game needs to have a listview box rendered in default Windows style. Game UI and tool UI are just too different.
 
My personal preference is to use 1 for tools. When your task is to build a tool, you don't want to get bogged down in the messy details of implementing UI from scratch. At worst, I would go with 2 and use CEGUI, if Qt just wasn't going to work for me. For the game, I almost always go with 3.
 
Now, many engines provide UI capabilities themselves, and if the engine was built with games in mind then a few of the widgets might be suitable for game use. But even so, I typically expect to have to do a lot of work implementing the things like swirly health globes, things that it just isn't practical to expect the engine developer to provide, since such widgets are so dependent upon the style and feel of the game itself.
 
As far as a Blender-like interface, you're not going to find such a thing built into many engines, since Blender's interface was tuned and tooled with Blender's needs in mind. Games typically require other styles. You might conceivably find game tools built with such an interface in mind; and, in fact, Blender itself is both a game engine and a game tool. But as far as standalone engines go, you might have your work cut out for you trying to find an engine whose packaged editor tools use an interface like Blender's. You might end up having to write that UI yourself.
 
The take-home message here is that everything is so highly dependent upon the engine framework that you choose. Also, expect to have to do a lot of tedious work to tweak any pre-built UI libraries to your needs, since flexibility equates to complexity, and no framework can possibly take everyone's needs into account.


Sunk deep. Qt and CEGUI for my engine UI, while CEGUI and my tweaks for my game UI. Thanks.
I wasn't really referring to the actual blender UI but since people were confused, i had to think up something and i chose blender's UI. My game UI and game engine UI will be nothing alike. My game will have a more 'gtaish' menu (more designed menu) while my engine will have a more blenderish/mayarish UI (simpler but more designed), they will be so different (very). Thanks again.

UNREAL ENGINE 4:
Total LOC: ~3M Lines
Total Languages: ~32
smile.png
--
GREAT QUOTES:
I can do ALL things through Christ - Jesus Christ
--
Logic will get you from A-Z, imagination gets you everywhere - Albert Einstein
--
The problems of the world cannot be solved by skeptics or cynics whose horizons are limited by the obvious realities. - John F. Kennedy


#24 Nathan2222_old   Members   -  Reputation: -400

Like
1Likes
Like

Posted 14 December 2013 - 09:53 AM

Not directly related to my post. It's good to have a paper and pen, you never know what your mind can think up. Just got the best 2nd engine software idea ever. Can't wait to become really good at c++ and game dev. Thanks all

UNREAL ENGINE 4:
Total LOC: ~3M Lines
Total Languages: ~32
smile.png
--
GREAT QUOTES:
I can do ALL things through Christ - Jesus Christ
--
Logic will get you from A-Z, imagination gets you everywhere - Albert Einstein
--
The problems of the world cannot be solved by skeptics or cynics whose horizons are limited by the obvious realities. - John F. Kennedy


#25 Lactose!   GDNet+   -  Reputation: 3476

Like
3Likes
Like

Posted 14 December 2013 - 10:13 AM

Pen and paper are extremely helpful tools for programming as well, not just for jotting down an idea to avoid forgetting it.

 

If you're having troubles implementing an algorithm, or doing various kinds of math (simplifying equations, solving geometric problems, etc), doing it by hand can be very beneficial.



#26 BHXSpecter   Members   -  Reputation: 1577

Like
1Likes
Like

Posted 14 December 2013 - 11:04 AM

Pen and paper are extremely helpful tools for programming as well, not just for jotting down an idea to avoid forgetting it.

 

If you're having troubles implementing an algorithm, or doing various kinds of math (simplifying equations, solving geometric problems, etc), doing it by hand can be very beneficial.

I completely agree. That is how I figured out the collision detection on Pong when I was programming it years ago.


"Through vengence I was born.Through war I was trained.Through love I was found. Through death I was released. Through release I was given a purpose."


#27 Nathan2222_old   Members   -  Reputation: -400

Like
0Likes
Like

Posted 14 December 2013 - 12:25 PM

Pen and paper are extremely helpful tools for programming as well, not just for jotting down an idea to avoid forgetting it.
 
If you're having troubles implementing an algorithm, or doing various kinds of math (simplifying equations, solving geometric problems, etc), doing it by hand can be very beneficial.


Even though there are basic, they are so important.

UNREAL ENGINE 4:
Total LOC: ~3M Lines
Total Languages: ~32
smile.png
--
GREAT QUOTES:
I can do ALL things through Christ - Jesus Christ
--
Logic will get you from A-Z, imagination gets you everywhere - Albert Einstein
--
The problems of the world cannot be solved by skeptics or cynics whose horizons are limited by the obvious realities. - John F. Kennedy


#28 Felix Ungman   Members   -  Reputation: 1036

Like
0Likes
Like

Posted 16 December 2013 - 02:54 AM

Has anyone tried to use http://blogs.gnome.org/clutter/ for game UI?

 

I'm also searching for a suitable UI framework and looked briefly at Qt and CEGUI. Both seem a bit too heavyweight or complex for what I need, and clutter seems more what I'm looking for. I don't need a lot of different widgets types, just a few standard ones and some custom ones. I want a lean C/C++ library, that focuses on the UI architecture, and nothing else. It should be dynamic, i.e highly moddable, preferrably with lua scripting.


openwar  - the real-time tactical war-game platform





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS