Accelerometer Movement Done Right
ericzingeler
Member Posts: 334
Noticed there was a post earlier asking about accelerometer movement, but it was in Pro forums and I don't use my work account for posting non-work related junk. So I've worked a lot with tilt and I think I've nailed it down pretty well.
First, there is one very important function everyone must use when using the accelerometer... Low Pass Filter! The problem is, the raw reading is way way jittery and makes your actors tweak out when you attach them to it. So, we need to filter out the jitters to give us a nice natural feel.
Second, use move and not constrain to move your actors. This way, we keep the ability to use physics.
Third, we need to reverse the input if the device is flipped. Simple, but overlooked sometimes.
The project below demos these three points above along with putting a stopper on your actor so it doesn't roll off the screen. Please feel free to ask me any questions.
All functionality is inside actor. Use tiltSpeed attribute to adjust sensitivity. Post a question for more advanced settings of the Low Pass Filter. Thanks!
Project file: https://dl.dropbox.com/u/27937751/AccelerometerHow_EZ_01_31_13.gameproj.zip
First, there is one very important function everyone must use when using the accelerometer... Low Pass Filter! The problem is, the raw reading is way way jittery and makes your actors tweak out when you attach them to it. So, we need to filter out the jitters to give us a nice natural feel.
Second, use move and not constrain to move your actors. This way, we keep the ability to use physics.
Third, we need to reverse the input if the device is flipped. Simple, but overlooked sometimes.
The project below demos these three points above along with putting a stopper on your actor so it doesn't roll off the screen. Please feel free to ask me any questions.
All functionality is inside actor. Use tiltSpeed attribute to adjust sensitivity. Post a question for more advanced settings of the Low Pass Filter. Thanks!
Project file: https://dl.dropbox.com/u/27937751/AccelerometerHow_EZ_01_31_13.gameproj.zip
Comments
Excellent stuff, a definite improvement on what I've seen, especially where the direction changes, much less of a linear 'kick', a much better transition. Thanks for uploading !
It's not clear, even from looking at your code, how you've made and implemented a low pass filter ? I've tried to do a low pass in the past by using a timer and interpolate, so the accelerometer is only being sampled every X seconds - but you can probably imagine the limitations of this kind of thing, but you seem to have completely lost the high frequency stuff . . . . . how !?!
You're basically taking 4 percent of the current accelerometer reading and using 96 percent of the last reading that only used 4 percent of its current and 96 percent of the previous and so on... Not sure if that makes sense or not... kinda of hard to grasp.
I originally got the filter off of Stack Overflow and made it fit into GS.
You can also throw a linear equation into the move behavior to trail off the sensitivity the more the device is tilted... There's all kinds of fun stuff you can do with this. Math is our friend.
No, that makes perfect sense.
Good stuff.
Thanks for the input and great design!
Is there a way that I can make the Actor move a bit faster?
If so please let me know.
Thanks again.
One point though is that the Move behavior sends physics events, but it doesn't receive them very well. If you have a projectile hit your box the box will hardly budge. The projectile will bounce though. This could be good or bad depending on your game. This is good for breakout type games but bad for situations where you would need the control actor to move on impact. The Accelerate behavior is a suitable replacement in those cases, since it doesn't interfere with receiving physics events. Accelerate isn't as smooth as @ericzingeler 's example, but it can be tweaked to be a close approximation - also, no low pass filter needed is needed since the inertia absorbs the noise.
Also, since when did constraining a variable to itself suddenly not cause bugs in GS? That used to be a "very bad thing." Is this now OK?
Like @JoeMeister said, just swap out X for Y. You may have to change. If the actor is going in the reverse direction of the tilt, just change the direction of the move behavior to 180.
@ORBZ
Yep, move is sucky for physics. Well technically, we're not constraining a variable to itself... we're constraining a variable to itself*.96+( game.Accelerometer.Y *.04)
John
Well, you'd have to create a 2nd set of the function. You need separate functions for both X and Y. Just make a copy of everything in my template and replace x for y.
@Bluemoonstudios
Here's an updated project file with up,dn,left,right tilt. Turns out we needed to use accelerometer Z (roll), not x. Also, to move along x-axis, we use accelerometer Y; so I apologize for the wrong instruction before.
https://dl.dropboxusercontent.com/u/27937751/gs/modules/AccelerometerFilter_v1.0_05_23_13.gameproj.zip
Like @ORBZ mentioned, this method isn't great when your colliding with objects. The weird bouncing behavior can't be avoided when using the move behavior.
The z position center... just tap screen when device is at a comfortable angle when holding. Doesn't matter what angle you tap at, will always work.
Yep, no problem.
Also, just posted a project using this functionality for a labyrinth game type in this thread:
http://forums.gamesalad.com/discussion/57033/use-accelerometer-real-ball-rolling#latest
No problem, and thanks!
You learn a lot faster when you get to do this stuff for a living... sit down and grind it out!
Yes, GS appears to be limited and simple at first, but we quickly find out that our own creativity sets the bar.
https://itunes.apple.com/us/app/gluhwurmchen/id601757784?mt=8