How Touchgram is Developed — Backwards

The summary of how Touchgram is developed is simple:

1. Write playable experiences (like a games programmer)
2. Add encoding of supporting data
3. Add a user interface

I’m posting this explanation because it’s something that gets referred to often in conversation in person and online.

In more detail, it goes like this. At each point, I often discard things or just make notes and leave it to percolate in the back of my mind.

1. Think up weird idea, often prompted by podcasts or tweets
2. Decide if the idea fits the main philosophy of Touchgram & is it something people could create or customise, if made into a template?
3. Rough out a version done purely in code. Often this is 2D games programming in Apple’s Swift language, using SpriteKit.
4. Convert the rough working code to Touchgram features. Inside Touchgram are about 20,000 lines of code that are basically a higher-level game engine on top of SpriteKit. (There’s nearly another 20,000 lines of code in the user interface)
5. Make the new features able to be encoded & decoded so they can be delivered in a message. A lot of design work goes into optimal encoding of them so the common cases take up almost no space and are decoded quickly. (eg: specifying layout relative to a corner may take only one byte).
6. Build a full demo Touchgram, still in code. It’s added to our…