Skip to main content
gamedev.net
🔒 Locked

GUI object selection

Started by Telastyn Jan 19, 2005 at 2:11 AM 0 replies 400+ views
Original Post
Telastyn
Telastyn
Hello everyone. I have a little bit of a problem, which I'm curious as to others opinions on how to solve it [and perhaps more insight as to how it's commonly solved] The basic problem is how to code object selection into my current project. By object selection, I mean the sort of scenario where the user initiates... "cast spell" or something and needs to select a target for it. My gui is setup as an n-tree [?proper term? each node has 1 parent and 0->inf() children] of objects which all inherit a common base class. Rendering recurses through the tree. User I/O [buttons, text input] used to be done via seperate stacks, but keeping them synched with the tree turned to be too unweildy. That too is now held within the rendertree. I've thought of 4 different solutions, none of which good. 1- Have 'select' modes in a stack like the user I/O used to be. This will have similar problems with keeping synched up to the tree, and seems... unclean. 2- Add a 'select' stack to each base object. This will work nicely, but it seems terribly inefficient to add it to the base object when only a half dozen or so [out of hundreds or thousands] of the actual instances will actually contain data. 3- Individually create mouse targets for each and every possible selection target when a 'select' is needed. This seems like a total pain, though since most selections will be done via lists or maps which are already generated, perhaps generating another layer for selection won't be so bad... 4- Create a 'select' renderable object, which could then be placed into the rendertree between the parent needing the selection and it's children. This seems like it would lead to cornering myself later. Render objects should know [and will likely need to know on occasion] about their immediate parent and children. Having the 'selector' between them would lead to some hackish work-arounds. Also would require the selector to override the base destructor to not delete it's children... Anyways, I am curious to what advice those wiser than I would give regarding the implimentation of this sort of feature.
Telastyn
Telastyn
Hrm. Well, thinking a little more about it [and receiving no advice] I think I'm going to try to do some sort of layering [#3 above].

Since most of the selection areas have their objects generated from game data as layers, adding another layering function when the modes change shouldn't be too much trouble hopefully.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.