The Story of Stories
Owen Mathews
When I wrote my first story, Pea and Carrot, for tapStory, I started with the text, which came very quickly—less than an hour. Creating the images took longer, but I had those done within a couple weeks. The harder part was building the story itself.
How do I build stories for the app? That answer has changed over time. That first story was laborious. Four years later, the process is considerably easier—it probably takes a quarter of the time, maybe even a tenth. That process will have to continue to improve, because I want to be able to produce new content for the app on a regular basis.
Structure
Stories in tapStory are not very complicated. They are, in essence, just a collection of images (each one representing one of the items in a scene, including images for each block of text), a set of accompanying files that define which parts of each image respond to touch and provide other information about them, and a text file that describes how the scenes are constructed. When I first came up with the structure of a story as the app understands it, I had to create all these text files by hand.
Each scene in a story is laid out on a 1024-by-768 pixel display—the standard screen dimensions of an iPad. Each element in the scene has a number of properties. Among them are position, size, and whether the item responds to touch. (There are other properties as well, but we'll restrict ourselves to these three.) If we wanted to put together the first two scenes of Pea and Carrot, it would look something like this:
* Scene 1
* "Pea Looking Straight"
* Position: (100, 100)
* Size: 100%
* Touchable: Yes
* "Carrot"
* Position: (900, 350)
* Size: 100%
* Touchable: Yes
* "Text: Pea"
* Position: (100, 200)
* Size: 100%
* Touchable: No
* "Text: and"
* Position: (400, 400)
* Size: 100%
* Touchable: No
* "Text: Carrot"
* Position: (700, 60)
* Size: 100%
* Touchable: No
* "Text: Credits"
* Position: (150, 700)
* Size: 100%
* Touchable: No
* Scene 2
* "Pea Looking Right"
* Position: (850, 350)
* Size: 80%
* Touchable: Yes
* "Text: Pea was a pea"
* Position: (300, 350)
* Size: 100%
* Touchable: No
Very Typing, Such Wow
For each scene in Pea and Carrot, I wrote text similar to this, only with quite a bit more information for each item. Just writing it all out took a while. Then, scene by scene, I tested it out in the app. Every scene needed adjustments, because I could only estimate the positions and sizes of the elements without seeing how they would look in the app. So I would make a tweak, re-run the story in the app, decide on more changes, and repeat. Partway through the development, I added a little display on the screen in the app that would indicate the positions of the elements as I dragged them, which reduced the back-and-forth estimation cycle. All the same, the whole process took quite. A. While.
All of Pea and Carrot was assembled in this way. I had enough other work to do that I didn't dedicate any time to improving this process until my next story, My Puppy Has a Puppy. I knew there was no way I could waste so much time on hand-editing the file for each scene.
Automation 101
For My Puppy Has a Puppy, I worked on code that would write this file automatically. With the new system, I could move elements around the scene by hand, and at the press of a button, the app would generate the file for me.
However, the file still needed lots of tweaks by hand. Setting things like touch responsiveness, or how the app transitions between two given scenes (pan, fade or cut), were not handled by the automated system. Also, there was still no way for me to put the elements in the scene in the first place, so I had to make the initial version of the file by hand. It was a start, but there was lots more I could do.
Evolution of a GUI
During the development of the next several stories, I continued my effort to make the story development process smoother. I began building a dedicated interface for editing scenes, independent of the interface that was in the app that would be published to the App Store. In this separate app, I had free reign to create exactly the controls I needed to define how scenes were constructed. I could also bundle all of the images for composing the story with the editing app. Now, without leaving the app, I could create a blank scene, pick its constituent elements from the catalog of all elements, lay them out, and generate the file which described it all.
It was at this point that I realized that what I had created could become a feature in tapStory. That original editing code is, in fact, at the core of the editing interface that's in the app today.
With the knowledge that I was building not just a tool for my own use, but a real feature, as I continued to make more stories and refine tapStory, I also made improvements to the editor. It gained the ability to control all aspects of scene construction, streamline selection of elements for scenes by adding them in bulk rather than one at a time, and make changes like changing the order of scenes and the transitions between them.
Today and the Future
As of tapStory 2.5, the editor in the app has almost as much power as the private story construction app. There are still some features, inappropriately advanced for young users, that will probably never make it into the consumer app. However, I no longer have to develop very much parallel code for my own purposes.
Despite all these advances, though, the process is still entirely dependent on me. I'm the only person who can create the stories, because it relies on a toolchain that includes the unpublished iPad app (which must be run in the simulator—not a device—via Xcode) and a separate Mac app to prepackage the elements and create the touch maps for them. I'm the choke point for the production process, and that can't continue for much longer.
So, this is not the end point. In order to be truly efficient, I need to hand over control of the story production process to others—interns, collaborators (writers and illustrators), and eventually, employees. I plan to create a separate iOS app that builds on the editor functionality but also includes the storage for the images and all the features of the Mac app. Once it's done, I'll have an app I can release on the App Store, or at least distribute in a limited way using TestFlight or enterprise distribution, that will allow anybody to create a story for tapStory and hand it over to me as a completed product.
How long will it take to get there? I have no current timeline, but I'm keenly aware that my limitation for getting new stories into the app will become a problem sooner or later. I'm looking forward to completing the process and relieving myself of the workload, giving the creators of stories full control of their construction for the app, and enabling a much faster pace for producing new stories.