I am making a simple game for Android devices. In this game, the user moves a control by turning the device to the left or to the right. I noticed that the orientationChanged message wasn’t sent. After some experimentation, I found out that all mobileOrientation features were broken, but the mobileAcceleration features worked. However, accelerationChanged message was never sent. I don’t know if these problems are LiveCode bugs or malfunctions of my own device, although I do have a feeling that something is wrong with LiveCode’s mobileOrientation and mobileAcceleration features.
Anyway, the point is that I found a way to make my game work correctly and I decided to write down how I did it. This is just a quick note. If you find anything to improve, just post it in a comment at the bottom of this text.
Before you can use the acceleration features of your device, you have to set up this feature for your app. I do this in the openCard handler to make the time between starting the app and rendering the first card as short as possible. It doesn’t matter whether your stack starts up in landscape or portrait mode. The acceleration values will adjust automatically.
Because you might want to play your game on desktop machines too, you need to check if the game is played on a movile device, using the environment function. Not all devices have acceleration features, so you have to check for those too, using the mobileSensorAvailable function. The parameter of this function can contain “acceleration”, “rotation”, “heading”, or “rotation rate”. For my game, I need “acceleration”. This is sufficient to make a control move accordingly the movements of the device.
on openCard
if the environment is "mobile" then
put mobileSensorAvailable("acceleration") into lSensorAvailable
if lSensorAvailable then
mobileStartTrackingSensor "acceleration",false
else
answer warning "Acceleration sensors are unavailable."
end if
else
put false into lSensorAvailable
end if
// first finish rendering, then send setupCard message
send "setupCard" to me in 0 millisecs
pass openCard
end openCard
If the sensor is available, we can turn it on using the mobileStartTrackingSensor command. The first parameter of this command determines the sensor. The second parameter toggles loosely, but power-saving sensor readings. If this parameter is false, it will read accurate values but also use a lot of energy. I have chosen to use accurate values for my game.
I want the openCard handler to finish before I start reading sensor values. The reason is that the card will render only after the openCard handler finishes and I want this to happen as quickly as possible. By using the send in time command, I make sure that the setupCard command is executed after the openCard handler finishes and the card is rendered.
on setupCard
if the environment is "mobile" then
pollForRotation
end if
end setupCard
The setupCard message can also be used to put controls in the centre of the card, to set up a score display, or do download some data from a server for instance. We don’t need that functionality in this simple example.
The pollForRotation handler actually doesn’t poll for rotation. It polls for acceleration, but my original intention was to get rotation values and hence the name. Actually, this is what makes me think that something is wrong with LiveCode. Perhaps RunRev got a few wires switched under the hood.
The pollForRotation handler first reads the device’s position. The more you turn your device to the left or right, the lower (less than 0) or higher (greater than 0) the value returned by the mobileSensorReading function.
Although polling might seem inefficient and power intensive (as polling usually is), it has two big advantages. First, polling the mobileSensorReading function works, whereas the accelerationChanged message doesn’t seem to work. Second, the documentation about the mobileEnableAccelerometer command suggests that the accelerationChanged message can’t be sent more often than 1 time per second –when this message becomes functional in LiveCode, I’ll have to test if the mobileEnableAccelerometer command accepts fractions of seconds.
The pollForRotation handler reads the acceleration value, stores it, and executes the moveControl handler. After the moveControl handler finishes, the pollForRotation handler executes itself again in 150 milliseconds. By keeping the reading frequency low (almost 7 times per second), I hope to save some energy and leave enough time for other game controls to be updates and rendered.
on pollForRotation
put mobileSensorReading("acceleration") into myDelta
moveControl item 2 of myDelta // horizontal, left-right movement
send "pollForRotation" to me in 150 milliseconds
end pollForRotation
The mobileSensorReading function returns a list of three values: front-back horizontal movement, left-right horizontal movement and vertical movement. We need the second item from this list.
The moveControl handler does some calculations and moves the button. The moveControl handler needs a paremeter, indicating the amount of left-right movement. We don’t want the game to be unresponsive but at the same time we don’t want it to be too sensitive. Therefore, we make two adjustments. First, we calculate the square value of the horizontal movement. If the player moves the device quickly to the left or to the right, the game will respond accordingly. However, if the plater moves the device slowly, the game will make small adjustments, which allows for high accuracy. We’re also increasing overall speed, by multiplying the square value by 1.2. We’re doing this just because we thought the game was a bit slow at first. You can change this number as you like. The variable myHorizontalSpeed now contains the number of pixels by which we want to move the control. We use the sign of theDirection to determine whether we want to go left or right.
on moveControl theDirection
// for demo, assume 1 button exists
put 1.2*theDirection^2 into myHorizontalSpeed // the movement of the button at a time in pixels
if theDirection < -1 then
set the left of btn 1 to max(0,the left of btn 1 - myHorizontalSpeed)
else if theDirection > 1 then
set the right of btn 1 to min(the right of this cd,the right of btn 1 + myHorizontalSpeed) end if
end moveControl
If theDirection is very small, i.e. between -1 and 1, we don’t move the control. This may happen when the player accidentally moves the device or if the device appears to be extremely sensitive. If theDirection is less than 1, we move the button to the left and if theDirection is greater than 1, we move the button to the right.
The left side of a button can be at any location above 0. The minimum value for the left of a button is 0. Therefore, whenever the new value of the left of the button is going to be less than 0, we set the left to 0. In all other cases, we set the left of the button to a value slightly less than its current value, if theDirection < -1.
The right of a button can be at any location below the right of the card. The maximum value of the right of the button equals the right of the card. Therefore, whenever the new values of the right of the button is going to be larger than the right of the card, we set the right of the button to the right of the card. In all other cases, we set the right of the button to a value slightly higher than its current value, if theDirection > 1.
If the button isn’t at the extreme left or extreme right location, the amount by which we move the button is determined by the variable myHorizontalSpeed.
If you want to stop the game, you only need to stop the pollForRotation handler. E.g. you can write the following in a button script:
Zn mouseUp
put the pendingMessages into myMessages
filter myMessages with "*pollForRotation*"
repeat for each line myMsg in myMessages
cancel item 1 of myMsg
end repeat
end mouseUp
To start playing, just call the pollForRotation handler again.
