• 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
Nathan2222_old

Which will be better for gui?

27 posts in this topic

Um, i will be making a game engine in the future (as some of you know :)). It'll be a windows directx c++ lua scripting ogre3d based 3d game engine. I'm learning c++ and planning for features for my game engine as i go. The problem now is the gui for engine.
Should i use CEGUI or Qt.
Qt is opengl and opensource but my engine will be directx. CEGUI like ogre3d is both directx and opengl, opensource and mit licensed unlike Qt's lgpl license. CEGUI seems to be mainly for game ui even though they say it can be used for other apps. Qt was used for the UI's of maya, photoshop, daz studio etc. and i've not seen that for CEGUI except for ogre's particle editor's ui. CEGUI seems more ui oriented than Qt and has the better license should i choose to make the engine commercial :).
If you've used any or both of them, what do you think. Thanks
0

Share this post


Link to post
Share on other sites

From what I know Qt is awesome for applications, but I couldn't imagine using it in a game.

1

Share this post


Link to post
Share on other sites

I recommend you read this blog post (it's part of a series which is itself pretty interesting) talking about one developer's experience with trying to use Qt for his main game UI, and the performance problems that it caused him. Qt is pretty heavy-weight. It's useful as hell, but that usefulness comes at a pretty significant performance cost. It really isn't designed for game UI. Game UI tends to be more highly specialized, since it needs but a fraction of the features something like Qt provides, and as a result tends to be more highly performant. CEGUI was built more with games in mind than Qt, but it also offers a measure of flexibility (and the attendant complexity).


Thanks. That's one part of my question answered. What of game engine ui
0

Share this post


Link to post
Share on other sites
Wait, do your answers apply to both game and game since the game engine runs the game or something like that. That would not be good.
Won't/Can't i need/use Qt to fix all the game engine pieces together and then use CEGUI to build it's UI.
0

Share this post


Link to post
Share on other sites

The game engine is a pile of linked code, it doesn't need a UI.... or are you thinking about making a level editor?  If you're wanting to make a visual tool to help make your game then yeah, you could use Qt for that... but that's a whole other level of complexity that I wouldn't recommend.  Unity, UDK etc. have their own world building tools, because they sell them... making your very own level designer is a project by itself.

0

Share this post


Link to post
Share on other sites

The game engine is a pile of linked code, it doesn't need a UI.... or are you thinking about making a level editor? If you're wanting to make a visual tool to help make your game then yeah, you could use Qt for that... but that's a whole other level of complexity that I wouldn't recommend. Unity, UDK etc. have their own world building tools, because they sell them... making your very own level designer is a project by itself.


Every part of my engine (except the source code) definitely needs a UI because if it doesn't, there is no way i'm going to be motivated to make anything in it. The UI i am refering to is what you see when you load the engine like the menus you see in torque 3d. UI's are really (really) important to me.
0

Share this post


Link to post
Share on other sites


Every part of my engine (except the source code) definitely needs a UI because if it doesn't, there is no way i'm going to be motivated to make anything in it. The UI i am refering to is what you see when you load the engine like the menus you see in torque 3d. UI's are really (really) important to me.

 

I never worked with Torque, but from what I could see, it seems you are referring to the GUI of the editor. While this might be accompanied with the engine, it's not the underlying actual engine that does all the rendering/audio/etc. 

 

It's usually your engine at work in the editor so you will be able to achieve "what you see is what you get" when comparing what you see in the editor to the game. With that being said, what Godmil actually said is perfectly valid: Anything beyond the basics (even some of the basics) is a project in itself. Doable, sure, but I would advice to at least get to know Ogre3D first, how it works and such before making an editor for it. Perhaps even better, I bet there's already plenty of level editors to some degree out there for it.

 

Judging on your (past) posts, I strongly suggest you read Game Engine Architecture by Jason Gregory to get familiar with how things actually work (it uses Ogre as a referrence as well), because at the moment it seems you are mixing things up and/or misinterpreting how stuff actually works.

2

Share this post


Link to post
Share on other sites

Every part of my engine (except the source code) definitely needs a UI because if it doesn't, there is no way i'm going to be motivated to make anything in it. The UI i am refering to is what you see when you load the engine like the menus you see in torque 3d. UI's are really (really) important to me.

 
I never worked with Torque, but from what I could see, it seems you are referring to the GUI of the editor. While this might be accompanied with the engine, it's not the underlying actual engine that does all the rendering/audio/etc. 
 
It's usually your engine at work in the editor so you will be able to achieve "what you see is what you get" when comparing what you see in the editor to the game. With that being said, what Godmil actually said is perfectly valid: Anything beyond the basics (even some of the basics) is a project in itself. Doable, sure, but I would advice to at least get to know Ogre3D first, how it works and such before making an editor for it. Perhaps even better, I bet there's already plenty of level editors to some degree out there for it.
 
Judging on your (past) posts, I strongly suggest you read Game Engine Architecture by Jason Gregory to get familiar with how things actually work (it uses Ogre as a referrence as well), because at the moment it seems you are mixing things up and/or misinterpreting how stuff actually works.

Yeah, i have the book/pdf. It was the first game engine related pdf i downloaded and i also downloaded the game engine fundamentals pdf (it doesn't have as much content as the game engine architecture but it's definitely more direct and clearly lists all the features of an engine. It's actually were i saw CEGUI). For me, game engine fundamentals is a must read. About the game engine architecture book, as i was reading it, i realised it wouldn't help me that much since i don't know c++ that much as i'm still learning it. So can i use Qt for the game engine ui or editor (the interface of an engine, i don't know ... yet, so i hope you know what i mean) and CEGUI for game ui.
0

Share this post


Link to post
Share on other sites

See it like this:

 

For your game, you want something function, but doesn't slows your game down to a slug. CEGUI is (appearantly, I never worked with it directly) one of the better options for that.

 

For your editor, you probably still don't really want it to slow down by a lot, but it's a stand alone application that makes use of your engine (doesn't even need to), The stuff your UI needs to do in here is probably a lot more varying than what it should be able to do in your game, or more data oriented I guess. So QT might be the better choice here, provided it does what you need for the editor.

 

So it's just weighing off your choices. What do you need, do you need full speed for the editor etc.

 

I didn't do any proper GUI work to give you the final solution, but if I would, those are a few of the questions I would ask myself when making something.

0

Share this post


Link to post
Share on other sites

See it like this:

For your game, you want something function, but doesn't slows your game down to a slug. CEGUI is (appearantly, I never worked with it directly) one of the better options for that.

For your editor, you probably still don't really want it to slow down by a lot, but it's a stand alone application that makes use of your engine (doesn't even need to), The stuff your UI needs to do in here is probably a lot more varying than what it should be able to do in your game, or more data oriented I guess. So QT might be the better choice here, provided it does what you need for the editor.

So it's just weighing off your choices. What do you need, do you need full speed for the editor etc.

I didn't do any proper GUI work to give you the final solution, but if I would, those are a few of the questions I would ask myself when making something.


My game being slow is not good so thanks for the advice on using CEGUI.
For the game engine, i think i may be confused. Doesn't unity/udk game engines have user interfaces i.e. you want to edit the world then you click on the world editor button and the screen changes, you want to import/export a model then you click the import/export button and a drop down menu appears, you get the picture right. I may be confused. Can some post a photo of the first screen they see when they click on their game engine icon and it loads, it'll help me get a clearer picture.
0

Share this post


Link to post
Share on other sites

Unity and UDK come with world builders, but that's not the engine. The game engine is just a collection of prewritten classes and functions that you can call in your code. 

0

Share this post


Link to post
Share on other sites

A GUI is nothing more than more than some images being drawn onscreen like anything else, most games create their own GUI elements in the engine. Generally they don't have to be as "complex" as a generic GUI toolkit like QT is or something. For instance you might add some boxes on your screen that hold items and react to mouse clicks, you can do that just by tracking mouse movement and creating reactions to clicks.

 

Torque is just one example of engine architecture, their engine has a sort of "editing mode" that is enabled in game just by having the configuration set up a certain way, this isn't necessarily how all engines work. In fact usually all the content creation tools are totally separate programs or at least are launched by providing certain special command line options to the engine to load it in a sort of "editor mode." There's no real rule about this, valve's source engine for example, they do all their map editing and content creation with separate tools.

 

How the "engine" is represented can vary a lot as well, a lot of times the game's executable is the engine, and just has game code layered ontop of it, some companies use things like dll's to represent their engine or static external libraries, it's really a case by case thing.

Edited by Satharis
0

Share this post


Link to post
Share on other sites

Unity and UDK come with world builders, but that's not the engine. The game engine is just a collection of prewritten classes and functions that you can call in your code.


Ok, i just did some googling on unreal engine gui, what is the kismet editor (i think that's what i need)
0

Share this post


Link to post
Share on other sites

I think kismet is a visual scripting tool. So a level designer could easily say create a door that opens when you move near it, just by bringing up a few boxes and connecting them with lines. It's an easier way for designers to script a level quickly without having to worry about coding. It's a guess here but I think Game Maker has similar tools.

0

Share this post


Link to post
Share on other sites
Is this right, a game engine like udk is made of subsystems including audio, graphics, AI, input system and others like memory management, world editor, scene manager etc. but to use these for your game, you write code and make your 'game ui' within the engine using something like CEGUI but all these subsystems combined to give a single sofware i.e. the engine itself and the engine has no ui so when you compile your game, it runs on the engine but the engine with ui without giving the user access to the engine tools. I'm guessing i mixed up somethings there.
Let's say my engine will use ogre, physx, havok ai and physics, directx etc. So only the renderer (ogre) and the world editor (ogre) will have a ui but physx won't have a ui. Confused
0

Share this post


Link to post
Share on other sites
I hope this isn't too demanding but can someone download the game engine fundamentals pdf because under the high level systems of a game engine, i see 'front end (user interface)' and i'm confused except 'front end(user interface)' means something different from my post.
0

Share this post


Link to post
Share on other sites

Let's say my engine will use ogre, physx, havok ai and physics, directx etc. So only the renderer (ogre) and the world editor (ogre) will have a ui but physx won't have a ui. Confused

 

I think your confused because your trying to dive in to too many things too quickly - its like if I was trying to derive the equations for a time varying signal propagating in different mediums from maxwells equations in my EE freshmen year..

 

a game engine like unity or unreal most likely uses their own ui system in game which IS part of the engine - it doesnt have anything to do with the other parts of the engine other than it may be possible to invoke other engine functions on ui events.. but this UI system doesn't necessarily have to do with the toolkit's UI system.. some engine toolkits do use the underlying engine's UI system but they dont have to

 

toolkit UIs are their own applications that can either use the underlying engine for rendering etc.. or not use the engine at all - but create files that the engine can use and knows how to load - these toolkits may let you do things like let you graphically create game menus for the game - the engine ui system would then just need to know how to read the format generated by the tool

Edited by EarthBanana
1

Share this post


Link to post
Share on other sites

Instead of creating a world editor from scratch for Ogre you may check out http://www.ogitor.org/

 

It is open source and I think contributing towards something that exists would be better than trying to start from scratch.

0

Share this post


Link to post
Share on other sites

Instead of creating a world editor from scratch for Ogre you may check out http://www.ogitor.org/

It is open source and I think contributing towards something that exists would be better than trying to start from scratch.


Thanks, i don't intend on creating anything from scratch except some things and a reall important really special thing i'll put in the engine but i do need their source codes. Been planning for features but this UI stuff. Hm
0

Share this post


Link to post
Share on other sites

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.
0

Share this post


Link to post
Share on other sites
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
1

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