Post by AlexTheRegent in ReSurfaced comments

Viewing post in ReSurfaced comments

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.

AnotherBoris1 year ago (1 edit)

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.

AlexTheRegent1 year ago

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.

AnotherBoris1 year ago (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

AlexTheRegent1 year ago

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.

itch.io

Viewing post in ReSurfaced comments