Jump to content
XCOMUFO & Xenocide

The Ui Overhaul Idea


SupSuper

Recommended Posts

This is something I've been thinking about for a long time. Xenocide's GUI has been the same ever since the beginning (pre-Ogre?) yet a lot has changed since then. There's been a lot of changes in engine, code, design, features and a lot more that's happened through the lifespan of Xenocide, and the UI is clearly showing the toll of all this. Controls that don't fit their places anymore, quickly-put designs for the sake of functionality, mixed placeholder graphics, wildly different layouts, etc. The GUI has simply become, quite frankly, a very unfriendly part of Xenocide, which is detrimental even when testing.

 

I'll admit we've come a great way with Xenocide lately, lots of development and functionality has been put together very well and very quickly, and I applaud you all for that. I know that functionality is top-priority and everything else takes a second-stage. But the GUI should be just as important as functionality while not getting in its way. Even X-Com had a very attractive and friendly GUI to support the fantastic gameplay.

 

My suggestion is that the GUI be "rewritten from scratch". Obviously without interfering with the functionality coding, this would be done by anyone that isn't busy with something more important, maybe as a side branch.

 

Step 1: Replace CEGUI#

As much as I love CEGUI, CEGUI# strikes me as a poor incomplete undocumented port, which has been very hard to work with. Instead of having to keep fixing and changing it on our own as necessary, maybe it'd be easier to just pick another GUI library to fit our needs, or even write our own if you're that dedicated. Window System for XNA seems like a nice alternative, C#/XNA-based and supporting a lot of widgets and basic skinning ala CEGUI#. Neoforce Controls is also C#/XNA-based and has a very powerful skinning system ala Falagard, but there's very few widgets supported.

 

Step 2: Standardize widgets

Another problem we've always ran into is how our current Xenocide widgets are very hard to implement into GUI libraries. Instead of always try to change the libraries to work with our widgets, maybe it's time the widgets were changed instead. It's not like they were never set in stone in the first place, and our current ones are very restrictive anyways since they were designed with looks, not functionality in mind. We need widgets that are easy to resize and create new screens with. The current ones were designed for specific screens and sizes in mind so they easily look out of place elsehwere.

 

Step 3: Design screens

We also never properly designed any screen. All we have are concepts for Main Menu, Planetview, Baseview and X-Net, which are outdated anyways since a lot of functionality has been changed, and there's plenty more screens and dialogs than that. We should also remember to design screens with both functionality and usability in mind, so making them friendly and easy to use, common elements in designs, making sure the user knows what to do without reading a whole manual. :P

 

Step 4: Spick and span

Once everything else is done, well, time to bolster the UI with whatever we can. Making it more attractive and interesting, making it fun to use, less like an application and more like a game. Again, I refer you to X-Com. :) Adding keyboard shortcuts, animations, tooltips, etc, every little thing contributes to a nice polished UI.

 

This is all purely up for discussion of course. I'm not commanding or dictating anything, just want to know what the rest of the team thinks. This is a cooperative project after all. :)

Link to comment
Share on other sites

As much as I love CEGUI, CEGUI# strikes me as a poor incomplete undocumented port, which has been very hard to work with.
I cannot agree more on this point, CEGUI# as close to CEGUI it is it is based to overcome the problems that C++ game developers had; the problem is that its roots make it obsolete or plain awful to work with in C# because the problems that C# game developers have are plain different to those that C++ developers do. For example, a critical examples is the lack of reflection. Most skinning features are designed for a language that do not support the advance capabilities XNA developers have at its disposal.

 

Surprisingly that very same problem is being introduced into the "Business" world now with C# 3.0 where LINQ will make our "Data Layers" completly useless and with it our general understanding of what an standard 3 layer architecture is. So in short, being afraid of change is what most of the time causes the biggest problems; in that regard david had the same type of "rejection" with XNA branch until recently where I have doubts C++ branch do really exists. But with technology shifts we have to be prepared to change our ways of doing things. What makes more interesting this post. :)

 

Making it more attractive and interesting, making it fun to use, less like an application and more like a game.
I will add up to this :) back in the early 2003 a design like this one was "top notch" up to par with professional development, but with technology changes so does what a UI looks like. So I cannot agree more on this point too.

 

Furthermore, I must add... that what do you propose even if it is the right approach must be done calmly with everybody working toward that and with far more work for the Artwork department. So instead of discuss endlessly we will preach with the example; So if David agrees I would like to call for an experiment (as we once did with XNA) on the Main Window to see how that approach fits and make you (SupSuper) the responsable to do it and blow our minds with what you can achieve in a simplier, nicer and more XNA oriented way ;) ...

 

Greetings

Red Knight

Link to comment
Share on other sites

As much as I love CEGUI, CEGUI# strikes me as a poor incomplete undocumented port, which has been very hard to work with.

I agree it's incomplete (much more than I had hoped) but I think we've made it easier to work with recently by adding the support for layouts so you don't have to be a programmer to design the screens. As for the quality of the port it's not bad. There are definately places where it could be optimized for XNA. That being said, if we can find another library to use I'm all for it. It will be quite a while before I can have the falagard capabilities working so if we can short circuit that all the better.

 

Some requirements I think we need are: (probably pretty obvious)

- Capability similar to the CeGUI .layout files to allow non-programmers work on the UI.

- Skinning

- Either access to the source code or an active team

 

For the time being I'll put the CeGUI# work on hold and spend my time somewhere else. SupSuper, let me know if you want some help looking at other solutions.

Edited by geerzo
Link to comment
Share on other sites

My thoughts, somewhat disorganized I'm afraid.

  • SupSuper is completely correct when he says that many of the screens look ugly.
  • That said, I'm not sure it's fair to say that CeGUI is entirely to blame for that.
  • As a counter example, I think the splash screen and Geoscape look very nice. (Feel free to disagree with me.)
  • I believe the main reason the other screens look ugly is because my primary focus was to build something that worked just well enough to test the engine. You might consider what the geoscape screen looked like before Darkhomb spent several weeks cleaning it up.
  • I suspect that cleaning up the ugly screens may not be that difficult.
    (1:31:41 PM) dteviot: 1. The default background for most of the screens is wrong.
    (1:32:12 PM) dteviot: We need a "standard" background for most of the screens, e.g. Buy/Sell/Transfer/Soldier/BaseInfo, etc. I tried to layout these screens to a "standard format" thinking we could put a common background under them, and have a common layout. However, we may need to lay out the controls on the screens better.
  • That said, CeGUI's, shall we say, unfinished state does present limits on what we can do. It's missing a number of widgets we would like to have. Tree, List Boxes with checkable items, scrolling text and menus would be nice. Consequently, to get the screens to work with the available widgets, some "field improvisations" have been made. (X-Net is the prime example.)
  • From what I've seen, I haven't seen an XNA libraries thats better than CeGUI.
  • I fully agree that we want Xenocide to look good.
  • It is entirely possible that the current screen designs are not ideal, and we may wish to re-organize the screens, and their functionality.
  • I have no strong attachment to CeGUI#. If we can find another widget library that will better meet our needs, then I will be leading the charge to replace CeGUI#.
  • That said, the alternative must be SIGNIFICANTLY better than CeGUI#, to cover the cost of replacing the existing investment in CeGUI.
  • Which means that the first thing we need to do is start nailing down the requirements for the widget library. (Which unfortunately, may be something of an iterative approach, going something like:
    • Have Art mockup a full set of screens, showing off the UI's features. (We probably want storyboards or stories showing how player will interact with the screens.)
    • Given the mockup, we figure out what widgets we need.
    • We then look at the available libraries, and try to see which is the best fit for our needs. As SupSuper suggests, we may decide that redesigning a screen is going to be easier than writing a missing control.

Furthermore, I must add... that what do you propose even if it is the right approach must be done calmly with everybody working toward that and with far more work for the Artwork department. So instead of discuss endlessly we will preach with the example; So if David agrees I would like to call for an experiment (as we once did with XNA) on the Main Window to see how that approach fits and make you (SupSuper) responsible to do it and blow our minds with what you can achieve in a simpler, nicer and more XNA oriented way

 

I agree with doing this experiment.

If we can see a working example, it's much easier to convince others that an idea is valid. (Evidence overrules theory every time.)

However, I'd suggest that a Splash window isn't a sufficient demonstration. I'd very much like to see a working mockup (using the proposed widget library) of 3 or 4 of the most difficult screens. And of course, we need to identify which screens these are. I'm guessing: X-Net, Statistics, and Manufacturing. That said, Soldier Inventory may also be difficult.

Link to comment
Share on other sites

Oh, and speaking of changing the screens, I've found out what the transactions button on the Geoscape was supposed to do

Finally I've taken the build new base button off the main screen as it's not a regularly used thing and it's been replaced by the transactions button which will bring up the buy stuff screen

Which means, as we have a buy button on the Base Screen, the transactions button will be removed

Link to comment
Share on other sites

Just a thought, but perhaps in preparation for this possible change and as a general refactoring of the code we could convert all screens to use a MVC/MVP model?

 

This should allow us to change the UI components with relative ease and will certainly clean the code up (separation of concerns and all that).

 

This could be done regardless of whether we move away from CEGUI# or not.

 

Any thoughts?

Link to comment
Share on other sites

Just a thought, but perhaps in preparation for this possible change and as a general refactoring of the code we could convert all screens to use a MVC/MVP model?

 

This should allow us to change the UI components with relative ease and will certainly clean the code up (separation of concerns and all that).

 

This could be done regardless of whether we move away from CEGUI# or not.

 

Any thoughts?

I'd point out that the screens already follow a Model-View Pattern. If you can show how adding a controller would improve things, I'd love to know. I still don't grasp the MVC pattern.

Link to comment
Share on other sites

I should have pointed out that yes, the Model part is already there.

 

Views in MVC are in charge of the displaying data and propagating events (via the controller), where each view implements a specific interface. This way each controller can be used with different views (i.e. text based geoscape, mobile geoscape views etc...) so long as they implement that interface.

 

The controller is in charge of getting data from the model into the view and propagating events to the model (and the resulting changes back to the view).

 

I am not saying this is the right way forward, but if we are going to overhaul the UI we might as well do this in case we decide to change the UI again or to facilitate having different UIs.

 

The best design patterns book I have read to date is head first into design patterns. It has a java bias but is very readable and also covers MVC.

Link to comment
Share on other sites

Step 1: Replace CEGUI#

As much as I love CEGUI, CEGUI# strikes me as a poor incomplete undocumented port, which has been very hard to work with. Instead of having to keep fixing and changing it on our own as necessary, maybe it'd be easier to just pick another GUI library to fit our needs, or even write our own if you're that dedicated. Window System for XNA seems like a nice alternative, C#/XNA-based and supporting a lot of widgets and basic skinning ala CEGUI#. Neoforce Controls is also C#/XNA-based and has a very powerful skinning system ala Falagard, but there's very few widgets supported.

Another XNA GUI library: xWinForms 1.3

A tutorial on constructing a GUI

Oh, and one of the guys at work suggested this.

edit: another another tutorial on building a GUI

Edited by dteviot
Link to comment
Share on other sites

Oh, and one of the guys at work suggested this.

 

At this point I don't think it's possible to mix XAML and XNA (see here and here). WPF and XAML are supposed to replace WinForms so you have the same issues where the two (XNA and WinForms/WPF) don't mix.

 

I know one of the features of XNA Studio 2.0 is the ability to host an XNA game inside a WinForm but it didn't mention WPF, or what ability you'll have to use WinForms/WPF controls to interact with the XNA application. It looks like you can host a Direct3D canvas in WPF like it describes here so we could go the other way but probably wouldn't want to (Again the interaction between the two would be interesting).

 

Windows Presentation Foundation and Direct3D

 

Direct3D, part of Microsoft's DirectX family of APIs, is a mainstay for Windows developers who create three-dimensional graphics. The advent of WPF in no way obsoletes Direct3D. In fact, as described earlier, WPF relies entirely on Direct3D for rendering. Yet since WPF also allows developers to create 3D graphics, developers working in 3D must decide between the two.

 

The decision isn't especially difficult, however. Direct3D is still the best choice for intensive 3D development, such as games and 3D-centered technical applications, e.g., high-end scientific visualization. At least in its first release, WPF isn't designed to be a platform for these types of software.

 

WPF does make 3D graphics available to a much wider and less specialized audience, however. It also allows using 3D graphics on the Web in an XBAP, integrating them naturally with two-dimensional graphics, documents, and other aspects of an application's user interface, and more. It's also possible for a WPF application to host Direct3D code via the HwndHost class described earlier. Both WPF and Direct3D have distinct roles, and both have a good future as part of the Windows platform.

Link to comment
Share on other sites

I'm pretty sure he was joking when he suggested WPF, but I thought it was sufficiently humourous that I'd repeat it.

 

Oh, and one of the guys at work suggested this.

 

At this point I don't think it's possible to mix XAML and XNA (see here and here). WPF and XAML are supposed to replace WinForms so you have the same issues where the two (XNA and WinForms/WPF) don't mix.

 

I know one of the features of XNA Studio 2.0 is the ability to host an XNA game inside a WinForm but it didn't mention WPF, or what ability you'll have to use WinForms/WPF controls to interact with the XNA application. It looks like you can host a Direct3D canvas in WPF like it describes here so we could go the other way but probably wouldn't want to (Again the interaction between the two would be interesting).

 

Windows Presentation Foundation and Direct3D

 

Direct3D, part of Microsoft's DirectX family of APIs, is a mainstay for Windows developers who create three-dimensional graphics. The advent of WPF in no way obsoletes Direct3D. In fact, as described earlier, WPF relies entirely on Direct3D for rendering. Yet since WPF also allows developers to create 3D graphics, developers working in 3D must decide between the two.

 

The decision isn't especially difficult, however. Direct3D is still the best choice for intensive 3D development, such as games and 3D-centered technical applications, e.g., high-end scientific visualization. At least in its first release, WPF isn't designed to be a platform for these types of software.

 

WPF does make 3D graphics available to a much wider and less specialized audience, however. It also allows using 3D graphics on the Web in an XBAP, integrating them naturally with two-dimensional graphics, documents, and other aspects of an application's user interface, and more. It's also possible for a WPF application to host Direct3D code via the HwndHost class described earlier. Both WPF and Direct3D have distinct roles, and both have a good future as part of the Windows platform.

Link to comment
Share on other sites

I'm pretty sure he was joking when he suggested WPF, but I thought it was sufficiently humourous that I'd repeat it.

:blink: *note to self, figure out how to detect sarcasm in forum posts...*

 

Oh well, you can never be too sure, as I found there are a lot of people seriously trying to get it to work out there.

Link to comment
Share on other sites

I know one of the features of XNA Studio 2.0 is the ability to host an XNA game inside a WinForm but it didn't mention WPF, or what ability you'll have to use WinForms/WPF controls to interact with the XNA application. It looks like you can host a Direct3D canvas in WPF like it describes here so we could go the other way but probably wouldn't want to (Again the interaction between the two would be interesting).
A couple of things, first nothing prevent implementing XAML into a XNA application, but that doesnt means you can use WPF... WPF is just a different kind of technology even though both use DirectX at the bottom of the stack. However, that means that you have to implement an XAML engine in XNA (not a small feat I must say) as nothing prevents XAML to be used outside of WPF.

 

About the XNA ability to host WinForms the last thing I know is that the feature was deferred until further notice to probably an XNA 2.0 Refresh because they had to cut some features to make it to the deadline.

 

Greetings

Red Knight

Link to comment
Share on other sites

A couple of things, first nothing prevent implementing XAML into a XNA application, but that doesnt means you can use WPF... WPF is just a different kind of technology even though both use DirectX at the bottom of the stack. However, that means that you have to implement an XAML engine in XNA (not a small feat I must say) as nothing prevents XAML to be used outside of WPF.

 

David and I actually talked about this earlier today. The advantage of this is that when Microsoft does release a UI kit for XNA, it will probably but based on or at least related to XAML in some fashion which could ease transition. As you said though, the downside is that it would be a tremendous amount of work to implement.

 

Assuming we don't find another library that blows us away and we decide we can't live with CeGUI#, maybe there something we could build that would have a heavy XAML influence at least. I have to admit, having the ability to declaratively script things like UI animations would be slick.

Link to comment
Share on other sites

Well I dont want to spoil the fun :) but if you did noticed the skipped revision numbers it is because we have been working on a prototypes directory with Supsuper and Darkhomb using the latest version of WindowSystem that has been released yesterday (we have been in touch with Aaron his designer) to prototype the use of Content Pipeline as an alternative way to "compile" your GUI. Basically what we are doing is writting an exporter that will take an .gui file (that it is really an XML) that looks like:

 

<Screen>
<TextButton Name="NewGame" X="20" Y="20" Width="100" Height="20"/>
<Image Texture="MainWindowBackground" CanFocus="false" />
</Screen>

And generate a binary representation of that screen so you can do:

Screen screen = content.Load<Screen>(@"Content\UI\MyGameScreen");
this.guiManager.Add(screen);

And provide an standarized way to query the objects inside that "package" like:

TextButton newGame = screen.FindControl<TextButton>("NewGame");

Notice nonetheless that Image do not have a name so cannot be searched and accessed ;) ... that is based on WPF-XAML style where you can leave anonymous markup.

 

The other big part is that if you code a new control the type can be augumented with a namespace that will define a clr-type (that means your custom assembly) so you can extend this easily. And all public properties can be accessed directly from the markup on creation. We are thinking on extensions like allowing triggers but that requires more work that what we need for Xenocide.

 

Greetings

Red Knight

Link to comment
Share on other sites

Well I dont want to spoil the fun :) but if you did noticed the skipped revision numbers it is because we have been working on a prototypes directory with Supsuper and Darkhomb using the latest version of WindowSystem that has been released yesterday

Link to code and screenshots please.

Link to comment
Share on other sites

Better, will post in here everything we mailed with Aaron and the current version of the code :) so you know where we are up to ;)

 

Source: http://svn.projectxenocide.com/xenocide/prototypes

Mails:

 

Hi my name is Federico, I have an open source project that has been recently migrated from C++ to XNA and currently we are researching alternatives to Cegui#; your project looks very promising and we have a bunch of developers that may contribute if it ends up being what we need. However you mentioned that you have made big changes to the source to be used in XNA Refresh (what we are using) so I would like to know either if you have a timeframe already defined for it, or if you are going to upload the changes into Codeplex (even if it is not finished work) for us to try out and who knows maybe to contribute some patches.

 

Thanks in advance,

 

Federico Andres Lois

Project Xenocide Leader

 

Hi Federico,

 

Thanks for the interest.

 

Just so you know, my GUI has always worked with XNA Refresh. The only problem was it used a third-party font system, and didn't work with anti-aliased fonts. I have fixed this by completely changing the way controls are rendered, and have just been testing before uploading the changes to CodePlex. I will start uploading my changes to the source control tonight, with the aim of a release at some point this week.

 

Thanks,

Aaron

 

Excelent we have been doing some examples over the weekend with a couple of developers and really liked the approach you took, in fact we have been writting code to see how defining the gui in Content Pipeline may look. We have a preliminary not functional yet version in our SVN. You can access it in http://svn.projectxenocide.com/xenocide/prototypes . The relevant part is on the WindowsSystem.Pipeline project and two additions in your source (Screen and ScreenReader) the aim is to be able to do something like:

 

Screen screen = content.Load (@"Content\Screens\MainWindow");

this.GuiController.Add ( screen );

 

and being able to handle special stuff for each control like:

 

TextButton newGame = screen.FindControl ("NewGame");

newGame.Clicked += delegate (UIComponent ui)

{

... do something ...

}

 

To do that we define a .gui file that is an XML that looks like

 

....

 

where Screen and TextButton as they have names are accesible through the FindControl interface and Image is anonymous (not accesible through FindControl).

 

Probably today one of our developers will try to finish my initial draft of this concept to handle TextButton and Image components.

 

I am CC Daniel our GUI Developer who is the one that will be most interested in your response :).

 

Greetings,

Federico

 

Hi Guys,

 

I like your idea for the content pipeline, and I'd be interested in seeing how it turns out. I'd like something like that for my GUI, although it would have to be generic enough for a library intended for many different games and applications. I've been playing with the idea of using XML files to define the GUI skins for a while, although haven't been able to find a graceful solution to keeping it extendible without code changes.

 

I've also been meaning to create a MenuScreen class (Screen), which would be more useful for games than windows etc. It wouldn't be difficult to do, it's just been on the back burner while I deal with some more interesting programming problems!

 

If you do have any more information on your plans, then be sure to let me know. I would be happy to implement features that would be useful to other games, and therefore could be added to the library itself.

 

Thanks,

Aaron

 

Well right now Daniel is finding a couple of things that may be needed to be changed for such an approach to work. For instance, Gui objects requires a Game and a GuiManager to work but the only way to handle that seamlessly is to have some sort of dependency injection on Screen attaching to a GuiManager.

 

I come from a more Business Oriented World where we use Silverlight and WPF, their approach is quite generic, I am positive we can implement such thing in a Gui library for XNA there is no real library "shortcoming" that would prevent such an approach. Using reflection you can create whatever thing you want, you just need to provide a typesafe way to query your screen for "their" packed objects. In our prototype it will be FindControl ("MyControl");

 

BTW even if you take an approach based on Content Pipeline it doesnt means that you can't still define your "Screen" in a more standard programatic fashion.

 

About MenuScreen, well probably that would be good for a start (like an extension) what Screen means in our prototype is that you can package whatever control set and provide the GuiManager that to handle whatever it has to do like a virtual form.

 

I am positive that we will soon know if that is a doable approach (we will track the changes that we may need to do to WindowSystem for that to work).

 

Hi Federico,

 

Silverlight looks cool. I looked into WPF briefly, but have never had a chance to make a real application with it.

 

I suspected that reflection is the key to implementing the XML skin descriptions I wanted, but I come from a C++ games background, so am not completely sure of what is possible.

 

So yeah I have uploaded my latest changes to CodePlex, which include the new GUI rendering, and support for SpriteFont. I think I've been looking for an excuse to work on the GUI again! It's easy to get tied up in other things with work etc.

 

I might add some more features later in the week, like multiline textboxes or something.

 

Thanks,

Aaron

 

Very nice work, we'll make good use of this. A multiline textbox would be handy, and I think we're also gonna need a columned listbox later down the line.

 

I have a question about the skinning support of WSX. From what I could figure from the code, there's this base layout that's used to draw all the UI components. However, there also seems to be support for custom skinning individual components. Any chance you could provide more details on this?

 

Will continue...

Link to comment
Share on other sites

Hi Daniel,

 

The way it's implemented now, each class has a set of static defaults, that specify the skin to use among other things. You can generally set the default texture, skin locations on that texture, margins, fonts, colours etc. Now, whenever you create a component, such as a window, it will set it's properties to these defaults.

 

You can change the defaults that will be applied to each subsequent control created of the same type, which means existing controls will maintain their existing properties, but all new controls of that type will reflect the changes. These are changed by setting the static default properties of that class.

 

The other way of changing the style of a control, is to create it as normal with defaults, and then change it's (non default) properties directly. Obviously these changes will only affect that control, with subsequent controls still using the original defaults.

 

You may be wondering why I chose to do skinning in this way. Basically I wanted to be able to change all controls at the start of the program, but still allow individual controls to be modified. More importantly, this method allows the skinning system to work without the GUI library knowing about any specific class, it's all done internally on a class by class basis. I am trying to flesh out some ideas to use XML definitions of skins, probably using reflection to keep the code from knowing about any one UIComponent.

 

Just so you know, it's easy to create custom controls, just remember to use composition rather than writing each control from scratch. For a tile map editor, I threw together a listbox that displays images in rows and columns, rearranging them to the best fit whenever the control is resized. I think that took about an hour. I realise that I know the codebase so I have an advantage, but I can't imagine that your columned listbox would be very difficult to make.

 

Hope that information was useful. I've been meaning to write a skinning tutorial, but I don't think anybody else has really looked at that yet. Let me know if you need any more information.

 

Thanks,

Aaron

 

Aaron,

 

With some stuff that Daniel did and some things I did today we have finally a proof of concept of what we want to do (not using reflection yet, but that in the end is a piece of cake ;) ) so current implementation can handle the Image and TextButton in our basic Hello World in an XML "still hardcoded" way; but the code in the Client is the final version everything has to change in the ScreenReader to make it trully generic and in the ContentWriter to do the save and validation based on the types in the assemblies in an approapriate way.

 

Take a look and tell us what you think of the approach, as for that to integrate seamlessly we may suggest you a couple "cosmetic changes" that should be done to improve the usability of the XML and ContentPipeline approach.

 

Greetings

Federico

 

Hi Federico,

 

I've had a look, and I think it's a good idea.

 

I've just done a little research, and it seems that you can create an object from it's string representation:

 

Type t = Type.GetType("TextBox");

TextBox new_obj = (TextBox) Activator.CreateInstance(t);

 

With this you would not have to hard-code the types. Similarly you can then ask your newly created object for its properties, and then check the XML for each one. This would mean that the parser would always keep up to date with the current GUI classes.

 

I may try to have a go at it tonight. I'm starting to think I could use a similar method for my skinning.

 

Thanks,

Aaron

 

Yes, that is what reflection is all about ;)... You've better do not use the activator, the best way is to handle that diferently using the constructor instance. You may have qualification problems and assemblies loading over the application domain (memory management issues may arrise if we dont do that correctly) and some things are not available on XBox360 like the LoadAssemblyFrom (). If I have time I will try to do the proper implementation today, so when you take a look at it you will have the complete picture of how to do it.

 

Greetings

Federico

 

Ok, I have added for you to see/use a better version roughly coded in less that an hour that can take whatever object and set its properties. If the property cannot be converted it will try to get it by ContentPipeline (as is the case of the Texture2D class) as a last resort. BTW I have added you the ability to change namespaces inside the XML using the namespace as it is done in WPF.

 

For example you may now do the following:

 

 

In that case the first will instance a WindowSystem.TextButton and the second a Xenocide.Controls.TextButton. However what I didnt added yet is a tag to include assemblies for use:

 

Link to comment
Share on other sites

More...

 

Hey Federico,

 

Yeah that's cool, I definitely like that method. I wish it was that easy in C++! :-p

 

One thing I've realised, is that basically you are just adding the loaded components to a UIComponent of the type Screen. I don't think there's any reason it couldn't work for any UIComponent. If you could nest them, then you could use XML definition files for complete sets of dialogs etc.

 

I'm going to go ahead and try something similar for my skins.

 

Thanks,

Aaron

 

Yes, that is the expresive power of the platform :) that is why I left programming in C++ a long time ago... I prefer expressive power than "metal" power; after all machines are faster every day GPU are taking over on the hard calculation, so in the end it is a win-win... more expresive power on the controller, more calculus on specialized chips.

 

About the screen, yes sure I just wanted to not touch much but you can definitely do that and include every kind of component, so feel free to take as much as you want from our prototype... as in the end, both of us will benefit. The only suggestion I have is to convert the GuiManager into a Service instead that has its own ContentManager instance as we had to hack it to get all the instances that we needed to perform the loading. The other is to provide a way for the GuiManager to be able to switch over/activate "screens" in an easy way (something that is pretty useful in games) so you dont have to reload everything.

 

I do like C#, which is more about dealing with problems than struggling with solutions. My job involves very low level stuff, where you need to actually know exactly what the Cell processor is doing under the hood. I think it's cool to see both sides of programming.

 

Ok, I know exactly what you are saying about the service thing with my GUI, and I was going to do that myself a while ago. The reason I haven't done so is because XNA 2.0 will handle that for me. In the new version you will be able to manage your own lists of GameComponent objects, which means you will be able to automatically stop all components existing in one state, when a new state transitions in. The cool thing about this over implementing a service, is that you could have multiple GUIManager objects existing in different states. So you could have a main menu GUI that isn't updated when the game is running, and a separate pause menu. This would prevent the need to shutdown a set of GUI components each time you transition, to set up another set.

 

Thanks,

Aaron

 

Greetings

Red Knight

Link to comment
Share on other sites

  • 3 weeks later...

I apologize for letting this seemingly die and I bet all the e-mail quotes didn't explain anything, but I've been busy with college so I'll just sum up what's in:

  • WSX is in (as a bonus we work together with the developer)
  • XML layouts are in
  • Sound support is in
  • Skinnable controls are in
  • New controls (InputBox and Spinner) are in

And what's under work:

  • Converting old screens to XML layouts
  • Converting old imagesets to control skins
  • XML skinning
  • Screen switching
  • Multiline TextBox
  • More advanced ListBox (for X-Net, Buy/Sell, etc.)

What WSX supports:

  • Very fast and easy to work with XNA-integrated UI (as well as easily adding new functionality and controls)
  • Easily skinnable controls, including skinning individual controls
  • Controls: Bar, CheckBox, ComboBox, DisplaySettingsDialog, Image, ImageButton, Label, ListBox, MenuBar, MenuItem, MessageBox, MovableArea, PopUpMenu, RadioGroup, RadioButton, ResizableArea, TextBox, TextButton, Window
  • Cooperating with the developer so we can work together on features that'll help Xenocide

I also haven't had time to actually sit down and draw out any new layouts, so I'll just sum up what's been on my mind regarding the redesign.

  • Sidebar: In or out? We introduced the sidebar in the Planetview following X-Com's style and ended up transferring it over to every other screen. Is that actually a good idea or not? Should we either:
    • Use it as a common element for every screen so that buttons and misc. text goes in the sidebar while the rest of the space is left open for all the screen data and what not? In which case, the sidebar should be generalized so it'll work for every screen (get rid of the screen-specific controls on bottom, etc.)
    • Only use it in Planetview/Baseview and have extra space on the other screens?

    I quickly threw this up as an example of a screen with or without sidebar, if it helps:

    xeno_research.png

    [*]Windows: This is a game, not an application, and we should avoid the over-use of complicated controls and windows to keep it as such. Windows are useful when you don't want them to get in the way of the rest of the screen and still need to see what's behind. But if that's not necessary it's better off having a dedicated screen so we can make full use of the space and not have to strain the game with rendering screen and windows at once.

    [*]Controls: The first control designs were done on a purely as-needed basis for specific screens. This basically means some of our controls don't fit on various screens, others are so elaborate that they're a pain to implement, and others just weren't drawn up so we used defaults. While I'm all for UI controls looking nice and shiny, we shouldn't abuse it. UI should remain easy to implement, easy to use, easy to look at. Plus controls that at least look similar to standard controls like Windows' make it easier for users. We should design a new set that meets these standards and looks good all-around. Getting more specific:

    • Button: The current button was designed for the sidebar. It's right-aligned, ugly to resize and a bit bloaty: the "extra bit" on the left-side adds space that can't be used for text, which gets a bit noticable given how wide our font is.
    • Window: It has a pointless scrollbar and unecessarily long Close button.
    • Checkbox: Right-aligned and pointless background.
    • Scrollbar: We've had many issues before with its odd size and how it won't look right unless the screen is *specifically* designed for it.
    • Others: We also need controls drawn up for ListBox, TextBox, ComboBox, Bar (slider), Spinner, MessageBox (for the message types) and maybe any custom stuff like the Planetview controls and special X-Net listbox. (the old C++ one looked really nice)

Ok I think that's enough for now. Feel free to post your thoughts and contribute. :)

Link to comment
Share on other sites

in theory at least with the later portions of the Xnet and Geoscape I created them to be scalable and fairly easy to update should new functionality be needed by revising the button names or numbers. I also believe we moved toward a more flat feel than the previous beveled edges on those screens. perhaps this can be extended to remove the greenscreen lines and have a more holographic feel to the interface. Edited by Vaaish
Link to comment
Share on other sites

Sidebar: In or out? We introduced the sidebar in the Planetview following X-Com's style and ended up transferring it over to every other screen. Is that actually a good idea or not?

I've asked the very same question myself.

My thought is, we want a consistent "look and feel" for all the screens. So, if we can arrange the screens so that a sidebar is useful in all of them, that would be my preference.

 

Windows: This is a game, not an application, and we should avoid the over-use of complicated controls and windows to keep it as such. Windows are useful when you don't want them to get in the way of the rest of the screen and still need to see what's behind. But if that's not necessary it's better off having a dedicated screen so we can make full use of the space and not have to strain the game with rendering screen and windows at once.

Agree 100%. This is exactly the route I took with the existing UI, as much as possible the work is all done on one screen, with no dialogs. (Except in a couple of cases, like the equip soldier screen, where a dialog was a lot less work than implementing the functionality on the screen.)

 

Others: We also need controls drawn up for ListBox, TextBox, ComboBox, Bar (slider), Spinner, MessageBox (for the message types) and maybe any custom stuff like the Planetview controls and special X-Net listbox. (the old C++ one looked really nice)

IIRC, the X-Net list box took about 4 weeks of tweaking to get it looking like it did.

Extrapolate that over all the screens, and you're looking at years of work.

Link to comment
Share on other sites

Sidebar: In or out? We introduced the sidebar in the Planetview following X-Com's style and ended up transferring it over to every other screen. Is that actually a good idea or not?

In my opinion part of what makes a great game great is how fit to purpose the UI is - I would rather have a different design for each screen, depending on how it is to be used (while keeping a consistent look and feel). The geoscape and base views are two screens where the sidebar makes lots of sense but other screens less so, and having the extra space can help create a better playing experience. I feel that the assign to craft screen for example has a clunky interface simply because I kept the sidebar and found CeGui# to be lacking in functionality (and difficult to work with).

 

Windows: This is a game, not an application, and we should avoid the over-use of complicated controls and windows to keep it as such. Windows are useful when you don't want them to get in the way of the rest of the screen and still need to see what's behind. But if that's not necessary it's better off having a dedicated screen so we can make full use of the space and not have to strain the game with rendering screen and windows at once.

Same points as above...

Link to comment
Share on other sites

in theory at least with the later portions of the Xnet and Geoscape I created them to be scalable and fairly easy to update should new functionality be needed by revising the button names or numbers. I also believe we moved toward a more flat feel than the previous beveled edges on those screens. perhaps this can be extended to remove the greenscreen lines and have a more holographic feel to the interface.
Well my goal is to provide a common set of controls that can be easily tweaked and used to create new screens that still look good, even by non-artists.

 

Artistic matters are still down to artists though, if you think the current look should be revised, feel free to. :) I do agree that there seems to be a clash between how the buttons look compared to the backgrounds behind them.

I've also been wondering if the globe controls and grerenscape text are still worth keeping, given feature changes.

 

Sidebar: In or out? We introduced the sidebar in the Planetview following X-Com's style and ended up transferring it over to every other screen. Is that actually a good idea or not?

I've asked the very same question myself.

My thought is, we want a consistent "look and feel" for all the screens. So, if we can arrange the screens so that a sidebar is useful in all of them, that would be my preference.

 

Windows: This is a game, not an application, and we should avoid the over-use of complicated controls and windows to keep it as such. Windows are useful when you don't want them to get in the way of the rest of the screen and still need to see what's behind. But if that's not necessary it's better off having a dedicated screen so we can make full use of the space and not have to strain the game with rendering screen and windows at once.

Agree 100%. This is exactly the route I took with the existing UI, as much as possible the work is all done on one screen, with no dialogs. (Except in a couple of cases, like the equip soldier screen, where a dialog was a lot less work than implementing the functionality on the screen.)

 

Others: We also need controls drawn up for ListBox, TextBox, ComboBox, Bar (slider), Spinner, MessageBox (for the message types) and maybe any custom stuff like the Planetview controls and special X-Net listbox. (the old C++ one looked really nice)

IIRC, the X-Net list box took about 4 weeks of tweaking to get it looking like it did.

Extrapolate that over all the screens, and you're looking at years of work.

I said maybe, I obviously don't mean things like that should be top-priority, but we do wanna improve over the current listbox eventually. :)

And the C++ X-Net took so long because of coding work, not art work. Since now we can change the controls for us, we might have it easier next time.

 

I'm also pro-sidebar merely because it provides a good common element, but it'll probably need tweaking so we can take full advantage of it.

 

Sidebar: In or out? We introduced the sidebar in the Planetview following X-Com's style and ended up transferring it over to every other screen. Is that actually a good idea or not?

In my opinion part of what makes a great game great is how fit to purpose the UI is - I would rather have a different design for each screen, depending on how it is to be used (while keeping a consistent look and feel). The geoscape and base views are two screens where the sidebar makes lots of sense but other screens less so, and having the extra space can help create a better playing experience. I feel that the assign to craft screen for example has a clunky interface simply because I kept the sidebar and found CeGui# to be lacking in functionality (and difficult to work with).

 

Windows: This is a game, not an application, and we should avoid the over-use of complicated controls and windows to keep it as such. Windows are useful when you don't want them to get in the way of the rest of the screen and still need to see what's behind. But if that's not necessary it's better off having a dedicated screen so we can make full use of the space and not have to strain the game with rendering screen and windows at once.

Same points as above...

I suppose it depends on how we use the screens and any new features we add/change on them. X-Com did fine with just 320*200. :P

 

I'll see if I can revise the current screens and throw up some new design concepts so we can brainstorm over the best way the screens would work.

Link to comment
Share on other sites

To be perfectly honest, the plantview controls aren't needed but they do conveniently fill otherwise blank space. I'm also of the opinion that eh sidebar is a good device for easy to get to unotrusive menu choices for baseview, plasnetview, and the battle view. The only place it doesn't quite fit is with xnet which should probably end up being a windowed popup... then again even baseview could be that too if we worked on it.
Link to comment
Share on other sites

  • 3 weeks later...

xWinForms seems to be a good GUI library

SimpleGUI is also simple...

 

In addition, if you see go around the various post in http://www.nuclex.org/ blog, you'll see this one:

 

http://www.nuclex.org/news/2007/08/23/nuclex-gui-anyone

 

That's the most interesting link :O, 5 GUIs and that guy tells his opinion on them

 

[noob_question] Why didn't you use the default ones really? [/noob_question]

 

 

 

In addition, another beautiful addition:

http://www.nuclex.org/news/2007/11/07/xna-...nstaller-part-2

 

Why not inform the users about the components already installed and let the installer fix the missing parts? :O

Link to comment
Share on other sites

×
×
  • Create New...