Jump to content
  • Advertisement
Sign in to follow this  
mind_wipe

Data Driven Ui Design

This topic is 2805 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

You know how developers are talking about using data driven design? The idea(supposedly) is to use components that represent various aspects(i.e. physics, logic) for game entities. Most examples I've seen thus far use game entities. But what I want to do is use this same technique to write a user interface. My idea is to reuse this in other games/programs as well. I'm hoping this technique will also allow me to add new components(widgets, controls) to the UI, and/or extending any functionality with easy. So now that you know what I'm trying to do, here is my problem.

How do you *component* something and how would you add this component? My approach is this: Define a base(semi-abstract) class that defines what a component is. I create new, or extend old, components deriving form this class. Then I should define a couple of methods in the Widget class that add a component.

That's easy enough right? Here's the catch 22 I'm having problems with. Each class(Widget) that I create/define would also have to contain pointers to those special components that it would use. For example, a Scroll-Bar or Combo-Box would add child components for buttons and such + rendering styles. Doesn't this defeat the purpose of this technique? Limiting a Scroll-Bar or Combo-Box because they know what components they need? But then again, if they didn't how would that function?

Am I making my self clear? This is what I'm having problems grasping. Not the whole programming bit, but more the concept and design... so maybe a little programming bit, but mostly concept. I though this design pattern was to allow classes to be defined by components, not the other way around. Another problem I've seen is that if I want to extend that functionality of a specific widget, I have to add a new member variable pertaining to that component that I wish to use. See, I'm confused! I though the classes(widgets) were suppose to be ignorant of all this.

Share this post


Link to post
Share on other sites
Advertisement
It sounds like in many respects you already have a data driven system.

Are you hard-coding your screen layouts in source code? Or do you have a resource editor that lets you position the buttons, boxes, images, and text?

If you are using a resource editor, and save the layout data out, and your program reads that data in and re-crates the screen however you want, then it sounds "data driven" to me.


The point is to allow non-programmers the chance to easily manipulate the data without impacting the engine. If your artists can adjust the layout without modifying your cpp files, then you have accomplished it.

Share this post


Link to post
Share on other sites
Make sure you know what "Soft-Coding" is and about the inner platform effect. As long as you're not doing that then it's all good.

Share this post


Link to post
Share on other sites
Data driven != component model.


These are orthogonal concepts and, in general, solve totally different types of problem. A data-driven UI simply loads its controls, layout, etc. from some data source rather than creating them all in code directly; Windows has done this with "dialogs" for many, many years. Newer approaches like Silverlight's XAML, Android's XML-based UI system, Flash, etc. etc. have appeared, but they all operate on the same principle: you have a set of well-defined widget classes, and you instantiate them across your UI with layout and animation metadata, and you're done.

Component-driven UI sounds like a totally bad idea to me. You gain nothing and lose all the advantages of concrete widget classes. No longer can I talk about my UI in terms of a text box widget with a scrollbar decorator; I have to think one step up in abstraction and see if the Widget1 component has the TextBox entity and if it has a cross-connection to Widget2 which has a ScrollBar entity. Blech!


XML-driven UIs are pretty damned effective, and seem to be the de facto standard for things like mobile/web-based apps these days. I'd suggest looking to emulate them if you want a truly flexible UI system... not necessarily to the extent of using XML as your data format, but in principle.

Share this post


Link to post
Share on other sites
Well thanks for all the replies because you helped out a lot. I guess I was confusing my self because I was mixing the definitions of two different patterns here. Component model vs. Data Driven. I'm thinking this is because I seen examples of this an automatically(sub-subconscious or whatever) analogous or the same entirely. Thank god I got that cleared up, thanks guys.

After posting this topic and researching + sleep, then reading these replies I've came to a new conclusion or design. I did, also, find it very cumbersome and annoying to NOT have widgets defined by type, in essence: ComboBox, Button etc.. I know for a fact that most UIs are actually created using these types of components,. I mean come one, dug? right? So my previous idea would of had me describing each UI widget with all the those features of those, more common widgets, over and over again. Not a good idea. But, Widget is still the base class for all widgets, but now I actually will define a what a ComboBox or Button it. The only thing I really need "script-able" or data driven are themes and layouts. Hence the new Themer class. Which is nothing more then a collection of textures, sounds and a few specialized drawing routines such as <i>DrawPart()</i> or <i>DrawText</i> for the most part. A theme will be defined via XML. So that means I have to write(yet another one) an XML parser again. Each layout or menu will also be defined with XML. I don't know, last time I tried to write an XML parser I went gung-ho! and also tried implementing DTD. I don't think I need this here because its highly unlikely my XML scripts will be web-validated... that is a cool idea though, or need that type of functionality at all. At the very least, simple syntax/semantics error checking (e.g. Button="Don't do this!" is illegal, bad grammar.

Sorry for all the jibber jabber. I think I'm going to have to look for a few of those XML/UI examples. Thanks again!

Share this post


Link to post
Share on other sites
Any particular reason why you aren't using an off-the-shelf XML parser? There's quite a few out there, most of which are pretty good and have decent license terms.

Share this post


Link to post
Share on other sites
Yes there is a reason. I choose to write my own software because of the knowledge and experience I would gain by writing it; In my personal opinion. I believe I wouldn't truly understand or appreciate a specific part of software(in whole) unless I try to reproduce it myself. There are so many things a person can learn when trying to create something. Somethings that have may lead to other areas of interest. Also, I would rather not work with another's license. Nothing against people and the great work they may produce. I'm just like them. I must learn to figure things out my self(mostly), thus I never be able to create anything. Besides, a recursive decent parser is pretty easy to write and they work well for things like XML. Fair enough? In short, I'd rather develop software my self, suited for my own particular needs... maybe that's what I should have said instead of that large paragraph above.

Share this post


Link to post
Share on other sites
But you said you've already done XML parsers... so what do you feel is left to gain by retreading old ground?

I just think it makes a lot more sense to use a freely-licensed parser once you know how they work, instead of constantly rebuilding wheels just for the sake of it. After a while you're going to hit diminishing returns, to the point where doing it yourself stops teaching you anything useful and just makes it annoying.

Worst case, why not write a library and reuse it yourself? No need to deal with licenses (as if that were much of an excuse - have you read the licenses for most XML libs? They're incredibly permissive...) and no need to do the same work a dozen times.

Share this post


Link to post
Share on other sites
So you assume I just through away the code I write? Well... I guess I didn't clarify and kinda made it sound that way. I have peaces and part of the parser's I've built lying around on a jump drive some where. You say that I'll eventually hit a diminishing returns. I don't entirely believe that but to some extent I do. True, things get boring after a while. But, think of it this way: When ever you write a peace of software you know you might come across something that you've already wrote before. But you may also see the need for that peace of software in a different light. I'm not excusing writing the same thing over and over again. Because, like you, I also believe it is better to reuse. That is what I try to do. I think I might have lead you to a false assumption of me because of what I said earlier. I was talking in terms of that task at hand that needed done, not to be taken literally. Like a grain of salt. I don't have a plethora of code, but I do backup a lot of what I write. I HATE system code at times. I couldn't stand writing X11 & GLX initialization stuff over and over again. That is why I wrote it once, then bring it back out of the closet when I need it. Eventually, I'll rewrite it. What I mean is that I might make changes. Not a complete rewrite. Then if i really like what I have, I'll replace the old with the new. I do this unless there is something particular about the old I want intact. Then I just append a simple numbering scheme at the end of their names. For example, filename(1), filename(2). What can I say... I'm a little weird.

Share this post


Link to post
Share on other sites
Depends on your objective.

I've been an senior member of a team developing engines for commercial games (mainly in tools/sound as opposed to graphics etc) and when I came to writing my own games the first instinct I had to override was "write everything yourself syndrome".

The reason for this is just the time it takes one individual to write subsystems themselves. When I worked on the engine team I was a lead amongst 5 tools/pipeline programmers and we were the subteam of the engine team comprising of about 40 developers. It was unrealistic for me to expect to write systems with the same quality. From a developer perspective its fun writing your own subsystems to learn how they work but its also unrealistic if your goal is to get games published in an manageable time limit.

If your goal is to learn how something works then I'm all for writing your own stuff and delving into the deep, if it comes to decent project management techniques then I just have to use off the shelf components (carefully selected) to get the project with any sort of manageable timeframe.

Ironically the thing I love about making more indie games is you get to see the entire project lifecycle, as opposed to just seeing bits and pieces of it. Some of the games I've got credits for are very well known but I would of actually played them for less than 15 minutes each due to the fact I just needed to test that the tech worked in the game.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

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!