modeling mouse control?

add some randomness, based on how "accurate" the AI is supposed to be.

One of the things I picked up from a friend''s Computer Science degree: there''s an industry approximation for the time taken for a user to move the mouse to a button: {Time}={constant}*log({distance to button})/log({area of button})

Using that might help:
{delay}={constant}*log{distance moved}/log{area of range of possible "mouse locations"}

rmsgrey: You can''t have a single equation for that... some users are slow, some are fast. If you''ve ever seen those "Test your mouse clicking speed" tests, you''ll notice the HUGE difference in times between users. The accuracy of the mouse, the time taken to THINK about what to do next, the eyesight of the individual (can cause them to have problems clicking buttons, and smaller text), the mouse sensitivity may effect the speed in which they can click... a lot of things. So, using a static equation to calculate the delay will not accurately model the mouse click delay users. I would simply just make it so the mouse can only move a certain distance each frame, so the farther the button/position, the longer it takes to move the mouse there... and this value can be changed (the speed in which the mouse can move) to make the AI better or worse. This is similar to how my FPS AI works, you give the bot a "smartness value" (0 -> 100) and it''s value determines how fast they can turn around, and aim and stuff like that. Another reason you can''t use that formula, is that he needs it to turn/aim with the mouse also, so it isn''t the same as pressing a button, because you need to take into account visibility of the object (if I whipped around, takes me a second to process that there is a player, THEN I aim), and the accuracy of the bot (if he has a bad shot, when he''s moving faster, make him over-shoot, and under-shoot the target when trying to aim quickly).

The thing is, a human won''t be accurate... he/she will overshoot the intended position, and then try to correct.

I have a mouse velocity setting... would that be of any help?

The constant factor in the equation would be a function of user/computer. To capture reaction time to new data, you''d add:

{reaction constant}*{area of new object}*{some sort of contrast value}

to the time taken. The trouble with constant speed motion is that''s not what happens in real life - you move the mouse faster when you''re moving it across the entire screen than when you''re moving it a few pixels. The biggest flaw in the equation is that it assumes that human accuracy is the limiting factor on mouse speed rather than physical constraints. For most real world situations, this is true. It also assumes that targets are (very) approximately square/circular rather than linear. Again, generally true in real world.

Using my equation, you''d have to randomly position the virtual mouse in an area centered on the target with size dependent on elapsed time, possibly recalculating for the next time step (aim approximately then refine). Or interpolate mouse position (probably using constant acceleration to midpoint then constant decel) to a random position within the target over interval based on the area of the target (aim precisely in a single smooth motion)

Some quick experimentation shows I can use either approach, though for rapid motion, I favour the former.

One possibility is this:

Calculate all the points the computer should click on, the make a spline connecting these points. (ask what a spline is in the math/graphics forum ) figure out some constant speed at which the cursor can move (about the same as humans move the cursor).

This would make the computer move look smooth and humanlike, yet professional - compared to the nerdish straight lines or jittery random errors...


just an idea

Ulf


well, for a c&c style game that is ....
If we're talking about an elite style 3D simulator, then i guess my advice is pretty useless ...

[edited by - UlfLivoff on February 24, 2003 8:14:39 PM]

After observing my own mouse movements for a while, I have discovered that they mostly have a somewhat flat/bent parabolic shape. You could modify coefficients to make a parabola that roughly connects the two points and roughly immitates human mouse movement. You also might want to add a little bit of noise to this, not enough to make a large difference, but just so it isn''t a completely smooth path. Then, you add a small fraction to the one component or the other of your motion vector at the moment. This creates the more bent shape and puts you slightly past your destination. You then, after a short pause of changing direction, follow a strait line the short distance back to the target. The distance is short enough that people would not notice unless they were looking specifically for it. Also, for a velocity vector for the mouse, you could use a flattened sin wave with noise added to it to create a fluctuating speed of movement, similar to what you would find if you recorded your own. These are all just suggestions. I don''t know what your restraints are as far as using up processor time.

Actually, my games running at a constant 100 FPS. Unfortunatly, it doesn''t work too well below about 40 FPS, and I haven''t added Pathing to the AI... so I''m not clear in that area.

However, it doesn''t need to be realistic to the finest details. The user can''t see the computer mouse. Just the results.

In my game, the ships will allways face the mouse (unless you opted for keyboard control). However, they turn way too smoothly, and they are too accurate. Thats the problem.

You might want to look around at some of the bots for various FPS games. Most of the fancy one implement some kind of adjustment for aiming so that it isnt instant, and many of them do so quote well. You could probably use the same kind of formulas, but you would have to convert them from polar coordinates (angles the bot is facing) to cartesian coordinates (x and y of the mouse). Many bots include source.

My bots allready have a "mouse_x" and "mouse_y", but they don''t move them the way I want to. Its very steady, and very accurate. Not realistic, and it makes the AI too tough.

How about adding some Perlin noise? That''d do the trick

---

ai-junkie.com