Moe plans.

Published March 14, 2007
Advertisement
I have the evening free tonight, and after a little poking at XNA over the weekend I kinda got the itch again to work on Moe.

Alas, yet another re-write. I imagine, like all others, less and less will actually be edited. Anyways, I am going to focus on the UI foundation first off. TBSes are UI heavy games, and in retrospect I realized how much time I spent interrupting game coding with UI building.

So, first off the unrealistic goal is to make a easy to use, fairly complete, fairly reusable UI setup. Right now I've got an easy to use in spots, mostly incomplete, fairly reusable UI so it's perhaps not as unrealistic as the random newb's goal. Still, I should know better.

Anyways, on the docket:

- Modify colors to act more like resources

Currently it's a pain to set colors of child controls to be that of parent controls (and keep them in synch).

[edit1: Sort of done. Generic manager and color class defined, pre-existing infrastructure changed to use new color class. Now to make a concrete manager to test against.]

- Modify fonts to act more like rectangles

Once again, it's a pain to update controls if/when the font changes.

- Make resolution changes handled more elegantly.

Essentially moving from explicit to relative coordinates.

[edit1: Mostly done. I once again need concrete managers to test]

- Add support for drag/drop, mouseover, stop hover, double click, and make mouse clicks more natural.

Most of these aren't supported, and perhaps not a big deal. The main problem is that scroll bars are weird when you can't drag the bar. Also, there's currently a large lack of interactivity in the UI, making buttons non-obvious and certain things like hover popup elimination very tedious.

- Add more modularity to the resource setup.

This should allow for skinning, and easier alternative resource sets for whatever reason (colorblindness, internationalization, hard of seeing).

- Create default resource aliases.

Which will centralize the UI defaults making them easier to see/change/replace/re-alias.

- Add more controls.

The biggie. Key on the list are layout objects, scrollbars that don't suck, buttons that interact better, hover popups, pre-made tabpages, perhaps a progress bar, and overall minor improvements to pre-existing controls. [edit: and many more I can't think of now

- Change TiedRect to allow arbitrary ties

The most common dynamic rectangle used should allow multiple ties to others stretching if necessary rather than placing awkward sizing functors for it.

[edit2: code added. Untested, existing source not yet changed to use the less demanding interface]

- Add info about aspect ratio somewhere

Because with relative coords, that will matter more than the resolution.

[edit1: done. Added enum, properties, event]

- Add a dirty flag to renderables.

To allow for more intelligent caching since the UI likely won't be very dynamic.
...and more as I think of it.]

[edit1: 2 hours work, much done.]
[edit2: 2 more hours, a bit done.]
Previous Entry Well, duh.
Next Entry Damned books.
0 likes 1 comments

Comments

Telastyn
Quote:Original post by Telastyn
- Modify colors to act more like resources

Currently it's a pain to set colors of child controls to be that of parent controls (and keep them in synch).

[edit1: Sort of done. Generic manager and color class defined, pre-existing infrastructure changed to use new color class. Now to make a concrete manager to test against.]


[3/25/07] - Sort of done. Concrete manager done with a little testing. Dependent on the 'skinning' changes to the resource managers to test effectively and provide much benefit.

Quote:
- Modify fonts to act more like rectangles

Once again, it's a pain to update controls if/when the font changes.


[3/25/07] - Sort of done. The load strings are now kept with the text objects making this feasible-ish. I need to decide how often this should occur and what the proper behavior should be for aliased fonts.

Quote:
- Make resolution changes handled more elegantly.

Essentially moving from explicit to relative coordinates.

[edit1: Mostly done. I once again need concrete managers to test]


[3/25/07] - Done, I think. It works as designed, though after seeing it in action a little it maybe doesn't do what I want. Maybe just a problem with my test object sizing/design.

Quote:
- Add support for drag/drop, mouseover, stop hover, double click, and make mouse clicks more natural.

Most of these aren't supported, and perhaps not a big deal. The main problem is that scroll bars are weird when you can't drag the bar. Also, there's currently a large lack of interactivity in the UI, making buttons non-obvious and certain things like hover popup elimination very tedious.

- Add more modularity to the resource setup.

This should allow for skinning, and easier alternative resource sets for whatever reason (colorblindness, internationalization, hard of seeing).

- Create default resource aliases.

Which will centralize the UI defaults making them easier to see/change/replace/re-alias.

- Add more controls.

The biggie. Key on the list are layout objects, scrollbars that don't suck, buttons that interact better, hover popups, pre-made tabpages, perhaps a progress bar, and overall minor improvements to pre-existing controls. [edit: and many more I can't think of now

- Change TiedRect to allow arbitrary ties

The most common dynamic rectangle used should allow multiple ties to others stretching if necessary rather than placing awkward sizing functors for it.

[edit2: code added. Untested, existing source not yet changed to use the less demanding interface]


[3/25/07] - Done. Existing source changed with a few problems with some fragile code which is going to be tossed anyways. The Ties are much more reliable now. Flexibility is also improved since I can do most of the sizings via ties rather than a sizing functor and events.

Quote:
- Add info about aspect ratio somewhere

Because with relative coords, that will matter more than the resolution.

[edit1: done. Added enum, properties, event]

- Add a dirty flag to renderables.

To allow for more intelligent caching since the UI likely won't be very dynamic.
...and more as I think of it.]

[edit1: 2 hours work, much done.]
[edit2: 2 more hours, a bit done.]


Next in the queue I think is going to be that sort of skinning/modularity change or a table layout object. Nothing likely soon since I've far less time for hobby these days, but that's fine just so long as I keep the progress flowing.
March 25, 2007 09:57 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement