rich Posted July 20, 2017 Share Posted July 20, 2017 Hi all, Am busy working on the Input Manager for v3 and an interesting question arose. There's no "right or wrong" answer, so I'm just after a vote / show of hands really. Just to explain a little first: * A Sprite has to be 'input enabled' before v3 will consider it for processing (just like v2). * Sprites have a bunch of callbacks like onDown, dragStart, onOver, etc. These are all empty by default, but you can change them. * The Input Manager itself will also dispatch pointer events, such as POINTER_ON_DOWN and POINTER_OVER. So you could, if you wanted, control all your game logic from these events, or from the callbacks on the Sprites, or a mixture of the two. Here's the question though ... At the moment in v3 if you have 8 input enabled sprites on the screen, all overlapping, and you click them - you will get 8 POINTER_ON_DOWN events firing, and potentially 8 onDown callbacks firing - one for each sprite. What I'd like to do is the following: The Input Manager only ever dispatches ONE event of each type. So if the pointer moves over 8 sprites, it dispatches POINTER_OVER just once and the event contains a property called 'gameObjects' that contains an array of all 8 sprites. The 8 sprite onOver callbacks will still all fire. The event will also contain a property 'gameObject' which is a reference of the sprite that is on the top of the display list (based on z-index) out of those 8. I've been trying to match the DOM with how this works, but in the DOM if you have 8 DIV elements, all with onclick handlers, only the top-most DIV ever fires. Anything below it is ignored completely. I could emulate this behaviour, but I feel like in games it's more useful not to. My worry is that in some cases you do only want the top most sprite to fire. For example, imagine a deck of cards and you click the top card, you don't want all the other cards below it to fire events or callbacks as well. But in some cases that is what you want. Should I make it an option in the Input Manager? "onlyReturnTopSprite" kind of thing? Or should I just fire it all and let the devs worry about managing the fallout? Cheers, Rich Link to comment Share on other sites More sharing options...
squilibob Posted July 21, 2017 Share Posted July 21, 2017 Will the array be in Z order? I can't see any reason why devs can't just assign gameObjects.shift() if they want the top sprite. Link to comment Share on other sites More sharing options...
alex_h Posted July 21, 2017 Share Posted July 21, 2017 In my experience having all game objects fire tends to be a real pain. You virtually never want this behaviour, and in those rare occasions that you do it would be easy enough to construct a system of your own to get all the objects at the point of the click. It's much better if the engine can just fire for the front most object. Link to comment Share on other sites More sharing options...
rich Posted July 21, 2017 Author Share Posted July 21, 2017 Yes, the array is in z order. I finished the implementation last night. By default it will only fire for the top-most object, but you can set a flag in the Input Manager telling it to fire from everything if you wish. So basically it now does both PBMCube and Juan 1 1 Link to comment Share on other sites More sharing options...
PBMCube Posted August 6, 2017 Share Posted August 6, 2017 This is the same problems from Flash ActionScript 3; Here's some conclusions: https://stackoverflow.com/questions/4924558/listen-to-click-event-on-overlapped-sprites I remember using a "Bubble up event" if it was active. Link to comment Share on other sites More sharing options...
md_lasalle Posted August 11, 2017 Share Posted August 11, 2017 Instead of having a flag in the Input Manager, why not decide this on a per sprite basis? sprite.inputPassthrough = true | false ? Can't wait to upgrade to v3 Link to comment Share on other sites More sharing options...
Recommended Posts