If there’s one thing I’ve learned over the past week, it’s that catching a cold while pregnant really, really sucks. All of the good meds are off-limits, so it’s all up to warm washcloths on my head and saline nasal drops and plain ol’ Tylenol to save the day. However, despite all that, I did manage to drag myself to the nearest Best Buy to scoop up a new Apple TV on Friday, and boy: it got me thinking¹.

When I first came up with my idea for a game, I thought that I’d make it iPhone-only, just to make it simpler for myself. However, everything Apple has done in the past few years—Storyboards, Auto Layout, Size Classes, asset catalogs—clearly points to a preference for Universal apps². Also, I enjoy playing games on my iPad, and I know others do too (especially kids, who would be a great audience for my game). But what about the TV? Is that biting off more than I can chew?

Turns Out™, it’s really easy to get a Universal game working on the new Apple TV. My plan is for my game to use the device’s accelerometer for character movement; conveniently, an accelerometer is built in to the new Siri remote, though I’m not sure how easy it is to figure out the remote orientation. (EDIT: I just checked the API doc for GCMotion and found this statement:

Although the remote supports motion data (and the GCMotion profile), the remote cannot determine the attitude or rotation of the remote. The corresponding properties always return constant values.

I’m not exactly sure how to interpret that, so I guess I’ll have to experiment once I get things up and running.)

In addition to the prospect of having my game work on the Apple TV, another thing that really excited me today was the release of a documentary called CODEGIRL. It’s free to watch on YouTube until November 5, so go see it while you can! I watched the entire thing this afternoon and found it really inspiring. I wish such opportunities existed when I was in high school, because even though I got straight As and was tied with my best friend as salutatorian of our class, I still didn’t think I was smart enough for a career in computer science. Part of that was my own stupid fault, and part of it was all that cultural socialization crap that says that programming is for boys (particularly boys who have been tinkering with computers since they were two years old or whatever).

Anyway, it’s a pretty neat film and I hope that a lot of people check it out!

Today I’d like to talk about one of my favorite new toys: the Fujifilm x100T. I bought as a birthday treat for myself back in July, and have had only a few opportunities to really use it since then. However, the times I have used it, I’ve experienced a joy that reminds me of why I ever loved photography in the first place.

The first thing you should know about the x100T is that it has a fixed 23mm f/2 lens, which is equivalent to 35mm. In other words, if you want to zoom in and out, you have to use your feet. The design harkens back to an earlier time (though it does come in an all black version that looks slightly less retro), and the similarities to old film cameras don’t end there. Which brings me to the second thing you should know about the x100T: it has lots of physical controls. Metal knobs, rings, wheels. They feel cool to the touch, are heavy-duty, durable, and make a satisfying “click” when you turn them. That physicality is key to the experience: you feel like you’re finally manipulating hardware instead of just software. Sure, you can use the screen to set stuff too, but why would you want to?

The front of the lens has an aperture adjustment ring, which can be set to “A” for auto. On the top of the camera there are knobs for shutter speed (which can also be set to “A”) and exposure compensation as well. If the aperture is set to auto and the shutter speed is not, you’re in shutter priority mode, and vice versa. I left both the aperture and shutter speed on auto for most of the photos I took and was pleased with the results.

Another one of my absolute favorite things about the x100T is how light it is. According to Fuji’s specifications, it weighs nearly a pound…but it certainly doesn’t feel like it. I have a deep-seated hatred of feeling encumbered, especially when I’m going to be doing a lot of walking around for a long period of time. It’s the reason why I sometimes carry a wallet instead of a purse. So believe me when I say that I was happy to have this thing dangling around my neck for hours on end!

The final feature I’d like to talk about is Fuji’s film simulations. Because I love vibrant colors, all of the photos in this post were set to the “Velvia/Vibrant” simulation, with an additional simulated neutral density filter. All of the photos are also untouched: all I did was process them in-camera using Fuji’s RAW-processing feature, which basically “bakes in” the film simulation to a JPEG along with any other tweaks you want to make (I didn’t make any).

I mostly like to take pictures of animals and flowers and landscapes, so I can’t really speak to how well the x100T handles portraits. However, it’s going to be my primary baby-photo-taking instrument as soon as my son or daughter arrives in March, so I guess I’ll find out! As of this writing, the Fujifilm x100T is $1299 at Amazon.com.

Let me start by saying that I’m completely new to game development. I would like to make a top-down 2D game in which there is a “chasing” mechanic. As in: you, the player, are able to chase other characters around the game world.

It seems like GameplayKit would be a good fit for this because it features an agent/goal/behavior system and one of the included behaviors is a goal to “flee” from another agent. I spent a long time looking at the AgentsCatalog sample code that Apple provided and attempted to translate the FleeScene into Swift. This resulted in the following:

The little orange dot follows your touch and the big blue dots flee from the orange dot. At first they just fled right off the screen, so I set up a SpriteKit edge loop to contain them.

Herein lies the problem: All of the dots “stick” to the edge loop instead of bouncing off of it, regardless of how fast they’re moving. They also fail to bounce off of each other. They’ll push each other around a bit, but there’s no bouncing. I have a feeling this has to do with the mismatch between SpriteKit’s physics system and GameplayKit’s agent system, but I don’t know how to fix it.

In the delegate method “agentWillUpdate,” I update the agent’s position to match the sprite’s position. In “agentDidUpdate,” I do the opposite. That’s…probably not right? I have no idea. It’s probably worth noting that I’m not using the Entity-Component system…I just have SKSpriteNodes that own GKAgent2Ds.

Anyway, somebody needs to write a tutorial re: GameplayKit and physics. Please and thank you!

I just submitted my first request for an expedited app review…does that mean I’m a real developer now? :P

I somehow managed to royally screw up the build settings for my project so that my watch extension 1) was not properly linking to my framework and 2) had an incorrect runtime search path. In other words, it was lookin’ for frameworks where there aren’t any. Sometimes I feel like Xcode’s build settings are like playing a game of Lights Out for the first time. With only a beginner’s understanding, it feels like I’m just flipping switches until everything works. Except in this case, everything seemed like it was working and I was able to upload to the store…only to find out that I broke the main functionality of my app: it’s ability to run on the Apple Watch. /facepalm

Of course, this will all be irrelevant when iOS 9 and watchOS 2 are released, because my watch app won’t depend on a shared framework in order to access the data store. It will have its own data store. So far, I’ve really enjoyed messing around with the new features in iOS 9 and watchOS 2, particularly SKSafariViewController and UIStackViews. I’ve also enjoyed attempting to answer people’s questions about WatchKit on Stack Overflow, even though I hardly know what I’m doing myself. All of this has been such a great learning experience and I’m already anxious to move into some new territory, such as learning how to fetch information from websites.