0

I have a bunch of Tank objects inserted into a quad tree. Some of these tank objects can be clicked on if they implement a Clickable interface. The problem is that in order to know what is being clicked, I need to query the same quadtree, but the quadtree has both clickable and non-clickable objects in it.

Potential solutions:

  1. I could using instanceOf to see which ones in a specified region were clickable when the user clicks the screen, but I hear that using instanceOf is bad practice.

  2. I could maintain TWO quadtrees. one for just tanks, and one for clickable objects. But then I could have to update tanks that implement the clickable interface TWICE since they would be in two seperate quadtrees, which would be slow considering I have to update every step, and people only click the screen every so often.

  3. I could only insert clickable objects into the quadtree, and simply make non-clickable objects define dummy click methods. This would solve the problem, but it doesn't feel right because if something is non-clickable, then it shouldn't be implementing a clicking methods to begin with even if it is an empty one. Or is this ok?

I'm thinking #3 is probably the best way to do it, but I'm not sure. Any pointers?

EDIT: Now that I think about it, #3 would have some problems dealing with overlapped clicks. If a non-clickable tank overlaps a clickable one, and I click in the overlap section, unless I call all click methods for everything at that point, I could end up calling the click method of the wrong tank. To avoid doing THAT, I'd have to use instanceOf and find the clickable object and only call ITS click method.

So maybe #2 is better because I could easily cycle through all clickable objects at the clicked region and choose the one that is either at the top, or closest to the center of the region, and only call that tanks click method.

It could also not necessarily be that they overlap, but are just close together. If I were to make this game touch based, your finger isn't a point, but a region, so it might be better to cycle through objects in a region and find the closest clickable object, which would be hard to do with 3# without sifting through a bunch of non-clickable objects.

Tiby312
  • 53
  • 5

1 Answers1

2

#3 sounds pretty good. You could maybe enhance it by creating another interface that ALL your objects implement, for example "GameObject", which has a method "isClickable". Then you can have your clickable objects implement a "return true" for isClickable.

faffaffaff
  • 3,429
  • 16
  • 27
  • Yes #3 sounded good, but it just occurred to me that it might be problematic dealing with overlaps. see my edit for details. Now I'm thinking #2, but it's slow. – Tiby312 Jun 25 '13 at 16:15