OOP

Sounds like you're overcomplicating matters - when the user clicks on the screen, you perform a calculation to find out where they're clicking, and then you can go through all your boxes to see which one was clicked upon. Observer interfaces and the like seem to give you no benefit here.

(Moved to Game Programming, also. Game Design is primarily for non-programming topics.)

Quote:

Original post by l5n If I have a screen on which the user can click on a graphical representation (the box), I am thinking of using an Observer/listener pattern where my box (or all my boxes and other objects) is/are enlisted. My view would then be the "observable" object.

Normally, it's the other way round: the view observes the objects in view. So that if a box changes at some point in time, the view will be noticed.

I'm a newb game programmer, so here's what I do in a 2d game:

class Entity {
EntityType *entityType; // EntityType object defines properties that are
// the same for all entities of the same "type"
// e.g. all aliens or all bullets or all volcanoes, etc.
int x, y;
int w, h; // HALF the width / height of entity's bounding box, respectively
Actor graphicalRepresentation; // class Actor (a.k.a. Sprite)
};

and that seems to work very well. I don't know how to calculate click detection in 3D, but in 2D, it's best to use more efficient techniques than checking every schtankin' entity to see if it has been clicked on, because doing so is O(n), and conducting collision detection in the same way is O(n*n).

I don't know if that will help answer your Q. or not.

First of all, you should not mix a box' mathematical representation with its graphical representation.

By that I mean, that you shouldn't put a mesh inside the box.
There are lots of cases, where you would need the box' mathematical representation, without its graphics. It is too much luggage for that class to carry around.

Instead I would probably make a function, that can render boxes, or I would make a GraphicsBox.

class GraphicsBox
{
Box box; // mathematical representation
Mesh mesh; // graphical representation

Render();
};


How would you activate the Observer/Listener pattern? And what kind of message is it going to give? And will that make sense to the screen (the observer)?

No matter what you do, you will have to make a mousepoint-to-ray conversion and then a collisioncheck with the ray against your world. When you retrieve what the ray hits, you can just call that object directly - there is no need for an Observer here in any way.



One very important thing when using Patterns, is to not overuse it. When I first read patterns, I was eager to apply them to just about anything.
That is a big mistake. You should only apply patterns when you have a specific need for them. Otherwise you end up with overly complex code, that can be hard to read afterwards.

Patterns are especially hard to understand when they are used in situations, where they don't belong.

If you need practice implementing patterns, try to make a small, seperate project, and invent a problem where they can be used. Instead of applying it to "live" code, before you know exactly how to use them.