Developing a GUI specific to games [closed]

Closed. This question needs to be more focused. It is not currently accepting answers. 开发者_C百科

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 8 years ago.

Improve this question

For a while now, I have been wanting to create my own GUI "library" in C++ and DirectX 9. I have seen a ton of questions regarding GUIs, but what I want is a GUI specific to games. Most libraries are really complex and are very generic, and they offer support for command line parsing and window creation etc. These libraries don't suit my needs, so I want to write my own. The only problem is I don't know where to start.

I have no idea how to build a framework/foundation for the library. I don't know how to make the GUI elements/objects communicate with each other and how to handle events. I also have no idea how to manage the graphics of the GUI. For example, do I give the programmer full responsibility over how the GUI looks, or do I create a default design? Do I then store store a separate file for the design of a button, textbox, label, combobox etc.?

I would also like to point out that I plan on my GUI in fullscreen mode only, and that I only want to support basic elements like buttons, textboxes, static labels etc. And that I would like to be able to create a HUD with the library. I know that I am asking to many questions, but I have never tried to create anything this complicated.

---

If you have no idea about all those things, I would recommend you don't write your own GUI from scratch. (I actually did write my own game GUI from scratch, and I kind of regret it -- what I ended up with was kind of half-baked and I'm sure there are better options around.)

But I do get what you mean: You don't want to use a standard GUI toolkit because then it won't "feel" like a game. The good news is, there are existing GUI toolkits out there specifically designed for games. The most popular one appears to be CEGUI (Crazy Eddie's GUI System). As you can see from their website, it looks quite skinnable and doesn't seem like a Windows app at all.

I haven't used it, but I'd recommend looking into it before you go designing your own.

---

Writing your own gui would be a good educational task, as you will soon have to learn the design patterns that are used to make it scalable. If you are interested, the GoF book uses GUI as an example to many of the patterns.

However, it is a large (HUGE - I mean years of your life) task to do it properly.

One project that might interest you, however, is the cIMG library. This is an image processing libary rather than a gui library. It doesn't support buttons or any such like, but it does do rather low level drawing which might be closer to your final goal (it doesn't outsource its imaging to a gui/graphics library). It is also a header only library, with all code in a single header file, and so fairly easy to have a peek at.

---

I respectfully disagree with the other opinions expressed here. (bg: I studied CS in college, and I have programmed for 30 years of my life.)

You CAN write your own GUI system, and you can do so in less than 2 weeks, if you know what you are doing. Even as a somewhat advanced beginner in programming. I believe that "how to write a GUI system" is lost knowledge, leading to the idea that it takes years to write a GUI system.

I recommend (and I recognize that this is a minority report) the following strategic points in your effort:

• Forget design patterns and architecture and bus communications systems and extensibility and so on. For such a simple problem, you absolutely don't need them. If you pursue these things, your head will be living in problems that you don't even have. Don't do anything object oriented. Totally the wrong tree for what you're doing.
• Go minimalistic; And you really cannot be too extreme here. Avoid every kind of abstraction that is not absolutely necessary. Think about the individual wires in your design, think about the absolute minimum of "what needs to talk to what." Do you really need a bus system? Or can you just add a single line that performs a notification? And come to think of it, can you make it so that a notification isn't need it at all? From another angle: Do you really need click and drag windows for your game? Etc., etc.,. 9 times out of 10, "you don't need it," and there's another simpler way to do it. Finding those simpler ways is like finding the cheat codes to GUI design.
• Think from the end. Design the final user interface, on paper, for what your GUI system needs to support. LOOK AT WHAT YOU SAID: "Fullscreen mode only, buttons, textboxes, static labels, etc.,. ... a HUD with the library." This is SUPER not complicated. You can absolutely do this, cheaply, and you'll be happier because you'll have perfect control.
• Use data. Let the data tell the story of how your user interface looks and how it works. Can you draw the window and layout in printable ASCII characters in your code and render from that?
• Control the notation for the API to the drawing system (ie, DirectX). Use "ESC" to represent the keycode for the escape key, "SPC" to represent a spacebar key. Make the API convenient with your wrapper. Make it map to the basic operations of what you are doing: flip(), line(x,y,x2,y2), color(BLACK), that kind of thing.
• Use bitmaps and make it easy to access them in your API. stamp(iconid, x, y) is how stupid simple you want to make it be, to draw an icon at a position. Notice that this is NOT: window.stamp(icon.imgdata, translated_coordinate(cursorpos));
• Pay attention to your input polling and draw-flip system. That's the core of your engine. If you have modes of interaction, that's at the core as well.
• Consider using a meta/information plane for positions and coordinates and click-throughs. You could use a grid to represent the layout, dramatically simplifying your work with the GUI. When the user clicks on a space, the information plan can have the information about what is being clicked on.

I have written very sophisticated GUI environments in just 500 lines of Python (using pysdl2.) This includes my wrappers. I have also written GUI systems in C++ -- it takes more lines of code, but really not all that many more.

I absolutely 100% recommend writing your own GUI systems for your work. You will have to get "out of the box" with respect to contemporary mainstream programming ideology, but the level of control you can achieve is incredibly liberating -- not just in your work on games, but in all realms of programming which will involve interaction with a user.

If you want to get out of the mainstream box, consider reading Alan Kay, Chuck Moore, or any of the older band of programmers. They were not infected with this idea that "You must use what other people have written before you, because other people are wiser than you about what you need and how to make things, and you'd just be repeating their mistakes if you went down their road anyways," when they did what they did. Their idea of "what works" is very, radically different, than contemporary ideas of what works. I encourage the exploration.

---

There are already numerous mature solutions to this problem such as Scaleform for custom games and the integrated gui API in game engines such as Unity, not to mention the Flotsam and jetsam of the many more experienced developers who have come before you:

http://www.google.com/search?q=game+gui+library

Given your admitted inexperience and the redundancy of what you're proposing, I think you would be wise to choose something smaller and more useful to cut your teeth on.