Improving gameplay

and locking the game to portrait orientation.
Adding connection screen

The connection screen will give the user a moment to connect to the BLE device, then proceed to the game. If the bot disconnects, then it will zip back to the connection screen.
Saving work in wiring up connection screen

I’m surprised the app is able to build, may not run. Need to go back and adjust the commit history.
Adjusting the byte headers

as accelerometer came before proximity sensor. Also, reworking the second screen as a stand alone game screen without concern for connecting the bot. The bot sends accelerometer data (X,Y,Z) in a single buffer instead of 3 separate buffers. Playing this game will also turn off the proxbot reporting the proximity. The other apps will enable it.
Finally registering the RBL_BLE delegate

The ship motion is jerky. Need to think of a method to smooth out the motion. Maybe move the repositioning elsewhere.
Much smoother and faster

just by moving it into the simulate physics method.
ToTheMoon app icons
UUIDs changed

and reversing the pitch movement to a more natural incline.
Adding flaming asteroid

I thought about it for a moment and had to research the difference between asteroids, comets, and meteoroids. It turns out flaming asteroids don’t exist and the closet approximation is a meteoroid entering the earth’s atmosphere and burning up.
http://en.wikipedia.org/wiki/Meteor#Meteor

An important lesson for the next version of the game.
Opening up the project in Xcode 6.1
Initial addition of RFDuino support files.
Renaming the avatar file

to make it generic.
Updating graphics to reflect a Dynepod
Connection window is now using RFDuinos

Successful connects.
Sharing and reassigning the delegate

between the ConnectScreen and the GameScreen. There may be a logic issue due to the switching. The app does compile and run without exception.
Remaining tasks
-enable accel data
-capture accel data and control ship.
Able to send/receive data from the BLE device

The incoming data still needs parsing but the format is visible (1 byte as operator code (0x04) specifying accelerometer data, 4 bytes for X axis, 4 bytes for Y axis, and 4 bytes for Z axis)
There is an issue that if commands are sent to quickly to the device they will override each other. It may be necessary to implement a confirmation return packet that will assert the previously send packet was interpreted.
Processing of the BLE data is accurate!

Most of the time, otherwise it will reset and start over building up the AccelPoint struct.
Also better bounds setting for the spaceship, ie. it will stay on the screen and not drift outside the viewport.
Found proper placement of the score on screen.

Will now have to increment time and reset time based upon impact.
When the BLE device is turned off

it does not execute the disconnect delegate. Instead it prints an error message. I will need to rewrite this section so that it calls the delegate in any case.

Using an SKLabel and a date to count up in milliseconds as the Time based score. The score will reset when a meteorite contacts the ship. Upon contact the controller will buzz.
A bunch of improvements in connectivity

The boolean to determine whether a controller is fully connected is publicly available.
Executing the disconnect delegate regardless of error condition ensures the app will receive the message of a missing peripheral and remove itself as a delegate.

Able to connect, disconnect, and reconnect, have other controllers with different Advertisement IDs  running simultaneously and have only the assigned Advertisement ID connect.