Making an UI in c++

Started by
6 comments, last by Manumeq 6 years, 2 months ago

Hello everyone.

Me and a bunch of classmates are making a videogame from scratch in c++. We are currently using the Irrlicht Engine in our code, but will begin to develop our own engine in a couple of weeks. One of our concerns right now is the User Interface.

After doing some research, I found several libraries for creating a GUI in c++, problem is in the past we have spent more time learning and figuring out how to make things work with libraries than we would have if we actually made the entire code from scratch ourselves.

So, I wanted to ask more experienced game programmers out there, what would be your preferred choice? using a library or writting the code from scratch when making an UI, and in case of the libraries, which ones would you use?.

Heres what we will most likely do:

  • Healthbars
  • Displaying numbers in HUD
  • Displaying icons (images) in HUD
  • Drawing game menu elements (text and rectangles)

Also, we are currently working in linux, more specifically Manjaro KDE and without IDE's (using our own make file and the console).

PD: Sorry in advance is this is in the wrong topic, It's my first time asking a question in GameDev.net

Advertisement

Most people would point to https://github.com/ocornut/imgui when people ask about UI libraries, however i don't know how appropriate it is for in-game UI as you describe. If all you want is to display simple HUD information it might be simpler to roll your own. You're requirements will probably become more complicated though so think ahead.

Usually the requirements of in-game UI and tools UI are different (tools might need way more complex and elaborate views). If your usage example is exhaustive, you won't need a lib since rendering texts and rectangles is something your engine will need to be able to do anyway.

A bit off-topic, but no IDE's in a team project of a game engine? After a few thousand of lines and dozens of files, this might slow down the team a lot - human memory is unreliable.

2 hours ago, Kirlim said:

A bit off-topic, but no IDE's in a team project of a game engine? After a few thousand of lines and dozens of files, this might slow down the team a lot - human memory is unreliable.

What does a plastic shiny wrapper around the real tools have to do with human memory, and why do you think it would speed up a team to have all that fluff and facepaint to wade through to do real work?

Stephen M. Webb
Professional Free Software Developer

I tend these days to a HTML5 driven UI as pointed out for some more times in this forum. HTML5 has the advantage that changes could be made easily without any tool or grphical editor just by editing the source file, style changes made with CSS keep the (possible compiled) source clean and make look-and-feel changes a thing of just replacing a file. DOM traversel is also very fast (if you implement it fast) and could be very memory efficient.

HTML5 has a strict standard as same as CSS so you wont have to invent your own and just take what is already there. There are also articles arround how a web browser does its rendering of the DOM to have an entry point for your UI renderer.

While this is for a simple quick-and-dirty project, you could also code anything hard into your software for a more rapid solution

Based on your requirements (assuming you keep it simple) I would probably go with my own implementation, but if you need more advanced components it's better to use library and focus on the game.

Text stuff:

I think bitmap fonts could be enough for you but you know better what your project needs.

When it comes to libs: except ImGUI that was already mentioned you could also consider: https://github.com/vurtun/nuklear.

UI not related: rather that writing your own makefiles you could take a look at premake or CMake for your builds - but that's up to you (personally I prefer premake).

Good luck
 

 

Thanks everyone. Your advice was much appreciated! Right now we are taking a chance with ImGUI but will consider making our own implementation on the future.

This topic is closed to new replies.

Advertisement