Move to Mouse
by Joseph Albon · in Torque Game Builder · 03/04/2005 (7:47 am) · 5 replies
First off, I wanted to thank you Melv for such a fun new toy =) I don't think I've stayed up so late programming in a long time (unless it was related to my day job). I've been working on an RPG idea for the past few years and never have I gotten as far as I have in 2 evenings worth of work (I restart projects from scratch a lot).
On to the point of this thread. I was banging my head against this problem for quite some time last night. Not sure if it was just because I was tired or not, but I'm hoping that if anyone else is stumped on it this might help out.
The goal: ability to move player character with the mouse.
So I started out by setLinearVelocityPolar([speed],[angle between mouse and player's current position]) in my mouseDown and mouseDrag events. That worked absolutely great, the player would run at the cursor even when I moved it around the screen.
The issue was stopping. There were two paths that I was thinking of using when I started this. One was to just have the player stop on mouse up, but I didn't like that idea because if a player clicked on a doorway, I wanted the character to run to that doorway, not stop after three steps.
The second way was to set up a schedule to make sure the character wasn't at the last known mouse position yet, and if it was to stop it.
I decided I didn't really like either of the options. What I ended up doing seems to be a hack to me, so I'd appreciate insight if there is a better way.
On mouseUp I made a quick call to setWorldLimit using the mouses position and the players position as the limits, and set the action to clamp. Then I had to go back in and edit all my start moving functions to reset the clamp to what it was originally (I also allow characters to move by keyboard).
This sounded like it would work perfectly, but in practice it wasn't quite so simple. Clicking, my character would move at a speed of thirty. Clicking and dragging my character would move at a speed of thirty. But release the mouse and he jumps to lightspeed.
I'm probably just really dense, but the issue was the fact that the player's position is the center of the image. So by setting my bounds to the player's position, it cut halfway in to the player and seemed to launch it at extremely high speeds (could be a nifty effect when used by a highly trained professional). Added and subtracting half of my image's size to the min and max values of the limits solved my issue and now it seems to work flawlessly.
Sorry for the long post, just hoping that I'm not the only one dumb enough to have this issue.
If any of you have a better way of implementing this or know of any issues my way could cause, please share. It seems to be working though (amazingly).
On to the point of this thread. I was banging my head against this problem for quite some time last night. Not sure if it was just because I was tired or not, but I'm hoping that if anyone else is stumped on it this might help out.
The goal: ability to move player character with the mouse.
So I started out by setLinearVelocityPolar([speed],[angle between mouse and player's current position]) in my mouseDown and mouseDrag events. That worked absolutely great, the player would run at the cursor even when I moved it around the screen.
The issue was stopping. There were two paths that I was thinking of using when I started this. One was to just have the player stop on mouse up, but I didn't like that idea because if a player clicked on a doorway, I wanted the character to run to that doorway, not stop after three steps.
The second way was to set up a schedule to make sure the character wasn't at the last known mouse position yet, and if it was to stop it.
I decided I didn't really like either of the options. What I ended up doing seems to be a hack to me, so I'd appreciate insight if there is a better way.
On mouseUp I made a quick call to setWorldLimit using the mouses position and the players position as the limits, and set the action to clamp. Then I had to go back in and edit all my start moving functions to reset the clamp to what it was originally (I also allow characters to move by keyboard).
This sounded like it would work perfectly, but in practice it wasn't quite so simple. Clicking, my character would move at a speed of thirty. Clicking and dragging my character would move at a speed of thirty. But release the mouse and he jumps to lightspeed.
I'm probably just really dense, but the issue was the fact that the player's position is the center of the image. So by setting my bounds to the player's position, it cut halfway in to the player and seemed to launch it at extremely high speeds (could be a nifty effect when used by a highly trained professional). Added and subtracting half of my image's size to the min and max values of the limits solved my issue and now it seems to work flawlessly.
Sorry for the long post, just hoping that I'm not the only one dumb enough to have this issue.
If any of you have a better way of implementing this or know of any issues my way could cause, please share. It seems to be working though (amazingly).
About the author
#2
EDIT:
well maybe using a sprite would be better, then just have a function that could turn all of them "off" or "invisible" ... let them be in their own group so you can control collision
I could probably work up a hacky script version for now, though depending on how long until you add it to T2D melv, lol my hacky version couldn't match yours but I know you've got your plate overflowing with things to add and change so if wanted I could work up some sort of script solution for now
03/04/2005 (8:45 am)
I guess for a hacky target/path system (until Melv can get a full implementation in) one could build the system of fxSceneObject2D's as path markers then once you get a good implementation of a sort of "setDestination" to path thing working the mouse could just then create active path points...EDIT:
well maybe using a sprite would be better, then just have a function that could turn all of them "off" or "invisible" ... let them be in their own group so you can control collision
I could probably work up a hacky script version for now, though depending on how long until you add it to T2D melv, lol my hacky version couldn't match yours but I know you've got your plate overflowing with things to add and change so if wanted I could work up some sort of script solution for now
#3
set new destination
while (not at/near new destination)
--do incremental move in the right direction
Obviously, this has no pathfinding/obstacle avoidance, collision/conflict handling, or anything else of that sort, but honestly I doubt that you'll see a whole lot of that type of implementation in a base product of any sort in any case. The specifics are so game/genre specific that anyone (yes, even Melv and Josh!) might be hard pressed to do a generic solution.
Heh..I know, been working on this type of thing for my RTS-SK project, as well has GG/Josh for the RTS-SK itself!
03/04/2005 (10:44 am)
TGE, and especially the RTS-SK already does a very basic implementation of "move to destination". It's actually a very simple algorithm:set new destination
while (not at/near new destination)
--do incremental move in the right direction
Obviously, this has no pathfinding/obstacle avoidance, collision/conflict handling, or anything else of that sort, but honestly I doubt that you'll see a whole lot of that type of implementation in a base product of any sort in any case. The specifics are so game/genre specific that anyone (yes, even Melv and Josh!) might be hard pressed to do a generic solution.
Heh..I know, been working on this type of thing for my RTS-SK project, as well has GG/Josh for the RTS-SK itself!
#4
- Melv.
03/04/2005 (10:44 am)
Dude, not only is the plate overflowing but it's starting to drip off the table... ;)- Melv.
#5
03/04/2005 (4:51 pm)
Stephen points the way, that's pretty much the best way to do it. It's also nice for networked situations (down the road), since it's easy to predict / sim on client vs server. And if you have that really basic functionality up and running, you can use it if you have pathfinding junk going on too, only instead of one single point to move to, you basically set move destination repeatedly, according to whatever path points your pathfinding algo spits out. Likewise with curves, you can use the same basic little routine, only instead of doing your incremental move linear, you'd curve-fit. :) 
Associate Melv May
Already got this kind of thing on my list as it falls in line with doing a similar action with angular velocity as well as the linear.
- Melv.