Mouse Input in Board Game.

[Rechard3]

Hi all.

i'm about to create my first graphical game ever, didn't start yet, and some questions started to cross my
mind about the general structure of my code, here's the most important:

the game type is a turn-based board-game (this must be the simplest), it has no input methods but the mouse.
i'll use DirectX::Direct2D to draw graphics (do you suggest i stick with GDI?).
anyway, every board-game must monitor mouse events to know what to do and when, right?
until now, two algorithms crossed my mind to deal with mouse input:

1:

- draw objects directly to the main window.
- catch mouse events occurring on that main window via MainWndProc().
- get the mouse coordinates.
- transform into client coordinates.
- check what object is the mouse event happening on.
- then call the proper function.

2:

- encapsulate with each object an HWND that will refer to a new child window.
- create a new child window for each object, the window conatins only a client
area.
- let ChildWndProc() recognize the object that contains the window handle.
- ChildWndProc() calls the proper member function for that object
(  ptrObject->HandleMouseClick()  ,  ptrObject->HighlightImage()  , ...   ).

in this method, the OS handles monitoring mouse events and sends the
message to the right child window, then the ChildWndProc() connects the
child window with the proper object.

i expect most answers will go for the second way, as it simplifies the process with smaller chance of bugs.


the reason i'm asking:
i want to know if there is an even better structure to do this.

[andywestken]

If it was something like a chess board, I would prob. use the first approach. But the objects would be called to do their own drawing, etc. That could including hit testing (i.e. you ask each object if the position is in their area), though with a rectangular grid (or similar) it might be better to just calculate it from the known layout.

Note that the coordinates that turn up with WM_LBUTTONDOWN, etc are already in client coordinates.

Andy

PS If you don't already know Direct2D, you could maybe "sketch" it out with basic GDI. Then move it to use Direct2D once you have some kind of running app. Depends on what you know already, and quick you pick things up.

[Rechard3]

the board is somehow more complex than just a grid, i'm actually making my own digital copy of the game "Risk", if you don't know it, the board is the world map.

i wasn't really an "expert" in GDI, all i had was simple knowledge about basic operations in it.
when i realized there's a modern graphics library that Microsoft recommends to replace GDI, i thought to myself:
why learn the old method?
i'm still fresh so let's start on the right path.

Note that the coordinates that turn up with WM_LBUTTONDOWN, etc are already in client coordinates.

Oh... i'm starting to mix things up....


well... even if the second approach works in this specific case, i think it would still fail when i push it up a little.
consider i want to create a simple 2D strategy game (like "age of empires").
in this case, i can't create windows for objects that are out of the screen borders.
it really looks intimidating monitoring the mouse and telling which object is it hovering on.

i'll keep searching MSDN while waiting for any other suggestions, maybe DirectInput can do the trick.

(i.e. you ask each object if the position is in their area)

i actually had that in mind, but i'm concerned about performance, this approach could contain lots of overhead (asking each individual object to perform hit-testing.)
you know what, this gave me an idea:
maybe not test ALL objects to test the mouse position, maybe i can create a list, contains pointers to the base class of everything.
each time an object is inside the screen borders it adds a pointer to itself to that list, and when hit-testing, i can ask just the elements in that list to hit-test, not all objects.

maybe another approach:
get rid of that list, i can tell the object to create its layered window only when it enters the screen borders, and when its completely out of the screen it can send WM_DESTROY.