Selection mechanism

Started by
0 comments, last by Telastyn 19 years, 8 months ago
I am curious as to how others have solved a fairly common problem: In a 2D GUI system, how do you program the ability to 'select' things? Common gameplay examples are "select a target for the spell.", "change active units", "move to here".
Advertisement
Appologies for bumping my own post.

The solution I implimented which works, though it seems a little awkward. Hopefully this will serve as notice to others to perhaps look for another method:

In my design, mouseclicks are handled by checking the coordinates clicked against an arbitrary sized array [a stack actually] of "targets". The targets are essentially a rectangle defining the target area, a series [left click, right click, and so on] of function pointers [and parameters] to execute when the target is hit, and a pointer to the owner of that target.

On a mouse event, I loop through the stack, calling the first "hit". Thus "lower" objects are obscured by higher ones. This works well, as objects generally do not change z-level.

Selection though was cumbersome with this design. Each individual render object would've had to create a mouse target for themselves, and bind it to a function pointer which generally targetted the render object's parent. The idea of having render objects know where they lie in the tree [or scene graph if you prefer] is largely against the benefits of having independant little render objects.

So, what I implimented was a secondary stack for selection actions, and an added 'object' field to the original mouse targets. The owner of a mouse target is not always what the mouse target represents in the game world. A simple image render object might represent a swordsman, or a tree, or a button. The object field represents what game object the render object represents.

On a left click event, the standard left click action is taken; but also the top selection action is passed a variable length array containing all "matching" targets in the mouse target stack [in order]. This allows functions to look through the resultant stack for "what they want". For example, the game could be in a selection state where it wants the user to pick a swordsman. If the swordsman icon is obscured by a spell effect, the selection function can simply look past the spell effect until it gets to a swordsman. Or if it sees a stack of units, to open another window asking for which member of the stack is desired.

This way, the children render objects can simply say what they represent, and let their parent worry about what context they're in.

This topic is closed to new replies.

Advertisement