Bouncy Ball NG Progress report 3

Progress to report on Bouncy Ball NG. The home stretch! Everything is implemented, and just doing a little more testing before posting to the app store. I’m very happy that the Horipad Ultimate also works on my Mac. iPhone X and Apple TV gave me the most trouble.

 

Updates:
November 27, 2017: Announcement
December 6, 2017: Progress report 1
December 31, 2017: Progress report 2 Apple TV
January 17, 2018: Progress report 3 the home stretch!
January 24, 2018: Progress report 4 signing the certs!
January 29, 2018: Progress report 5 Submitted to the app store!

Beta testing right now. All features are in, works on iPad, iPhone, ATV, and Mac. My favorite platform is the ATV. Having it on the big screen is awesome. The iPad is my second favorite, because of how it feels holding it in your hand, directly interacting with the game, and the size of the screen.

At this point, I’m in bug fix only mode. I hope to be ready to submit within the next week or two. I do need a little more work on the Siri Remote interactions when navigating the menu, but I’m considering that a fix, since it works right now, just not as good as it should.

On the ATV, I spent a good chunk of time working on the control pad code. It took a lot of digging around to figure out you need only derive your class from GCEventViewController instead of UIViewController. Once you do that, you can change controllerUserInteractionEnabled to change if menu goes to the ATV main menu, or is handled in your game. Even so, I still have strange behavior in one of my screens when handling the B button, which also goes to the ATV main menu.

import UIKit
import SpriteKit
import GameplayKit
import GameController
class GameViewController: GCEventViewController {
    override func viewDidLoad() {
    ...

The example code in DemoBots that shows how to use the joystick doesn’t compile in Swift 4. I’m not in the habit of spending any time on code that doesn’t compile. I also have to wonder if they are purposely vague in the ATV developer video on game controllers. Not impressed with Apple’s documentation efforts.

The Siri remote is it’s own can of worms. Right now I do support it, but menu navigation with it isn’t ideal. Way too sensitive. I also want to be able to support just tapping the edges of the controller to change the active button, like you can on the ATV main menu. I’m sure there is a gesture recognizer I can take advantage of, but again, I am not very familiar with it.

Control pad on the Mac. This is very cool. The Horipad Ultimate works like a charm. After pairing the Horipad with my Mac, I kind of expected there would be something in the System Preferences. Nothing shows up. But I hooked up the joystick code into the macOS bits, and fired up BBNG. And just like that, I had control pad support in BBNG. The next few days were spent fixing up the UI to handle the control pad. It was actually a good thing, since it forced me to allow the user to use the keyboard to navigate the UI, instead of being lazy and forcing the mouse on a user. I mean the mouse is great, but sometimes it’s just nice to not have to reach over and use it when you just want to start playing.

The iPhone X I discovered has a very wide aspect ratio of 2.16. Other phones are 1.77, and iPad is even smaller (more square) with 1.33.

Make    Model           Aspect
iPhone  SE              1.77
-->     X               2.16
        8               1.77
        8 Plus          1.77
iPad    Pro 12"         1.33
        Pro 10"         1.33
        9" 5th Gen      1.33
        Mini            1.33

This simply means you have to rearrange your UI a little. When I had started the project, I was using code snippets from 2D Apple Games by Tutorials, which has a very good idea to keep the play field the same size across all devices. But as a result it didn’t do a very good job handling such a wide screen. Buttons buttons ended up too close to the top and bottom of the screen in the iPhone X, and you end up with a gap between the top and bottom of the screen on iPad and Mac (when not full screen). A better approach would have been to keep the play field the same size, but move your UI bits based on the height of the screen. Which I did for the most part. Buttons were always along the bottom or top, and had consistent offset from the sides of the screen. I was able to clean up the UI for the iPhone, but will need to tweak the iPad and Mac versions a little more to get the buttons at the top and bottom of the screen.