Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(1 edit)

Hmm :) Why is there a timer? I'm currently on a home machine where there is no msdn, so I can lie with the names, but... This is usually done like this: the MouseDown fixes the click point. MouseMove provides data for rendering the drag animation. The MouseUp fixes the exit point of the click. And, in fact, it calls the drag or click handler. If the click point coincides with the exit point, it is a click. If different, there was a drag. Why do you need a timer? If you are afraid that the user will also move the mouse during the click, if he has a tremor or clicks with a finger half the size of the screen on a mobile device, just make a zone inside which dragging is both a click. Just set a condition that the distance between the points is less than the specified (radius of the zone). However, then you will get the opposite effect :) If now I can't click, instead getting drags to a distance of zero, then there will be false positives causing the character to move as a reaction to the micro-displacement of the camera.

There is such a rule, every programmer should know it. "The best is the enemy of the good" :) In another reading, it sounds like "too much is good - it's not good." Unnecessary checks are unnecessary errors. If we're worried about false positives, maybe we should just avoid them? On the computer. for example, it will be enough to separate clicks and dragging the camera to different mouse buttons and the problem will be solved by itself :) It's not for nothing that clever designers have attached several buttons to the mouse at once. It was for a reason! :D


Update: 

And more. Never, you hear, never assume how the user will act. The user is a messenger of Primordial Chaos, dreaming of becoming an Emissary by his actions. Users will always, you hear, always find a way to do something that you would never have thought of. Learn Murphy's laws by heart and hang them in a frame in the most visible place :)

And you think he'll make it in 200 ms. And if not? If he's old like me? If he has arthritis and his fingers don't bend? If he plays at work on an industrial computer with a touchpad and buttons that withstand hammer blows? If he got dislocated/concussion /diarrhea and now he's sitting at home, through cramps and pain, pressing some buttons in some game. And you've already decided everything in advance and for everyone.

I mean, you'll probably decide not to suffer and increase the timeout by another two hundred milliseconds :) Fifteen years ago, that's exactly what I would have done :) And it will even work. It's just that the error will occur even less often and, perhaps, if you overdo it, another one will begin to occur, in the form of a delay when dragging. It is better to get used to doing the right thing right away, so that later you do not listen to the user and do not waste time on alterations. Is not it so? :)

However, it still won't save you from users who want strange things :D

Actually I do use algorithm you described. I handle button_up/button_down events for movement. I can’t add extra time for click window, because even 50 more ms will introduce jittery motion, when both camera movement and click would occur in one click (I’ve already tested it and decided to go with 200 ms as least noticeable). I’m thinking about cursor confinement (when you move mouse to the screen border, it drags camera, like in some games), or move drag from left to right mouse button, or click and hold to move.

As of “never assume how the user will act” part, again, this is why I’ve made early release. I need feedback to understand how majority of user sees my game, and what parts of the game must be adjusted. Also I do know that it is hard (almost impossible) to predict how user would act.