Let me guess: did you think there was mouse movement there? Well... theoretically, it is, yes. If you click the mouse three times, then, as a rule, one of the clicks gives the result. But this is still a hemorrhoid. Because at close distances you just get tired of clicking, and at long distances you click and don't see if he moved there, behind the screen, or you need to click again. It's very inconvenient.
And yes, now do you know what else I remembered? Your hitboxes are weird :) That is, they are not hitboxes at all, but the meaning is the same. When you find out which building the character is standing under, as far as I understand, you take the corner point of his sprite. Most likely the lower left one. And you need to take the center! Because when two buildings stand one above the other, it turns out very strange. The player has already crawled into the upper one, where his heel is only touching the lower one, but the game confidently asserts that he is in the lower building. Again, it is constantly causing inconvenience.
Actually I’ve been playing using mouse for a whole time except for 2 days I’ve been experimenting with keyboard movement a few months ago. For long distances there is a map that can be used to navigate from one end of the planet to another. Also I will improve markers mechanic to be able to travel between them in one click.
What platform do you use? It takes one click for me to move. And hitboxes issue is weird too, because I have debug tool to see colliders of every ingame object. I will enable it to see if there is some problems with hitboxes. Player’s sprite is also centered properly for me, right between his legs.
I also have idea to change camera pan button from left button to right, to avoid problems with movement.
Windows 10. The problem with the mouse is that you have both the click and drag-n-drop tied to one button. Maybe it's convenient for mobile devices, but for me, a click is very often not perceived as a click, but is like a drag and drop. Just a zero distance. I would venture to assume that you distinguish between clicks and drags by timer, but you need to check for the range of dragging. After all, even if the click was very long, but the mouse did not move, this is definitely not dragging. So why artificially limit the player in the speed of movement of his fingers? I'm already old, my fingers don't bend as fast as when I was young :) And therefore, a whole bunch of my clicks are simply not perceived by the game as clicks.
And yes, this is exactly what I told you about :) Unless the dot is not in the lower left corner, but in the bottom center. And it turns out like this:
That is, I am already in the market with my whole body, but the game is still sure that I am at the university.
And, of course, ideally, the buildings' hitbox should be their outline, not the rectangle of the map cells that this building occupies. What if you want to make a lamppost later? Tall, but narrow. Or some kind of rails. I understand that this is an early beta now, there is no need to repeat this again. It's just that often things should be done right right away, no? So as not to redo it later, doing unnecessary work.
I differentiate click from camera drag both by moved distance and timer. If there was no mouse movement (range of dragging equals to 0), it always will count click as click, despite elapsed time. And if there was camera movement, it will not count click as click after 200 ms. I’ll see what I can do to make mouse movement controls smoother.
About hitboxes, now I understand that we are talking about problem I’m aware of. When I was assigning images to buildings, I forgot to offset them, and noticed it only after I’ve finished all buildings. Since this is tedious (and time consuming) process, I decided to leave it as it is for a while. I will definitely fix this in the upcoming updates.
I had this problem with trees during development, and I will fix buildings just like trees now works, since all colliders are handled by single algorithm.
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.
