How to detect which way a character is moving? (Solved)

Started by Ali, Fri 05/03/2010 00:00:14

Previous topic - Next topic

Ali

It was pointed out in the thread for my Smooth Scrolling and Simple Parallax module that it would be better if the screen only started to scroll when the player was near the edge of the screen.

The way scrolling worked in lucasarts classics was quite elegant. When the player moves near one edge of the screen, the viewport pans to bring them into the centre. I've found a way of making my script (which is really Steve McCrea's) do that, the WIP script is below.

The trouble is when the player suddenly changes to walk in the opposite direction. Currently the screen continues to scroll until it reaches a point the player left when they changed direction. Instead, I need to make the screen come to stop quickly but smoothly even if the player is still near the edge of the screen.

If any of you clever scripting types can see the solution, I'd be grateful for a hint!

UPDATE:

Well, I have it working. To detect which direction the player is moving in I'm checking the loops.

I think this is a clumsy solution, because it could be fooled if the character was moving but locked to a particular view. Is there a foolproof way of finding out which way a character is moving?

Shane 'ProgZmax' Stevens

My memory is a bit foggy on the Lucasarts scrolling effect but if you turned heel while it was scrolling one way I think it would continue scrolling slower and slower and then upon reaching 0 would begin scrolling the opposite direction.  Basically, just have the x velocity reduce quickly until it hits zero and then have the velocity build up again in the opposite direction towards whatever the maximum is.  Some tweaking with this should yield a good result.

NsMn

#2
Lucasarts games actually cheated there: Your player character wouldn't be fast enough to trigger scrolling to a side while already scrolling to another at all.

Ali

#3
That's what I want to do ProgZ, but I don't know exactly how.

As NsMn points out the screen just needs to slow down to a stop, not change direction. The trouble is, how should I detect that the player turns on heel and walks in the opposite direction?

UPDATE:
At the moment I'm checking the loops but, as I mention above, that's not a good solution to the problem. I'm trying sampling the player's position every 2 game loops to guage their velocity, but this doesn't work for very fast characters.

Are there a more elegant solutions?

Shane 'ProgZmax' Stevens

Why is checking player.Loop for a 1 or 2 a bad solution?  It's fairly straightforward and if you want to make sure there's movement you could pair the check with player.Moving to prove he's facing a direction and MOVING that direction.  That should be all you need unless you want something more complicated?

Ali

Thanks for the reply!

Lets say a character is recovering from a hangover cure and the gamemaker wants him to wobble left and right while remaining facing one direction. Then using Loops wouldn't work.

I know that's an unlikely example, but something of the sort will exist somewhere in an AGS game. Since I want other people to be able to use this module, I'd like it to be as flexible as possible. If no other solutions are possible, I could include both methods and allow the users to switch.

Wyz

Another trick is to poll mouse inputs. This will only work when all walking is induced by mouse clicks.
Convert the mouse coordinates to room coordinates and compare them with the current character coordinates. Now you only need to keep track of which direction the character was facing the last walkto, so you can compare it with the induced walkto and know if he changed direction. Alternative you can also check if the character is currently moving when doing checks.
Life is like an adventure without the pixel hunts.

Crimson Wizard

#7
Can't you simply store previous character position and compare with a new one?
In such case you will not only know direction of movement, but also velocity.

Whoops sorry, missed you wrote
QuoteI'm trying sampling the player's position every 2 game loops to guage their velocity, but this doesn't work for very fast characters.

but why does not this working for fast characters?

CShelton

#8
Ali, I've spent some time and looked deeply into how the scrolling code works. What I'm pursuing (towards the same goal) is to use the inner workings of the code itself to handle a smooth, but speedy about-face.

I've got it working very smoothly at this point, but I had to take out the 40% middle screen dead zone. Working that back in is going to be tricky math, but it can be done. I have completely mangled what you posted, but when I'm done, I'll be able to tell you the gist of how I accomplished it.

Heck, isn't Steve McCrea still around? If this is his code, he could drop a solution in an instant, I'd bet.

Ali

I think I have it working with the deadzone, using the position sampling method, which does seem to work for faster characters. In an older version I was able to cause problems with fast characters, but it seems to be working now.

Thank you for your suggestion, I'll experiment with different methods of position-detecting and maybe allow the user to switch. This still has things I'm experimenting with, but here is the work in progress:

http://www.filefront.com/15776927/SmoothScrollWIP2.zip

CShelton: thanks for looking at the script, if you can find any more elegant solutions than the ones I've come to then I'd be very pleased to implement them!


Shane 'ProgZmax' Stevens

QuoteI know that's an unlikely example, but something of the sort will exist somewhere in an AGS game. Since I want other people to be able to use this module, I'd like it to be as flexible as possible. If no other solutions are possible, I could include both methods and allow the users to switch.


This sounds like the only possible exception, which you could provide for with some kind of placeholder 'drunk' condition that further affects the scrolling so the screen itself wobbles.  In this fashion (since you seem really dedicated to this, which is good!) you could provide a few such 'effects' out of the box for users to play with, sort of like scrolling presets if you will-

Normal mode: consistent, Lucasarts style scrolling left to right
Alky mode: wobbly, back and forth scrolling to simulate a sick/drunk effect
Pan and scan: have the screen scroll in units like pan and scan films
etc.

A few different methods of room scrolling would practically cement your module as the only one anyone need use, so I fully support such an approach!


SMF spam blocked by CleanTalk