Both my own siblings and my wife’s siblings have had a Christmas present exchange for the past couple of years and although the gifts are never extravagant, we always try to make them thoughtful. This year we thought it might be fun to give our siblings a choice of which present they wanted. We thought of making a card with the various options printed on it but then I came up with the idea of making a custom app that could serve the same purpose.

But I didn’t want it to simply be a card analog. It would have to take advantage of some of the unique features of iOS and do things that a normal card could not. Maybe we could somehow sneak it on to their iPads without them even knowing and surprise them with it! I was really excited about the idea and so I immediately sat down and started cranking it out. Thus, Present.app was born.

The User Experience

We decided to call the app simply “Present”. After toying around with various ideas for what the app experience should be like, we settled on this:

• A local notification goes off at 9:00AM PST December 25th, 2012. The message comes up as “Present. To: (sibling + spouse names)“.
• Opening the notification launches the app and the recipient is presented with an image of a present and a message that reads “Shake to Open“.
• As they shake the iPad they hear noises of something rustling around inside like a real box. Curiously though, nothing else happens.
• They continue to shake the iPad and after a little while they hear a crashing sound and glass shattering. Further shaking produces sounds of broken glass jostling around.
• The message “Oops… I meant ‘Touch to Open’” is displayed and they are then allowed to proceed to the present choice screen.
• The recipiant is allowed to pick one of the four displayed presents. They can come back to this screen and examine any of the four choices anytime they want.
• Touching one of the choices brings them to a screen with a funny internet video related to the present they selected and a little quip from us.

Development

Development of Present.app was very quick and dirty. Almost everything hard-coded, nothing modular, no error handling and we only authored it for iPads. The app would only run on iOS 6 devices and also was developed with ARC turned on. To get things done I basically picked the technologies that minimized development time. I used Audio Services to play the sounds, MPMoviePlayer to play the videos and looked for the UIEventSubtypeMotionShake event to detect shaking (which isn’t a very reliable event by the way, but it was good enough). I was able to reuse the app and give it to both to a sibling and sibling-in-law by just changing the name of who the present was for in two places. All told, I spent about 8 hours developing the app (most of which was creating the art and rummaging through Soundtrack Pro looking for sound effects). One of these days it might be neat to productize this idea somehow and publish it in the App Store but that will have to wait for the time being.

Deployment

Making the app itself was enjoyable, but getting it installed on the target iPads without the recipients knowing and making sure it remained undiscovered was probably the most fun. This specific app is never going to see a public release and so using the App Store as a distribution method is out of the question. Apple is notorious for making it really difficult to get apps onto iOS devices without using the App Store (and for security reasons, rightly so). I was going to have to get some alone time with the iPads hooked up to my laptop, mark them for ‘Development Use‘, add their UUIDs to my provisioning profile and build/sign/run the app on their device. This would get it to install on their device and upon first launch, the Christmas morning local notification would register. I then needed to kill the app, disconnect the iPad from my laptop, hide the app somewhere in their Springboard where they wouldn’t notice and get it returned to them none the wiser.

I enlisted my dad and my father-in-law to help with the social engineering required to get a hold of the devices and was able to nonchalantly install the app right in front of them without tipping anybody off as to what I was doing. After prepping my development environment, the actual technical process of getting the app installed only took about 2 minutes. What took significant time was waiting for the right moment to go for it. People’s attention needed to be in just the right places at just the right times.

Execution

I knew from the beginning that in all likelihood the recipients would not be near their iPads at the exact moment that the notification went off. I still thought it would be a fun experience to try for it though. I was able to get one sibling to actually use their iPad when it went off but they weren’t watching at the moment and it got lost with all the other messages in notification center. We eventually just told them to check notification center and then they discovered it and were able to enjoy the gift.

I actually think the most fun was earlier in the morning when we told them that their present was going to “go off” at 9:00AM. That produced all kinds of fun guesses and searches around the house for the mystery present. Both the recipients loved it and both of them ended up picking the iTunes credit option. It was a lot of fun to come up with the idea for Present.app and execute it. I had better start brainstorming now what I can do to one-up it next year

It is always fun to try and guess what Apple is going to do next. You can guarantee that there will always be surprises and sure bets, letdowns and magical moments. The Apple rumor sites do a decent job of soliciting leaks, reading between the lines and making educated conjecture. As a developer, I often like to take a good look at where Apple’s technology is right now and make logical extrapolations as to where things are headed. Oftentimes, when Apple announces some new feature or technology it seems obvious in retrospect if we had only connected the dots. Based on 2011′s release schedule, it is a fair bet to say that Apple is going to announce iOS 6 at WWDC sometime this summer and distribute a developer beta. That means that in the coming months little trickles of information are going to get doled out to the rumor sites about what kind of changes and additions we can expect. Just for fun, I wanted to get my own predictions out in the open before any of that started. Here is my very developer-oriented prediction list of what we might be expecting in iOS 6.

UPDATE: WWDC and the iOS 6 beta have come and gone. Some of my predictions now have conclusions. You will notice however that most of the predictions have not yet been updated. That is because there is the potential for Apple to be keeping a few more surprises up their sleeve for the fall when iOS 6 goes GM. Inline below are the results so far.

UPDATE2: iOS 6 GM is here which means that the NDA has lifted! Check down below to see how well I did.

(Miss)  90%

Notification Center API

It seems often that Apple will introduce a new feature or technology, keep it fairly closed off from developer access for a cycle and then release an API for it after they learn a little more about how people really use it and work out many of the initial kinks in the system. Notification Center seems very ripe for this kind of API access. Apple has had a full release cycle to gather user reactions and think about how to design a really clean API for developers to hook into. Of course 3rd party apps can already get their notifications listed in Notification Center simply by using the same old Notification API that has been around since iOS 3. However, there is currently no way to further customize the display and do anything fancy like the weather or stock widgets. There are already a lot of nice additions and hacks for Notification Center in the jailbreak world (which also it seems is a good indicator of what frameworks and APIs Apple is likely to open up next). This seems like a nice, low-risk, natural progression of a fairly straightforward technology that has already had some time to grow up a bit by itself in the wild.

UPDATE: Hmm, the absence of this is somewhat troubling. A year should be enough time to get a public API for a shipping technology in order. To me this seemed like a no-brainer. I can only assume that for scheduling or other reasons this got bumped to NMOS which means that I am holding on to this prediction for next year when iOS 7 comes out.

(Miss)  80%

Siri API

Siri was the hot new feature of iOS 5 exclusive to the iPhone 4S. For 2 weeks everybody swooned over it and would use it to impress their friends with interesting natural language queries like “Where’s my wife?” or “What’s the volume of 63 grams of barium?“. Then we all hit the limits of what Siri could do and she became just another feature. Like Notification Center, Siri has had a full release cycle for Apple to study user response and nail down the user experience. It is time now to unleash the real potential that Siri promised us and allow developers to hook into it.

If generalized into two broad categories, Siri can accomplish two different kinds of tasks. First, she can answer questions by querying a web service like Yelp, Wolfram Alpha, etc… Secondly, she can perform simple device-local application tasks like create reminders, create calendar items, call phone numbers and send messages. It seems like Apple would want to vet any sort of web service that all Siri users could potentially smash with traffic and so the more likely route of opening up Siri would probably lie in attaching APIs to performing simple actions or application local queries. Imagine if you could ask your turn-by-turn direction app for directions with your voice instead of typing addresses or if you could tell your stock trading program to perform certain actions by voice (that could lead to some hilarious headlines, just be sure to always listen to Siri’s confirmation first). This kind of an API seems like it would be fairly difficult to design correctly and would probably require more of the developer than something like Notification Center. I expect that at a minimum, Apple will initially have a few cookie cutter commands where developers can plug in their own simple verbs and nouns. “Siri, compose tweet: ‘had cereal for breakfast today’“. “Siri, how many (insert virtual game currency here) do I have?“. Developers can instantly leverage Apple’s voice recognition tech and give their users access to all the information and tasks that their applications offer. This seems like the natural progression for where Siri has to go next if she is going to keep distinguishing herself from competing assistant programs. Much like the advent of the App Store itself, it seems like Apple is poised to spark another app revolution which will cement its platform by harnessing the power of it’s developers once again.

UPDATE: Likewise I feel that the omission of a Siri API is quite puzzling. There was a ton of welcome improvement to Siri over the course of the year. However, I feel like there is a gold mine of untapped developer value just waiting for Apple to harvest it with a Siri API. Again, this advancement is too powerful and too obvious to not be coming sometime and so I am also going to hold on to this prediction for iOS 7 as well.

(Miss)  65%

Full Bluetooth/30-pin API

Both users and developers alike have been clamoring for a public API to the 30-pin connector and Bluetooth stack for years. Apple does have an official MFi program that hardware developers can sign up for, but they have to purchase high-priced decryption chips from Apple for every peripheral they build and pay significant licensing fees. For years it seemed like it was in Apple’s best interest to keep a very tight quality control over the kinds of peripherals 3rd parties could produce for iOS hardware, but with devices like the 60beat GamePad (and to a minor extent the Square Card Reader) which side-step Apple’s lockout by going through the microphone input in the headphone jack, it is clear that the bar for developing hardware peripherals needs to be lowered. Incidentally, I have a friend who is currently developing an iOS peripheral using audio input over Bluetooth and software signal processing to avoid paying the licensing fees and integrating the decryption chip.

After taking a closer look at iOS 5, it appears that Apple is slowly heading in a more open direction in this regard with the addition of the CoreBluetooth.framework. It is currently limited to interfacing only with BTLE (Bluetooth Low Energy) devices though. Now that iOS devices are unarguably mainstream and the iOS peripheral market has had a fair amount of time to mature and settle, it might be time for Apple to open up these ports for general license-free use by any developer. There is a huge demand for iOS compatible game controllers right now as evidenced by the 60beat GamePad, iCade, iControlPad and Atari Arcade. It would be really interesting to see what kinds of great controller options would come out of the woodwork if it were more economically attractive to develop iOS hardware peripherals. This kind of freedom for the communications ports would be extremely convenient in conjunction with my next prediction…

UPDATE: For a while there during the iOS 6 beta it looked as though this one might actually come to pass. With iOS 6 came the integration of the External Accessory Framework into the iOS SDK. This is the framework that participants in the expensive “Made For iPod” (MFi) program would use to interact with their 30-pin or Bluetooth devices. The fact that it was being pulled into the mainline SDK was an indicator to many (myself included) that Apple was finally going to ditch the need for encryption and open their hardware interfaces up to the masses (the fact that BTLE and the CoreBluetooth.framework had no such requirement was further evidence in support of this assertion). Alas, on further investigation it appears that this was not the case. By all accounts you still need to sign up for the MFi program, pay a large licensing fee and buy expensive encryption chips if you want to use < Bluetooth 4.0, the 30-pin port or the new Lightning connector. Fortunately as time marches onward Bluetooth 4.0 will become move prevalent and the BTLE chips will lower in price thus further lessening Apple's need to opening up these 'legacy' ports.

(Miss)  75%

Apple TV SDK

Apple pretty much fell into the Gaming industry by complete accident. Nobody, not even Apple themselves could have foreseen the kind of massive takeover of iOS devices in the portable market, especially because they weren’t even trying to attack that market in the first place. The Apple TV has long been publicly declared as a “hobby” for Apple and long been looked at suspiciously as a Trojan Horse by analysts and pundits for…something…. The reason it currently exists is to get the iTunes Music and Movie Stores into your living room. Why not the App Store as well?

Granted, there are significant development challenges for developers in porting apps to the Apple TV, such as dealing with one more UI idiom in addition to the phone and pad ones they have to target right now. Developers would obviously have to live without multi-touch, accelerometer and microphone input (if targeting the Apple TV 2, rumors suggest that the Apple TV 3 may headline Siri as a feature). They would also need to deal with potentially small storage space (8GB for the Apple TV 2). The iOS developer community has proven itself to be a very quick responder to new hardware and has great feature adoption rates, as evidenced by the second app gold rush sparked by the original iPad. Obvious applications would include games (duh), more applications that blur the line between books and movies, home automation/security app ports and data visualization software hooked up to analytics services and the like (it seems like every other startup office I visit these days has a computer in a public place hooked up to some data visualization of sales or hits or something). The sheer financial incentives that accompany a high position in the App Store sales charts all but guarantee massive developer adoption of any potential future Apple TV SDK. One can speculate as to whether Apple will maintain a separate iOS branch just for the Apple TV as it currently does and later unify it (much like it did with the iPad), or if it is going to be merged in with iOS 6 right out of the gate. Again, I don’t think Apple is going to initially position the Apple TV as a gaming console (it can’t compete with the horsepower of the entrenched players at the moment), but one shouldn’t underestimate the power of yearly hardware upgrades and a voracious and resourceful developer community. Should the Xbox, Playstation and Wii start getting worried?

UPDATE: I guess that iOS 6 was not necessarily the right place for an Apple TV SDK to debut. After all, the iPad and iPhone versions of iOS were disjoint for almost a year before they merged. It does make a measure of sense for Apple to simplify and just concentrate on mainline iOS and then afterward work on pushing out a refined Apple TV SDK during a normally dry spell for Apple releases in the coming year. Once again, this is just money on the table for Apple. Thousands of iOS developers are clamoring to port their games and other apps over to the Apple TV. I still believe this is coming but I am now less certain on the timeframe.

(Miss)  70%

AirPlay Mirroring Plus

The collection of technologies and protocols now dubbed “AirPlay” has had quite an interesting technical history. First there was AirTunes, with which you could send encrypted audio to authorized devices like the AirPort Express from iTunes. Then came a separate technology called AirPlay Video, which allows iTunes and iOS devices to send unencrypted video/audio to the Apple TV 2. Then last summer we got AirPlay Mirroring, which is yet another additional, separate technology that sends encrypted video/audio of whatever is on iOS device to the Apple TV 2.

AirPlay Mirroring has had a huge impact on presentation technology (I use it at an event I founded called the Startup Grind). It has even more unlocked potential as clearly evidenced by existence of Reflection and AirParrot and by the recently revealed AirPlay Mirroring capability in OS X Mountain Lion. I predict that at some point Apple will add iOS-iOS device mirroring capabilities as well. The idea of sharing your device screen with somebody else near you doesn’t seem extremely interesting until you add something like multicasting into the mix. Imagine a conference talk or a board meeting where the speaker uses their iPad to show the audience slides or some other sort of demonstration, and instead of cranking your neck over to get a glimpse of a poorly lit, off angle projection screen, you simply follow along on your own iPad. This seems like a no-brainer considering all Apple has to do is port the AirPlay mirroring receiver app over over to mainline iOS from the Apple TV 2 and add multicasting support. Now that the AirPlay Mirroring private key has been extracted and the protocol reverse engineered, if Apple doesn’t do it, some other enterprising developer will.

UPDATE: This did not happen. In fact, no AirPlay Mirroring enhancements came at all! If Apple hasn’t foreseen the possibilities for more flexible mirroring or hasn’t seen fit to give mirroring any enhancements of any kind then I am not so sure that it is going to arrive in the future either. I am not going to hold my breath for this one now but hope to eventually be pleasantly surprised.

(Split)  70%

Mobile Payments

The NFC rumor got a lot of play last year when people threw around iPhone 5 predictions, but we haven’t really heard much from it lately. NFC/RFID reading hardware in phones has had somewhat of a hard time gaining adoption despite a lot of press and attention put on its potential uses. In the United States there are only a handful of Android phones currently sporting NFC/RFID hardware at the moment, which is somewhat surprising considering that Android handset makers are constantly looking for ways to distinguish themselves. Google seems to be making a fairly large play for the use of the technology in payments although adoption doesn’t appear to be significant right now.

It appears that Apple is going to throw their weight behind BTLE for the kinds of things that NFC is typically used for. They are already shipping BTLE hardware in the iPhone 4S and, as mentioned above, they have already provided the CoreBluetooth API for it in iOS 5. Apple could potentially “just walk in” to the payments ball game with two gigantic assets already in place. First, they have a huge guaranteed, uniform hardware install base to entice developers and partners and secondly, there are hundreds of millions of credit card accounts in iTunes already hooked up and primed to go. The payments-in-real-life arena seems ripe for disruption as evidenced by the success of such players as Square and the seemingly uncompetitive entrenchment of the few large credit card companies in the US. It only remains to be seen if Apple is even interested in this space at all. Time and time again they have proven that they aren’t going to just jump into the latest buzzword market simply because it is the hot thing right now. That said, mobile payments married to iTunes/iOS seem to make a lot of sense to me, and enough time has passed for Apple to be able to calmly evaluate the arena with a cool head and develop a consistent plan.

UPDATE: Depending on how you interpret the verbiage you could call my prediction either a hit or a miss. I am going to take half credit for this one. Passbook is clearly Apple’s alternative to making a physical swipe or moving your device so that it is proximate to a sensor in order to get something accomplished. It is being used for tickets, coupons, boarding passes and all sorts of other things that people envisioned NFC to be suited for. Clearly Passbook is much less secure than having an end-to-end cryptographically-based system but it also has much less friction to adoption and much better hardware support. With that in mind, in regards to functionality I am going to call my prediction a ‘hit‘. However, because you can’t use it to actually perform a financial transaction and my prediction was much more closely tied with the particulars of the hardware implementation I am going to have to also call my prediction a ‘miss‘.

What Won’t be Coming:

Here are some things I think would be great if they made it into iOS 6 but I wouldn’t put any money on it:

(Hit)

Game Center 3rd Party Authentication

This is something I had hoped Apple would include in their gaming social network from the get-go (a year ago I wrote about how this is the number one problem holding back Game Center adoption). For games that require accounts or some sort of establishment of identity, being able to develop a game that authenticates against Game Center user accounts would be a godsend. Unless you are a large development house that has already created secure user account management systems, it is a huge pain to manage users, and an even bigger pain for your customers when you ask them to do yet another song and dance through a signup process. Apple could very easily integrate a 3rd party authentication system into Game Center, but I have heard through the grapevine that there is no internal interest in doing so. Instead they have provided us with Apple-hosted turn-based gaming functionality, which alleviates some of the problems developers have had, but it has some severe limitations and doesn’t address entire swaths of game genres like realtime action games.

UPDATE: As I predicted, Game Center continues to go nowhere fast. Apple likes to tout Game Center’s account statistics during keynotes but it is all for naught if it is nothing more than an achievements system (Game Center leaderboards are meaningless because of complete lack of security). I would really love to see the day when Apple makes Game Center so attractive that game developers cannot resist developing for it. But the fact that rival services have continued to grow and prosper even after Game Center hit the scene is evidence enough that it doesn’t really offer anything special. Also Apple, get rid of the poker table aesthetic. Nobody likes it.

(Miss)

Deep Facebook Integration

By all accounts (from the rumor sites) this one almost happened. Technically there is nothing stopping it. iOS 5 already brought us deep Twitter integration and from what it looks like from the outside, most of the work was already done (see Ping etc…). Instead things got bogged down on the business side of things as they often do, and after some heavy Jobs vs. Zuckerberg meetings it appears like it was no longer meant to be. That is not to say that it can’t happen in the future, which is why some people have high hopes that it will arrive in iOS 6. I however feel that as time as passed, distances have grown instead of shrunk. These days Facebook seems to be the girl everybody wants to dance with, and it seems every day they and Microsoft continue to get cozier with each other. I wouldn’t preclude this from happening sometime in the future, but iOS 6? Too soon.

UPDATE: Well, looks like I just got this one wrong. Facebook integration at a similar level to iOS 5 Twitter integration was announced at the WWDC Keynote. By all accounts the technical work had already been completed over a year ago and it was just a matter of people on one, the other or both sides swallowing their pride and flipping the switch.

Your Predictions

What do you think? Do I have it right? Any iOS 6 predictions of your own? Let me know in the comments.

UPDATE WRAPUP: Well, it looks like my prediction hit rate (1.5/8) was pretty dismal. This isn’t going to stop me from prognosticating about future editions of iOS though. On the upside, I feel like I have just given Apple their tent-pole feature list to start working on for iOS 7. You’re welcome

Here’s demo of the new 60beat GamePad with my friend Mike‘s game Caster HD. I added support to both Caster/Caster HD and the update has been submitted to the App Store for approval. It shouldn’t be too long before the update actually hits the App Store. (UPDATE: Both updates are now live on the App Store!)

In the video I demo the controls starting with the cursor. The Mac/Win/Linux version of Caster has game pad support for the in-game cursor and so it was easiest to just hook into that. You don’t need to worry about switching between touch and game pad controls. Caster has no on-screen control overlays and both control styles will work concurrently so you just plug in and go! No setting switch required.

After getting into the game I demonstrate the settings for the camera movement which is controlled by the right analog stick. The start button will pause the game and give you access to the options menu. There you can tweak the camera sensitivity and invert the axis if you want.

A lot of the other controls are doubled up so you can use whichever you prefer. The left analog stick or the directional pad control walking movement. Button 3 or R2 will jump. Button 4 or the R1 will fire. Buttons 1, 2 and L2 will rotate through the different weapons. By holding down L1 you initiate a dash when moving.

(While I’ve got you here, be sure to check out my new 3D physics shooter Invader Zurp if you haven’t already. It is a ton of fun and there is nothing else like in on the App Store. )

What Is It?

The .DS_Store is a Finder metadata file created primarily by Mac OS X’s Finder.app. Because of the dot (“.”) prefix it is typically not visible in many file browsers and most Mac OS X users are probably not aware of it. It is regularly created when the Finder accesses filesystem directories. It contains directory information about icon locations, view options, silkscreen configuration and the like. The functionality that it provides is moderately useful, but becoming less and less relevant over time. In any case, a long time ago the horrible decision was made to store that Finder metadata in an actual file (.DS_Store) in the filesystem within the relevant directory. We have been paying for it ever since. Over time more and more metadata relating to files and the filesystem has been added to Mac OS X, but thankfully those have been stored in saner places (extended attributes, etc). For the time being though .DS_Store is still here with us and still causing trouble. What’s so harmful about the file you might ask?

Cross-OS Cleanliness

The .DS_Store file is only useful if you are accessing the filesystem with the Finder. What if you aren’t using the Finder though? What if you aren’t even using Mac OS X at all? At best the files then become wasted space that is ignored. At worst they are horrible clutter that dirties up your file browsing experience. It doesn’t take much online searching to find countless forum posts from Windows users asking what these files are or the innumerable removal scripts that Linux users have authored to clean them from their directories. On Mac OS X, if you insert a USB flash drive, mount a network volume or zip up a directory to give to a friend, more likely than not, .DS_Store files have hopped on for the ride. Whoever has to interact with those directories next that doesn’t use a Mac is going to have to deal with those in some way even if it just having to consciously ignore them. Eventually a power-user facing flag was added that would disable .DS_Store file creation on network volumes (“defaults write com.apple.desktopservices DSDontWriteNetworkStores true“) which was a good move. There are still however, plenty of reasons why Mac OS X users hate having them on their own systems.

Source Control Gunk

All the programmers in the room, raise your hand if you have ever added “.DS_Store” to your .gitignore file or equivalent source control ignore configuration? What’s that? That guy in the back who didn’t raise his hand? Oh, he was sleeping…there’s his hand. The contents of the .DS_Store file are always changing and so even if you did happen to check the .DS_Store files into your repository (furthering it’s unholy propagation) it is always going to be showing up as a changed file and gunking up your commits with changes and data that have absolutely nothing at all to do with your code. I have to wonder how many global man hours have been wasted in configuring source repos to ignore these files or cleaning them out of the repos after someone YET AGAIN added them in their latest commit.

Permissions Playtime

Because the .DS_Store file is so inconspicuous and usually innocuous, a lot of the time we simply forget it is there. Unfortunately when doing things like mass permission changes and the like, the .DS_Store file will unintentionally come along for the ride. Suppose you tighten up the permissions on a directory that has a .DS_Store in it. After a while you decide to go through an manually clean it or lower the permission levels on the contents again. You had better remember that you also raised the permissions on the .DS_Store file as well or you might be puzzled why you don’t have permission to delete the directory or why the Finder isn’t saving your directory options. It is no show stopper. Any competent command line monkey can figure it out and fix it. But again, the few minutes it takes to fix it should never have been necessary. Technology is supposed to save time, not destroy it.

So What Do We Do About It?

Those were just three examples that I thought of off the top of my head. Leave your own .DS_Store horror/annoyance stories in the comments and I will add any more that don’t generally fall under one of those three examples. So they are a time consuming annoyance, easy enough to whine about. But what to DO about it? The other day I again ranted on twitter about them and it was suggested that maybe someone could write a daemon that would listen to fsevents and nuke them on creation. I kept thinking that the evil should really be stopped at the source. The Finder. I wondered aloud what it would take to patch the Finder so that it wouldn’t even create them anymore at all. I decided that the creation of .DS_Store files needed to be stopped. Like Jack Ryan in Patriot Games I decided that “I will make it my mission in life”. For an afternoon at least. So in the interest of cleanliness I came up with a dirty hack. I call it DeathToDSStore. I have documented my investigation and development process below.

Who’s Behind This!? I Want A Name!

I initially suspected that it was solely the Finder.app that was responsible for .DS_Store creation. After a little investigation it appeared like that was pretty much true but there might be other things out there that also create them. My first lead was the DSDontWriteNetworkStores setting that causes the Finder to not create the files on network mounts. I needed to find out where the code that interacted with that setting lives. Examining /System/Library/CoreServices/Finder.app with strings came up empty. It must be in a framework somewhere. Poking around /System/Library/PrivateFrameworks revealed the culprit: DesktopServicesPriv.framework. Ok so, .DS_Store authoring functionality is very likely in this framework. Clients of this framework in /System/Library/CoreServices include Dock.app, FileSyncAgent.app, TimeMachine.menu, backupd and the Finder.app. For the time being I was just going to concentrate on the main offender.

AKA Property Stores

I started perusing DesktopServicesPriv.framework‘s symbols using nm (piped into c++filt) to see what kind of things I had to work with. Hmm, FSVolumeInfo::ShouldWriteNetworkPropertyStores()? That sounds like it could be directly connected to DSDontWriteNetworkStores. Perusing around a little more it appears like .DS_Store files are called “Property Stores” internally. There is even a C++ HFSPlusPropertyStore class present. I had just found what I was looking for. Time to start poking at things.

I Wanna Be A mach_star

I pulled out rentzsch‘s awesome mach_star injection/overriding code and started overriding various routines in that class. For some reason I wasn’t able to use dlsym() to get the address of any C++ member functions. I tried all sorts of permutations of the mangled name that nm was giving me for stuff but nothing seemed to work. “Well, I guess I could always just plug the raw address in.” I thought. So I used vmmap Finder to get the base address of where the DesktopServicesPriv.framework‘s __TEXT section was residing in memory. If ASLR (Address Space Layout Randomization) is in play then this value can be different every launch. (EDIT UPDATE: comex reminded me about the _dyld family of routines and so this is now obtained manually at runtime instead.)

nm gave me the offsets of the functions I was targeting and so it was simple enough to just add them together to get the location of the functions I needed to override. It would obviously be a lot cleaner to be able to determine the address from within the binary at runtime but I couldn’t convince dlsym to give me anything and this was working (unfortunately it adds an external dependencies on Apple’s Developer Tools (nm) and BSD.pkg(c++filt)).

Gotcha!

After a bit of trial and error I found that overriding HFSPlusPropertyStore::FlushChanges() with a function that simply did nothing, successfully prevented the creation of .DS_Store files on both Snow Leopard and Lion. On first inspection it doesn’t appear that overriding this function has any unintended behaviors and appears to accomplish the objective of halting .DS_Store creation quite nicely! Or about as nicely as you can when you are doing something like live patching the Finder.

(Side note: I noticed that I am not the only one using mach_star to live patch the Finder. The Dropbox daemon is doing it as well every time the Finder launches)

There’s An App For That

So I packaged my work up into an app (you can also run it through the command line under sudo with the “-silent” option) and published the source on github. In the near future I am going to add a launchd option so that it will run every time the user logs in or any time the Finder is run (EDIT UPDATE: The option to install a Launch Agent has now been added). Now that I have a solution I am going to put my money where my mouth is and start running without .DS_Store file creation full time. Hopefully I wont run into any major issues (I will report them here if I do) and I am pretty sure that I wont miss their functionality (At least by having new ones created. Existing disk images and CDs with custom layouts will still be read just fine). So far the result is pretty positive! Is this safe? Eh…. The safety/cleanliness/forward compatibility of patching OS components has been discussed and debated ad nauseum. You probably already understand the risks involved. Things look pretty stable but I make no promises. Go ahead and try out the DeathToDSStore.app or build your own from source if you want and let me know how it works out for you. Remember that you need to have the Developer Tools installed, BSD.pkg installed and admin authorization. Death to .DS_Store!

The Story So Far…

So to recap the original blog post a bit, it was the middle of the summer (2011) and I had been working my brains out on Cannonade for the previous 6 months. I was a little discouraged at that point because progress wasn’t coming quite as quickly as I had hoped. Reception from my testers (just friends and family at that point) hadn’t been as positive as I had wanted either. I still had a very clear vision of what I wanted Cannonade to be and still believed that there is a ton of untapped potential for multiplayer-only games on iOS. But there was only so much I that could do as a one-man team and testing a multiplayer game can be quite time consuming. I took the family on vacation in early July and was able to step away from things for a while. It was then that I got an idea for a single player experience that distilled the core gameplay mechanic of Cannonade down to it’s essence. Thus Invader Zurp was born. Within two weeks I had modularized the Cannonade game engine, re-written the graphics sub-system in OpenGL ES 2.0 and had a working prototype. And it was fun! I found myself on very long “testing” sessions playing even after I had verified my fixes. I seeded the first alpha version in early September and wrote the introductory blog post. Then began the journey of finishing the game and kicking the darn thing out the door.

Feedback Lesson 1: Make Written Feedback Easy

I got a lot of really great feedback from my testers all along the way. I learned two very valuable things about feedback through my experiences with Invader Zurp. The first was that you really need to make it dumb easy for people to give you WRITTEN feedback. A lot of my friends would give me awesome feedback when I saw them in person but for the life of me I wouldn’t be able to remember it even the next day. I got on the beta list for the TestFlight SDK and start integrating various features into Invader Zurp. One of the most important functionality that I saw in the SDK was a one-line (of code) feedback dialog. I added an obnoxious red “Feedback” button into the app and made it pervasive except when the user was actively playing the game. This button brought up the TestFlight feedback dialog where they could write to their hearts content. The floodgates opened. I started getting a lot of feedback. Most of it was pretty short, just stuff people had noticed in the moment. But it was those little things that people would not have remembered to tell me later that really helped raise the polish level in a lot of places.

Feedback Lesson 2: Take Individual Opinions As Part Of A Whole

The second important thing I learned about feedback was that any individual person’s opinion needs to be treated as a part of a larger set of feedback. I had friends tell me very confidently that things needed to be this way or that way. My friends are really smart and know what they are talking about and so I would start to worry that maybe I was on the wrong track and I really should change course (sometimes drastically). However, once I took that individual nugget of feedback and put it up against all the other feedback I was getting I was able to remove my more emotional reactions to it and look things more objectively. This meant that even if my friends were right and I was wrong, I could deal with it in a better way by understanding how it fit in to the entire picture of collective user reaction. I could see patterns emerge across multiple testers that indicated that a particular piece was either very wrong or very right. I wasn’t doing game design by committee though. I still took minority advice sometimes when I felt it was the right thing to do and ultimately I had to veto some majority feedback when I truly felt that it didn’t mesh with the overlying game vision. I was willing to try anything though and I did in fact implement a lot of crazy feedback that my testers gave me just so that I could see what it felt like in action. An idea on paper and the same idea in implementation are often completely different things. I mean, just look at the “it’s just a big iPod Touch” iPad.

Building A Game For Me

The overall gameplay concept of Invader Zurp was originally inspired a lot by Ikaruga. Ikaruga is a game that you can completely play through in 25 minutes. But the REAL game is not simply completing the levels from start to finish, but rather it’s mastering the intricate chaining system and racking up huge scores. I thought that this was a really deep gameplay mechanic. One that really wouldn’t be appreciated unless the player invested some time into it. However, this deeper gameplay and Ikaruga as a whole is not regarded as being a very casual friendly game (casual gaming being what the iOS App Store seems to reward a lot). Treasure (the developer) is well known for catering towards the more “hardcore” elements in gaming. I initially designed Invader Zurp in a similar manner to Ikaruga in that you could easily burn through all 100 waves of structures in about 20 minutes. The REAL game and the mechanic that would add substantive depth would exist in a system that rewards you for making tricky mid-air block hits. Anyone could shoot the blocks and destroy the towers but it took real skill to hit things in such a way that the blocks would pop up into the air and you needed to be lighting fast in order to target them before they hit the ground. Doing so would reward the player with a lot of points. Coupled with this is an automatic upgrading system that directly ties to your score, the maximum number of missiles that you have to shoot, how fast the missiles regenerate after being shot, how fast your shields regenerate and how powerful your missiles are. The idea was to have a nice smooth power ramp up. You start out with only a few, slowly regenerating missiles and as you get more points, you gradually upgrade to become an uber powerful, unstoppable destruction machine. The thing is that you need to make sure you are scoring a lot of points so that your upgrade curve stays ahead of the difficulty curve. The waves coming at you steadily increase in turret number and rate of fire and so if you don’t make sure to rack up tons of points along the way you will eventually not be able to keep up with the onslaught. Learning the point-heavy, mid-air shot skill is really important because it compounds on itself very quickly. The more points you get, the more upgrades. The more upgrades you get, the higher potential for you to be able to milk points and stay in the game. At this point in development the player always started the game with the same upgrade levels every time. Because of this you could very clearly observe your own skill increase by seeing how far you got before death or how high a score you were able to rack up before finishing the game. It was a very pure game concept that I enjoyed quite thoroughly.

Building A Game For The Masses

However, like Ikaruga, this mechanic’s hardcore simplicity didn’t appeal to everyone. Many people thought it was too simple and they said they didn’t feel like they had a reason to play it again once they got a little taste of it. They kept wanting me to put in more stuff and add more to complexity to the gameplay. I didn’t want to complicate things up though. I wanted to keep things “Fruit Ninja” simple and I felt that every added gameplay intricacy would need to be baked in for a long time to see if it really worked in the game (idea vs implementation). I had a long talk with my friend Reed Olsen about it one day. We talked a lot about what kind of games are successful right now on the App Store and what kinds of psychology they were tapping into to breed their success. I didn’t want to simply follow a pattern and become a “me-too” game, but there were many clear examples of gaming hooks that were extremely effective in getting people to play and continue playing that I couldn’t ignore. I thought long and hard about these and tried to find a way to integrate some without losing the gameplay essence I had already refined. After a long period of agonizing I decided to test out an in-game currency system. This added a very valuable psychological hook of giving the player the feeling of progress every time they played the game. Regardless of whether they did poorly or totally rocked it, their total accrued money would still go up. They would be farther than they were last time. They would feel accomplishment. I was wary of adding this element to the game mainly because I didn’t want grinding to ultimately overcome skill and I was also keenly aware that in-game currency systems (especially the ways in which they are implemented in freemium games) are distasteful to many in the gaming community right now. But I decided that I was going to be willing to give anything a try. I allowed the player to purchase upgrades outside of the gameplay that would increase the base level that their in-game upgrade levels started at. This meant that I had to adjust the difficulty curve up so that the player would need to save currency up and purchase upgrades to (realistically) be able to finish the game. No longer would a very skilled player be able to just waltz in and finish the game with just the initial upgrade levels. They would need to put in some time and work to get accomplish that goal. In practice I found that this worked fairly well at providing a hook for the less “hardcore” players and didn’t detract as much from the pure gameplay mechanic as I thought it would. I eventually had to bump down the maximum missile regeneration level because once the player had max’d out all their upgrade levels they basically became an unstoppable block-killing machine. Skill kind of got thrown out the window for the high end players at that point. After making some small adjustments to the max upgrade levels I found a nice sweet spot that made the player feel like through their efforts they had grown into a powerful, planet ravaging machine but still left room for the high end players to compete against each other with their pure skill.

Further Motivation

Another gameplay addition I developed grew out of a conversation with my friend Mike Smith. Again, he wanted some additional gameplay element to increase the complexity and I was resistant. But in the course of our chat we came up with an idea that I thought meshed really well with the existing mechanic and wasn’t confusing or overwhelming. The idea was suggested that I hide three special blocks in every wave and tie some sort of bonus to hitting all of them. This was really appealing to me because it was super easy to implement and addressed a major complaint that a lot of people had up to that point which was that they always felt like they were out of missiles. I decided to put three shiny gold blocks into every wave and give the player a full missile reload if they were able to hit all three. This meant that now there was now an opportunity for a full missile reload at pretty much every moment. The player now had to balance whether they were going to take the risk of spending ammo to go after the gold blocks or write them off. It was a great improvement on the gameplay and also allowed for another progress-based psychological hook. I could keep track of how many blocks the player got in each wave and record those in a running stats menu outside of gameplay. That way the player can see the progress they are making towards getting all the gold blocks in every wave. This kind of optional “collect” mechanic is used to great effect in tons of games these days (in my mind most notably in the Mario franchise). I then layered on an additional mechanic of keeping track of how long the player can maintain getting all three blocks in the waves in a row and giving a bonus missile damage multiplier as their streak increases. This seemed like a very easy element to simply layer on that would add depth without adding complexity and confusion. I then did a similar thing with enemy turret destruction streaks and started keeping track of those stats as well. The feeling of having your accomplishments recorded can be pretty powerful and very motivating to people with completionist mindsets which brings me to the next element I layered on.

Achievement Unlocked: Make 50 Achievements, Ship Game

Achievements are a no-brainer. They are super easy to implement and you get a lot of psychological mileage out of them. I found that coming up with crazy achievements and writing their humorous descriptions was some of the most fun I had during the development of Cannonade and Invader Zurp. It is well documented that having a lot of easy early game achievements can do a lot to keep people invested in your game and motivate them to keep playing. Coming up with a nice curve of achievements for the beginners, intermediate, advanced and insane was pretty fun and actually not that hard. I didn’t need to worry about giving any skill level too many. I could just make whatever achievement popped into my head. I loved coming up with really random ones that players would accidentally run into during the course of the game. “Huh? What was that achievement? Eh whatever, cool!“. I was really proud of a lot of the locked/unlocked achievement descriptions that I came up with. Unfortunately Game Center has visually small spaces in their app to display those descriptions and so anything more than just a basic description gets truncated. So when perusing achievements, be sure to do it in the in-game menu where you can view the “Director’s Cut” achievement descriptions.

Future Plans

I had a lot of other cool ideas that I wanted to implement in Invader Zurp but I knew that I needed to pare things down and determine my exact 1.0 feature set or else I would never get around to shipping (“Sometimes you just need to shoot the engineers and ship the darn thing“). I had a lot of ideas like:

• In-App purchase to allow people to buy in-app currency (kind of a given these days on the App Store).
• I also wanted to rip out and incorporate the Cannonade level editor (what I used to make all the levels) into Invader Zurp so that the players could design and ulpoad their own building designs and have them trickle down into the game. It would be really cool to see a different set of towers every day, each with a little “Designed by GamerX” credit under their announcement title.
• I want to have alternate missile effect sets like psychedelic rocket contrails or themed missile explosions like a burst of hearts when missiles explode for Valentine’s day.
• I wanted to have a lot of analytics hooks and an App Store release “Feedback” button that the players could use to interact with me.
• I also wanted more Zurp character art, iCloud save game support, Game Center avatars, Twitter integration and a lot of other little things.

Many of these will find their way into a future update. Just need to prioritize them correctly.

Submission Deathmarch

About a month before release I was talking to my friend Mason Sheffield about what I felt I needed for a 1.0 release and how far off I thought I was. He challenged me to get 1.0 on to the App Store by Christmas (2011 ). I thought was a really unrealistic target. I looked at what still needed to be done and saw an unsurmountable mountain. But December 25/26th is the biggest day of the year for the App Store and it was also ahead of my own in-head release target. I decided that this challenge was just the kind of motivation I needed and it put a fire under me. The App Store review team was going to be shutting down on December 22nd and I thought that during this season there would be a lot of other developers also trying to make the deadline in order to get on to the App Store before Christmas. I conservatively estimated that a review would take two weeks and so that put my submission deadline at December 8th. So for the last month of 1.0 development I worked like crazy and started aggressively cutting things right and left. About two weeks before the deadline I hit a moment when I realized “Hey, this thing is actually coming together! I might actually make it!”. I was quickly heading toward the light at the end of the tunnel. I was seeding every two or three days (much faster than my usual goal of once a week) and felt like I was running a marathon. Soon enough though the day of truth arrived. I actually decided then to give myself two extra days to finalize a couple of things and squash as many bugs as I could before submission. On December 10th I finally submitted Invader Zurp version 1.0 to the App Store. It was amazing how many truly egregious bugs I found on the day of submission and was thankfully able to squash them right before submission. I figured that I would probably get approved (fingers crossed) just in time for December 25th and that would give me enough time to make a website, gameplay trailer and find reviewers to give promo codes to. To my surprise, only four days later the iTunes Connect app on my phone buzzes to tell me that Invader Zurp is “In Review” and only 40 minutes later it changed to “Ready For Sale”. This was a nice surprise and actually caught me a little off guard! So now that the game is finally for sale the time has come to start promoting it and preparing for the first update. I definitely want to be in the league of other great games that have quality content/features in every update. I want my users know that when they get an update from me it’s going to be something new and good to explore. Aright, enough writing, back to work!

(Interesting side note: I found out during app validation that you can’t submit an app with an unresolvable symlink in it. I was doing this intentionally though. Email me if you want to know why.)

Aright it’s here! Invader Zurp, the project I have worked so hard on for the last 5 months is now for sale on the App Store! I want to thank all my wonderful testers for all their time they put into playing it and even more for the thoughtful and productive feedback that they so lavishly furnished on me. I couldn’t have done it without you!

Check out the gameplay trailer here:

Work, work… More work?

So a basic description of the gameplay in Invader Zurp is that you, the player are flying in 1st person over a planet’s surface towards structures made up of variously shaped and sized blocks. The player taps the screen to fire missiles at the structures which then explode. This explosion destroys some blocks and sends other blocks flying through the air. There are also some special blocks (called turrets) that shoot missiles back at the player which must be intercepted or else the player takes damage. In the next couple of sections I am going to step through the procedures that I go through in order to make sure that my physics simulation work is as small as possible while still giving the player a good gameplay experience.

Less Stuff, Less Work

First things first. The player is constantly moving forward and “blocky” structures are being brought into the simulation at the horizon regularly as the player plays the game. Obviously more blocks means more work and so minimizing the amount of blocks in the simulation is imperative. Because the direction the player is moving never changes, it only seems natural that once a block has moved behind the player’s viewpoint that it should be removed from the simulation. In this game a block behind the player can no longer be interacted with (usually) and so it is simple enough to just remove them from the simulation. I also thought about removing blocks once they have left the player’s view frustum but I decided that I should still keep those blocks in play in case a missile has already targeted it and is currently homing in on it. The player might be really disappointed to have successfully targeted a special bonus block only to have it lifted from their grasp as it leaves their view. In addition to removing blocks behind the player viewpoint I also remove blocks that have been pushed too far into the background.

Shh… Don’t move. It’s CPU Load’s Based On Movement

Another very basic performance concept in physics simulation is that if objects are not moving (or are moving so slowly as to not be perceived as moving) we can skip over a large part of the simulation for them. You can set a movement threshold that causes blocks to become inactive from a lot of the simulation once their velocity falls below it. This functionality is built in to Bullet (btRigidBody::setSleepingThresholds()) and most other physics engines. In Invader Zurp I chose to bump up that threshold higher than normal so that blocks would become inactive sooner. I also set the friction coefficients of the blocks and the ground such that blocks would slide around less and fall under the inactivity threshold quicker (btRigidBody::setFriction()). Because the player is constantly moving there is not a lot of perceived difference to the player between a block that is sliding around a little bit and one that is stationary. Thus, aggressively changing these values didn’t result in a very different experience for the player. Also, when new block structures are added to the simulation, every block is always initially flagged as inactive (btRigidBody::setActivationState(ISLAND_SLEEPING)). This is because in Invader Zurp it is assumed that the structures are all initially standing still. This does have the interesting side effect of allowing for structurally unsound buildings to appear to be holding up. Blocks can be suspended in air and blocks can also occupy the same space at the same time indefinitely. Of course the instant a moving block collides with it the entire thing falls apart but I decided that the charm of having interesting (but structurally insufficient or conflicting) building designs outweighed the realistic depiction of the structure.

Accuracy Is In The Eye Of The Beholder

There is an interesting problem in traditional realtime physics simulation called “tunneling” which I describe in depth in another blog post. In that post I describe some techniques to deal with the problem of relatively small objects tunneling through others and different ways of dealing with it. In Invader Zurp the fastest moving objects are (usually) the missiles that the player shoots at the oncoming structures and incoming enemy missiles. The missiles travel quite quickly (especially when they are completely leveled up) and at a normal simulation granularity they can easily tunnel through the blocks. I considered special-casing them and simulating their movement and collision myself but I eventually decided to have them remain as Bullet simulation objects and keep (most) collision detection for them inside the physics engine. Taking some cues from the solution I came up with for Cannonade (“Convex Sweep Collision Based Time Slicing“, discussed in the tunneling blog post) I decided to start from there. To ensure that the missiles do not tunnel through blocks even at their high rate of speed I decided to increase the granularity of the simulation high enough so that they could not completely tunnel through an individual block. Because doing so increases the needed computational power substantially, I had to make sure that I only did it when absolutely necessary. So every frame I would spend some CPU cycles performing convex sweep collision queries (btCollisionWorld::convexSweepTest) for the fast moving missiles to see if they are likely to hit a block within the next simulation frame. If it seems like a collision is likely then I see what the fastest velocity is of any of the missiles that will likely hit a block during that frame. I use that velocity to determine just how much more accuracy (and in turn granularity) my simulation needs to ensure that the fastest moving missile will not tunnel. The cost of performing convex sweep collision queries is expensive but in the long run they save much more time by making sure that the simulation runs at lower accuracy level when missiles aren’t going to tunnel. Those convex sweep queries can still get quit expensive though. I started looking at ways to avoid performing it. I looked very closely at the specifics of the missile’s role and player perception in my game and got an insight. When you tap on the screen an algorithm determines which block or enemy missile you most likely intend to hit with your missile. Your missile is entered into the simulation and undergoes forces that cause it to home into it’s target until either it or it’s target is destroyed. Because of that strong homing force, I noticed that 9X% of the time the only collision that a missile would ever experience in it’s lifetime is one with it’s target. I figured that if I only performed the convex sweep query for a missile when it was getting close to it’s target that I could forego performing a ton of queries when the missiles are not close to their targets or much less when they aren’t even close to any block at all. It is substantially less expensive to simply calculate the straight-line distance between a missile and it’s target and then check if that distance is within a certain threshold. If it was within the threshold only then would I actually perform a convex sweep query to determine if I really did need to increase the simulation granularity. A side effect of this is that occasionally missiles will tunnel through blocks that they are not targeting. In practice though I have only actually noticed this happening two or three times. The computation savings was well worth the compromise in this specific application. I took this optimization one step further and also decided to sort the missiles per frame in order of how close they were to their targets. This meant that the missiles which were more likely to come up with a positive collision as a result of the convex sweep query were examined first. This then meant that a contender for the fastest moving collision during the frame was calculated earlier and thus increased the likelihood of being able to forego convex sweep queries on missiles that had less of a chance (due to their increased distance from their targets) of coming back with a positive collision because they were perhaps moving slower than the missile that we already had determined had collided. All of these optimizations led to a significant performance boost without sacrificing significant user perceived accuracy. Occasionally when there is a lot going on you can see individual frames take longer as the simulation granularity gets spiked but it is usually only for a few individual frames. For the most part, the player taps, sees a missile shoot out towards the structure and then watches it blow up, all with a fairly regular frame rate.

They Are So Small Anyway…

In that same strain of missile collision performance, I devised another slight performance win but it was instead born out of player experience rather than an egregious slowdown. In addition to targeting structural blocks, your missiles can also target the enemy’s defense missiles which are constantly homing in on you. Unfortunately, because of the missile’s speeds relative to their sizes, what would usually happen is that the player’s missile would speed towards the enemy missile very quickly and then violently hover around it for a while before finally colliding with it and exploding them both. This was not a very fun player experience and was also perceived as being a very erratic result. So I decided to pull missile to enemy-missile collision into my own code instead of using the physics engine. So I instead calculate the straight-line distance between the two and when the distance falls below a certain threshold the missile explodes and takes the enemy missile with it. This makes for a much more satisfying player experience. The player sees their missile heading toward it’s target and then both exploding when they appear to intersect. In addition to being a better game experience it saves on collision computation as well. In fact, we can probably say that we don’t need to even compute collision between a player missile and an enemy missile in the physics engine at all! Using collision flags (btBroadphaseProxy::m_collisionFilterMask, btBroadphaseProxy::m_collisionFilterGroup) I separated the missiles into specific groups that would only collide with the ground and blocks. The likelihood that two missiles would collide with each other when out in play area away from the ship was somewhat small (much less have a user even notice that it should have happened but didn’t) and so pulling those objects out of collision computation with each other was significant win. I also found that this was necessary because when the player got to higher levels of the game and started to fire missiles much more rapidly, their own missiles actually WOULD collide with each other (fairly often actually) and explode themselves very quickly after being fired because of the missile density around the area they were being fired out of the ship from. This was also a bad player experience that was fortunately also simply solved by taking the missiles out of collision tests with other missiles.

Modifying Bullet

At one point I experimented with extending Bullet itself to allow for more specialized control over it’s execution. I added some flags to collision bodies that allowed me to selectively control which bodies were fully put through collision detection and contact resolution system. My aim was to lower the hit of increasing the simulation granularity by keeping most of the simulation progressing forward at the rate of one full frame and instead only allowing the speedy missiles that were likely to tunnel undergo multiple sub-frame physics passes. That way the only increased performance hit would be involving the additional physics calculations associated with objects that I had determined were likely to tunnel. This would of course also sacrifice some accuracy because not all of the objects involved in a high granularity collision will be progressing forward like they normally would but the potential performance gain was too high to ignore. I took about a day to investigate this avenue and got things up and running but they didn’t quite work correctly. There were clearly many peripheral effects to my modifications that I did not yet fully understand and so I decided to instead keep Bullet an unmodified black box for Invader Zurp version 1.0 and planned on re-visiting that idea again when I had more time to dig into Bullet’s internals.

Other

Other small things I did to try to milk more performance was to keep my landscape geometry as simple as possible (in the case of Invader Zurp it is just one simple plane). I also read that adding the SOLVER_ENABLE_FRICTION_DIRECTION_CACHING flag to m_solverMode of btContactSolverInfo and lowering the m_numIterations in btContactSolverInfo (I lowered mine down to 2 down from the default 10) you could possibly gain some performance at the cost of simulation accuracy. Because of the quick gameplay pace and constant movement of Invader Zurp I felt that it was fairly tolerable of accuracy loss and so I added those settings in to my configuration. I didn’t do any formal or extensive testing to see if this had any effect but to the naked eye I couldn’t discern any significant performance gain (or loss, or accuracy loss for that matter) and so I decided to leave them in.

Conclusion

Well, that is about all the ones I could remember. I am sure that as time goes on I will be able to figure out more ways to squeeze the most out of Bullet. The grand takeaway is that in your application (especially games) it helps to look at your own specific situation and perform very narrow situation-specific optimizations. Are any of these optimizations applicable in your game/application? Any other ideas on getting more physics bang for your buck? Let me know in the comments.

Write It Down

“No more!” I declared. Nothing gets remembered unless it is written down. Hmm, idea notebook? TextEdit file on the computer? I did the text file thing for a while but I kept forgetting that it was there or didn’t have access to it at the time. No worries… Evolution of the computer to the rescue! Transferred things to Notes.app on the iPhone. Not good. Too jumbled, un-organized, too much information presented in-general. I knew of the million and a half “getting things done”, task management, mind-mapping and brain organization apps/ecosystems out there. But I found most were too general for what I wanted and too heavy. Well, if you want something done…

Version 1.0

I decided that I was going to create a web page where I could dump all my ideas instead. It would sort and organize the ideas so that I could easily review them when I was looking for an idea. I am not a web programmer and so it was kind of fun to learn about the latest in AJAX-ish web technology and poke around a bit with it. I got something up and running within an evening and it actually worked pretty well. No longer was I going to lose those awesome little nuggets of inspiration. I called it “Think Tank“.

Gone Native

Some time passed and I was thinking about how one of these days I should really re-write the Think Tank web page cleanly using modern web standards and methodologies. But then it dawned on me: “You’re a native iOS programmer. Why don’t you do what you do best and implement Think Tank as a native iOS app?” Yea! Then the interface would be nice and fast and I could take advantage of all sorts of iOS goodness as well. What’s more, I could then put it on App Store for others to take advantage of. I set to work and quickly got it up and running. I have been using it myself for about 3 weeks and it just what I wanted. Simple, straightforward and fast. Now when I get an idea I just whip out Think Tank, jot down what is in my head and get back to what I am doing. And now that Think Tank has just been released on the App Store for $0.99 anybody else can take advantage of it now as well.

Above is some footage from the current Invader Zurp alpha (apologies for the bad exposure). As you can see, things have come quite a ways since I released the first video! There are a lot more visual effects, 5 music tracks from Monte ‘Trance’ Emerson, a new gameplay mechanic, an in-game currency system and tons of other little advancements. I must say that I feel like things are progressing quite nicely! I still have a ways to go though and so I am going to continue cranking away with my head down until it is finished.

What are your thoughts on how development is going? Let me know in the comments. Also, a huge thank you to all of my testers who have given me invaluable feedback on all the builds thus far.

As we open up more chapters of the Startup Grind you will be able to access all the information and interactive elements for the events for every new meetup that we get going. More awesome features are in the works so stay tuned!