Jump to content
  • Advertisement
Sign in to follow this  
  • entry
    1
  • comments
    7
  • views
    943

UI, for the love of God. UI..

Spool

1153 views

A couple months ago I decided to delve into the dark arts that are seemingly only attempted by the bravest of programmers. UI Framework development. While honestly I didn't fully understand what designing and creating a UI Framework from scratch truly entailed, I had some notion that it was no easy feat. As such should be approached with caution if not entirely avoided as the amount of UI Frameworks available are as numerous and the reasons not to make one yourself. But, I decided to embark on the journey anyway..

 

I guess the first big question you would ask is, Why? Why would you want to do that. 

To be honest, I asked myself that very question. The answer I came up with may seem rather shallow and the hallmark of an inexperienced developer..

They all suck. 

In *my* personal opinion anyway. Yes, they all suck.  

But that seems to be the norm in software development, we work with things that we don't really like because the idea of making the utility they provide ourselves is just as miserable if not more so than using the framework or tool in the first place. Anyway back to why all UI Frameworks suck. From hours and hours of scanning through endless lines of Desktop UI Framework source code repositories, I have come to two major conclusions about most if not all of them. 

1: They all do WAY to much and try to handle every single feature, problem, platform, style, you name it. They end up bloated piles of code that seem to have no cohesive structure.

2: Everyone of them seem to have a ridiculous monolithic base Widget class that does EVERYTHING. So when you have a Screen full of Buttons you have all the infrastructure and memory requirements needed if you were to have a Screen full of Windows containing many other Widgets. Wasteful and unnecessary.

 

To be honest, I can see why these traits are common. UI is complex. It needs to be reusable and flexible enough to fit into any application that wants to utilize it. Doing so in a clean concise manner is no easy task. Its very easy to indulge in the temptation of easiest implementation is the best implementation. After all, people need their UI's in a timely fashion. But what if we didn't do that? What if we really sat down and looked at how a UI operates, what it *needs* to do. What type of general structure would work best for those needs. 

 

This is what I decided to do. I decided that if I was going to make this, I was going to do it right. By my standards anyway. 

Next post I intend to go into my thoughts on how UI *should* be. If anyone read this. Thanks, feel free to yell at me in the comments. 



7 Comments


Recommended Comments

"Widget class that does EVERYTHING."

From my own experiences with UI is that the widget class often is just a abstract class or a very limited class. That is to say it does nothing or just keeps track of position and collision, it's function is to group object types into a single group.

 

How would you replace this?

 

 

Edited by Scouting Ninja

Share this comment


Link to comment

@Scouting Ninja

My own experience with other Frameworks is the exact opposite. I don't want to name any specific ones as that seems rather rude given the context. 

I am not saying to replace this type of functionality. It makes perfect sense to have a base element with common data and very basic common logic. But that seems to get out of hand very quickly. 

Share this comment


Link to comment
6 minutes ago, Spool said:

But that seems to get out of hand very quickly. 

It could be as you say that a lot of these UI framework are made in a rush, so planing is skipped on a lot of them. However most of the UI framework I have used tend to be well optimized.

Maybe I just see the problem less because I keep using the same frameworks over and over and haven't tried one of the more up to date ones yet. These days I mostly use engines.

 

So what futures will be the focus of your framework?

Share this comment


Link to comment
1 minute ago, Scouting Ninja said:

So what futures will be the focus of your framework?

This is what I will go into in the next post :)

2 minutes ago, Scouting Ninja said:

It could be as you say that a lot of these UI framework are made in a rush, so planing is skipped on a lot of them. However most of the UI framework I have used tend to be well optimized.

Maybe I just see the problem less because I keep using the same frameworks over and over and haven't tried one of the more up to date ones yet. These days I mostly use engines.

I think that's a big part of it. On one hand most of the time you don't care about how a Framework is structured. As long as it works and works well for you who cares. Totally see that. On the other hand.. what if you need more than that? What if you need less than that? What if that Framework dies? What if it doesn't support the platform you want? I mean granted these are very general concerns. None but one of which where part of the reason that I decided to make my own. But still. They should be considered. 

Share this comment


Link to comment
Quote

The answer I came up with may seem rather shallow and the hallmark of an inexperienced developer..

They all suck.

Two things:

  1. Firstly, as you admit here, one issue is that you as yet have little knowledge of the problem space, because you haven't explored it yet. So this makes it difficult for you to be able to appraise these systems (you may see them more as a user rather than a developer / maintainer). Some might be doing things in what you consider 'odd' ways, which may more sense when you understand the problem they are solving, and the constraints.
  2. Secondly, some probably do suck somewhat. :) As with a lot of software engineering, authors might start down a path, and find that the early design determines the decisions available to them further down the line. Rather than throw out the whole thing, they end up tacking stuff on to 'make it work', and the result isn't so elegant, whereas ideally they would start again and create UI framework 2.0, or at least be prepared to do a lot of refactoring.

The reason why many UIs use inheritance or have some kind of base widget is because UIs are typically a tree structure (if you move a window you want all the child widgets to move with it).

If you want to deal with traversing the tree in multiple ways, arranging elements, etc, then you don't want to write different code to deal with different widgets, 95% of the time. Although inheritance is somewhat less in vogue these days (with DOD and entity component systems becoming more popular), this is a one example where inheritance can be used to make a viable solution (at least to start with, you may use something more esoteric later on).

Overall I personally found it very worthwhile writing at least a basic GUI system. It really isn't rocket science to get the basics working, is great for learning how they work, and you should be able to use yours in a game even if you don't get the time to scale it up to work in a fully blown app. :)

Share this comment


Link to comment

Most UI framework available in the wild are mostly targeted larger audience UI are mostly use in business application. I'm own the same boat to write your own specific UI engine  if you have the luxury of time and for learning experience why not... I want a UI framework specifically for games which is image base that leads me create my own.

https://youtu.be/AQ9w3g8UjOM

 

Edited by DexterZ101

Share this comment


Link to comment
13 hours ago, lawnjelly said:

Two things:

  1. Firstly, as you admit here, one issue is that you as yet have little knowledge of the problem space, because you haven't explored it yet. So this makes it difficult for you to be able to appraise these systems (you may see them more as a user rather than a developer / maintainer). Some might be doing things in what you consider 'odd' ways, which may more sense when you understand the problem they are solving, and the constraints.
  2. Secondly, some probably do suck somewhat. :)As with a lot of software engineering, authors might start down a path, and find that the early design determines the decisions available to them further down the line. Rather than throw out the whole thing, they end up tacking stuff on to 'make it work', and the result isn't so elegant, whereas ideally they would start again and create UI framework 2.0, or at least be prepared to do a lot of refactoring.

The reason why many UIs use inheritance or have some kind of base widget is because UIs are typically a tree structure (if you move a window you want all the child widgets to move with it).

If you want to deal with traversing the tree in multiple ways, arranging elements, etc, then you don't want to write different code to deal with different widgets, 95% of the time. Although inheritance is somewhat less in vogue these days (with DOD and entity component systems becoming more popular), this is a one example where inheritance can be used to make a viable solution (at least to start with, you may use something more esoteric later on).

Overall I personally found it very worthwhile writing at least a basic GUI system. It really isn't rocket science to get the basics working, is great for learning how they work, and you should be able to use yours in a game even if you don't get the time to scale it up to work in a fully blown app. :)

 

1: Yes, generally speaking from a number of years experience viewpoint I am relatively inexperienced. But I have made multiple semi complex UI systems in the traditional way. So I wouldn't necessarily say that I have "little" knowledge of the problem space. But generally speak I am somewhat inexperienced.

2: Of course, I couldn't agree more. But I am advocating learning from those design "mistakes" < personal opinion, and using that to our advantage. Rather than just using the framework at all. 

 

I am not saying inheritance is bad. The functionality that it provides is useful, and given the context is very appropriate. I am saying the use of inheritance is what is bad in most of these frameworks. The tool isn't bad. Its the use of the tool that is bad. Bad isn't really a good word but I think you know what I mean. 

Yes, I agree. Making a basic UI system I think is very educational and personally has taught me a lot. I just happened to get sucked into the semi philosophical understanding of what seemingly is a common trend in these types of software and decided to give it a try and make it into something I thought was better. 

Thanks for the reply, and giving it a read. Cheers! :) 

Share this comment


Link to comment

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
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By JustACicada
      Random Number God has been updated to v1.1.0.
      This is an incremental (although not idle) game about defeating randomized robots by rolling dice and playing cards that alter those dice and their effects.
      Other than performance fixes, the game has been rebalanced from the ground up. Now it should progress in a more fluid fashion. An option to reset the game with a significant boost to your power has been added, allowing you to advance further than you could before.
      There is also now an option to significantly speed up battle animations. Once you learn the rules of the game, a battle can easily take <2 min.
      Windows, Linux: https://justacicada.itch.io/random-number-god
      Android: https://play.google.com/store/apps/details?id=samuelVazquez.randomNumberGod


    • By Seer
      Currently if I was to program a game using C++ with SFML or Java with LibGDX I would render game objects by calling "object.render()" on the game object. Although this makes it easy to access the information necessary to render the game object, it also couples rendering to the game logic which is something I would like to move away from. How can rendering be implemented so that it is decoupled from the game objects?
      I wish to know how this can be done in the standard object oriented paradigm, so please don't suggest that I use an ECS. Thank you.
    • By Jamesgz
      Hey my dudes,
      Me and 4 friends are third year compsci students. Three of us are pretty good at drawing. We are hoping to make a 2d roguelite game with unity during the next few months. We are still brainstorming. At the moment, my idea is to create a card roguelite game:
      First, you would need to choose 2 heroes to enter the dungeon with the goal of finding a treasure. The treasure found gives you extra bonus in later runs. You can choose between mage, gunner, rogue, paladin, warrior and fighter. Each hero has their own unique cards. And there are common cards that every heroes can get(like hearthstone).
      The progression system would be like slay the spire’s. You can choose your own path, but every paths leads to the boss. It would use procedural generation. After defeating an enemy, you get to choose a new card out of the three options. There would be shops, random events, elite enemies, etc
      The combat system is where i need some suggestions on. There would be two piles of deck. One for each hero. I can think of two good combat systems:
      1. Before every enemy encounters, you can choose what cards to use from your deck. Cards not used would not get discarded. Cards are drawn from the deck only if they break or due to special card’s effect. Every card have a durability number. Ones the durability reach zero, the card would break and can no longer be used. Events/enemies can modify the durability of the cards.
      2. Card not used this turn would get discarded. Once the deck is empty, the discard pile gets shuffled and copied to the deck. Card/item effects can increase the number of cards you draw.
      How can I make the game more interesting? Any suggestions would be appreciated.
    • By horror_man
      Hello, I'm currently searching for a talented and passionate programmer to create a small but great horror game that would take around 3 months to be done.
       
      About the game: The game would be a sci-fi/post-apocalyptic survival horror 3D game with FPS (First person shooter) mechanics and an original setting and story based in a book (which I'm writing) scene, where a group of prisoners are left behind in an abandoned underground facility. It would play similar to Dead Space combined with Penumbra and SCP: Secret Laboratory, with the option of playing solo or multiplayer.
       
      Engine that'd be used to create the game: Unity
       
      About me: I'm a music composer with 4 years of experience and I'm fairly new in this game development world, and I'm currently leading the team that'd be creating this beautiful and horrifying game. I decided that making the book which I'm writing into a game would be really cool, and I got more motivated about doing so some time ago when I got a bunch of expensive Unity assets for a very low price. However, I researched about how to do things right in game development so I reduced the scope of it as much as I could so that's why this game is really based in a scene of the book and not the entire thing (and also that's why it would take 3 months). Also I'm currently learning how to use Unity and how to model things with Blender.
       
      Our team right now consists of: Me (Game Designer, Creator, Music Composer, Writer), 3 3D Modelers, 1 Sound Effect Designer, 1 Concept Artist and 1 Programmer.
       
      Who am I looking for:
      - A programmer that's experienced in C# and with Unity.
       
      Right now the game is very early in its development (GDD is completed and all 3D Items, Music and Sound Effects are completed).
       
      If you are interested in joining, contributing or have questions about the project then let's talk. You can message me in Discord: world_creator#9524
    • By Wolfebytes
      I am currently an undergrad several months from graduation. My major is in Game Programming and Development. During the course of my studies, we've had a few modeling classes and I really took to it and feel that is the direction I really want to go, specifically I would love to become a character artist. I keep hearing about your portfolio being super important, but I've really never been able to find out what kind of work is best to put into my portfolio. There's no "put 2 of these and 1 of those in," kind of tips. I get that I'll want to put some characters I've modeled in there, but I guess what I really want to know is, if I want my portfolio to be noticed and taken seriously for a character artist position, what is the best way to present it? Since most of my courses have dealt more with programming, I need to build everything for my modeling portfolio on the side, outside of class on my own time. I know there are no specific numbers like: put 3 realistic humans, 2 robots, a creature, and a stylistic character in your portfolio. But as a general rule is there some kind basic guideline or tips for what to make to get your portfolio off to a good start?
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!