- UI implementation has more caveats on touch devices than it does with a controller. You have to worry about overlapping buttons, for instance, or what happens when a dialog should block out some UI elements but not others. There's nothing hard here, but there are details that need addressing.
- Although it's a little daunting going from a memory managed language (C#) to one which isn't (C++ + Objective-C), a carefully coded framework can insulate you from most dynamic memory allocations. I have a lot of containers and low level framework code that ensures that my actual game contains naked dynamic allocation in only one place. Of course, the framework is doing a fair bit of allocation under the hood, but I don't ever see that.
- You really can't make any assumptions about how the iPhone emulator runs compared to the device. Surprisingly, sometimes the emulator will actually run *slower* than the device even though the machine I'm using is considerably more powerful. Regular device testing is essential.
- Regular device testing is imperative to suss out memory concerns. The iPhone runs out of memory a lot faster than you think. Even a simple Match 3 game can have memory concerns. An unfortunate reality of developing for the device, I'm afraid.
- I really should have created a good texture atlasing system, because doing it by hand is a *pain.* Texture atlasing is pretty essential, because iPhone textures must be powers of two, but like I said above, you really have to watch your memory and thus conserve as much as you can. I've seen some decent greedy algorithms laying around that would honestly probably do a better job than my manual atlasing. Didn't have to worry about this with XBLIG.
- Users really, really do not seem to like the "in-app upgrade to full version" model that was made available when in-app purchases were introduced for iPhone. Looking over the app store, I see a ton of comments accusing developers of false advertising because the game is labeled as "free" even though only a trial portion is actually free. The market seems to expect a Lite version in those instances. This is the reverse of XBLIG, where an upgradeable trial is a requirement.
- The "Universal App" is non ideal. It unnecessarily bloats iPhone games. Same goes with retina support. There are better ways.
- It's quite honestly shocking that I can use achievements & leaderboards on the iPhone and not on XBLIG - why is *Apple* paving the way for indies here? But at the same time, I do love the XBLIG avatar integration. Avatars would've been a good thing to add to the XBLIG version of this game that I just, well, didn't.
- I don't like Objective-C or XCode. I'm not going to talk about why here, and I really have no interest in debating the points; XCode is a poor substitute for Visual Studio, and I find myself avoiding Objective-C and instead writing most of my game in C++ (which may not be great since XCode and the Instruments tools don't always play nice with C++). On the plus side, my inclination toward C++ will hopefully make porting to the Android - using the NDK - easier down the line.
- I sure do hope ExEn gets funded so that I can use one language between several platforms. I already have a C# version of Word Duelist for XBLIG, but it's not mobile friendly and quite honestly the code base is a mess. The only way it will ever see WP7 is if Microsoft at some point provides a C++ path so I can take the much nicer mobile version and port it over. Wishful thinking.
That's all for now. The Word Duelist port is nearly finished - it has every feature the XBLIG version does (except sound right now), so I'm just spending my time polishing and putting in additions (ie: achievements). I expect in about a week's time I'll be able to put it up for review.
Let's hope it makes more than $12, which is what my last indie game has made in the app store. ^^