Tilt to live Possible with GS?
UtopianGames
Member Posts: 5,692
Is there a way to use Tilt where the more you tilt the faster my ball rolls in all directions?
Im trying to do a Tilt to Live concept (i understand GS wont be able to handle loads of actors but its just a test)
I want the controls to be very tight but cant seem to work this out.
Any help guys?
Darren.
Im trying to do a Tilt to Live concept (i understand GS wont be able to handle loads of actors but its just a test)
I want the controls to be very tight but cant seem to work this out.
Any help guys?
Darren.
Comments
It would be great if we could manage tight controls like the game above and move very slow if tilted a little and fast if tilted a lot.
Darren.
i.e.
if accelerometer.x >0.1 set max speed to 200
if accelerometer.x >0.3 set max speed to 300
etc etc
On your ball actor you would just say when accelerometer.x >0.1 accelerate at whatever speed you wish.
In theory this is one way which could work, i dont have my mac here at work so cant test this.
http://itunes.apple.com/us/app/fireflight/id359342941?mt=8
accelerate
direction vectorToAngle(accelerometer.x, accelerometer.y)
speed magnitude(accelerometer.x, accelerometer.y)*100
under motion set max speed to 200
done.
I have tried what you said (landscape mode game) and i cant for the life of me make it work properly....its very sluggish with no top end speed and the x y are messed up.
Am i right to think i still need 4 rules for left right up and down?
This is what im using atm and it works well but im using 3 rules for left for eg attribute game.Accelerometer.x >0.1 >0.3 >0.5
max(100, min(1000, 1000*abs( game.Accelerometer.Y )))
Cheers m8,
Darren.
Cheers m8,
Darren.
I'm working on a space shooter would benefit from good (read: working) tilt-based navigation. Any chance you could post (or email: barkbark00 at gmail dot com) a stripped down demo with the ball logic? Thanks in advance!
The biggest problem you will likely run into with making a tilt to live style game is the effect that moving actors have on FPS. I am making a game for the iPad and with 30 bad guys the FPS goes to around 40 and when I have 40 moving bad guys it becomes distractingly noticeable. What makes tilt to live fun and challenging is when nearly the entire screen is filled with moving red dots. If you used GS to do this it would likely crash. So what I have done is put a limit on the number of moving dougs (I mean bad guys) and then I also have on moving bad guys that have a simple two image animation to at least give them a little life without destroying the FPS. The combination of moving and nonmoving bad guys seems to find the balance between making the game challenging and having a reasonable FPS.
*in the Dougs category of games (you know, doug induced coma, addicted to dougs, doug overdose, etc.)
You will need 4 rules ill do a sample of each.
This is when iPhone is in landscape position (Y axis becomes left and right, X axis become up and down.)
1st rule
Move Left
When Attribute game.Accelerometer.Y > 0.1
Move
Direction 180
Speed 500*gameaccelerometer.Y
2nd rule
Move Right
When Attribute game.Accelerometer.Y < -0.1
Move
Direction 0
Speed -500*gameaccelerometer.Y
3rd Rule
Move up
When Attribute game.Accelerometer.X > 0.1
Move
Direction 90
Speed 500*gameaccelerometer.X
4th Rule
Move Down
When Attribute game.Accelerometer.X < -0.1
Move
Direction 270
Speed -500*gameaccelerometer.X
You can find the reasoning behind the whole (When attribute game.accelerometer.Y >.01) in the how to section, so I will not explain that part.
Now the speed result I guess is the main focus on this. in Tilt to Live the more you tilt the iPhone in one direction the faster it moves. Due to this you want a speed that involves the accelerometer. Now if you just put the speed as
Speed = accelerometer
your actor would be moving at a speed in between .01 - .80 (just rough estimate numbers)
this type of movement is hardly noticeable. This is the reason why I have the 500*accelerometer this will multiply the value of the accelerometer by 500 which will bring you around 100-200 speed range based on how much you tilt it because .20*500=100 and .40*500 =200.
**Note the number 500 can be replaced with any number you please to adjust the speed of the actor.**
Now the reason why I have the minus sign in front of the speed for down and right.
Due to the landscape changing the planes to move right you are going into accelerometer-Y and to move down you are going into accelerometer-X.
for the speed to come out as a positive number just through the minus sign in from of the 500 and we all know a minus multiplied by a minus equals a positive.
I hope this helps as I guess this could be considered my first tutorial i have contributed to GS.
Any thoughts as to how to add a calibration option?
I have not mastered GS yet so this isnt a "top notch" calibration idea, but you could try it.
on you calibration screen have the actor in the middle, so users can test it.
then have some buttons on the screen as well that would change the "500" number that I have in the previous post.
So it would be kinda something like this.
I have buttons A, B, C, and D.
button A (default) when touched turns "500" or any number it has been switched to back to 500 and saves it.
button B when touched turns 500 (default) to 300 and saves it.
button C when touched turns 500 (default) to 400 and saves it.
button D when touched turns 500 (default) to 600 and saves it.
This could possibly work for you as the lower numbers would make the ball move slower relative to how much you tilted it and the higher number would make it move faster.
Just a thought you can try out if you like.
I was talking about calibrating the accelerometer for center. Example, if I start the game tilted at an angle then the xy calculations are all off...