Talking iOS Apps

Summary

The most long-term client relationship I've had was with Yann le Coroller from Tayasui. When the number of titles is concerned, most of my published work also comes from this collaboration. The apps in question aren't exactly games but more like toys. Each app has a character (usually a cute one), that responds to touching in various ways, and most importantly, repeats back whatever the user says. Each also has some kind of extra functionality.

List of Titles

• The Mouth
• Talking Carla (small contributions)
• Talking Carl iPad
• Pat the Talking Cat
• Talking Air Penguin
• Mr Poo

Technologies Used

• Unity Pro, iOS addon
• iPhone, iPad
• prime31 plugins: inApp Purchases, Social Networking, Game Center
• 2D Toolkit plugin (GUI)
• Megafiers plugin
• Playmaker FMS plugin (finite state machines)
• Unity Asset Server

iTunes Connect

I've already discussed the quirks of mobile devices in an earlier entry, but this was the first time I got familiar with Apple's publishing and sandbox testing system: iTunes Connect.

Strangely enough, publishing an app turned out to be fairly streamlined, as long as you make sure your application information and info.plist contents are correct. However, they seem to have gone the extra mile to make testing network-based features, such as inApp Purchases, as awkward as possible. I'm still not sure why I needed to create a fake app, publish it and reject it just to test whether you can indeed go through the puchasing sequence in your app.

Playmaker FSM

We used many plugins to speed things up, and one of them was Playmaker FSM, that allows building finite state machines. Basically, it lets you create program logic by connecting boxes with lines. You then attach scripts to the boxes to determine what the program does while it's in that state.

I found this system kind of interesting. It brings a nice, intuitive high-level structure to the program flow: each FSM is always in one state and one state only. You'd usually stay in one state for multiple frames, as opposed to the usual Unity program flow where the Update method and the like are called every frame for every object and the logic branches there, only to return to the Update method next frame. Also, if you wrote scripts for Playmaker, you'd have to think in terms of activities, not actors. You'd consider how the activity would start, what would be done every frame, and on what conditions would it end and what would be done next. These activities often ended up quite modular and reusable, though not always: sometimes I had to write a script for a simple equation used only once.

I'm not convinced it's going to replace conventional scripting, though: my eventual impression was that it suits situations where there isn't a lot happening simultaneously, and where the sequence of tasks doesn't branch too much. Otherwise the FSMs tended to become bloated. It's also hard to avoid copypasting similar states just because you need them in two different parts of the tree. However, the approach lets non-programmers participate more directly in creating program logic, so it definately has its place in projects like this.