• entries
25
39
• views
46905

# Porting Word Duelist & Thoughts on iPhone Dev

1063 views

I've currently been working on porting my Xbox Live Indie Game Word Duelist to the iPhone (and potentially the Android). Here are some unfiltered thoughts while I've been going through the process:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. The "Universal App" is non ideal. It unnecessarily bloats iPhone games. Same goes with retina support. There are better ways.
8. 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.
9. 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.
10. 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. ^^ ## 8 Comments ## Recommended Comments Interesting observations. I tend to agree with most of them. Especially how shockingly slow the Simulator can be compared to the device, particularly when testing fairly intense OpenGL ES stuff; even if you run the Simulator in non-Retina mode. (In Retina mode it is almost unusable at times!) The only places I disagree with you are on C++ and Xcode. (Also not trying to start a debate here - honestly. ) I work exclusively in C++, with a tiny Objective-C wrapper around my code base, and have zero problems with Instruments and C++. For really intensive profiling I still tend to fall back to Shark though. And I think the Xcode / Visual Studio debate really comes down to which you are used to - or started using first, of the two. I've spent a long time with both VS and Xcode (on both large and small projects) - and my personal feeling is exactly 180 degrees opposed to yours. Did you really only make$12 on your last Indie title? That hurts man.

Regarding #2: You could have always kept with C# if you wanted by using MonoTouch and GL which is another option to consider if you prefer writing code in sharp.

Regarding #3: Note that the iOS simulator is a software renderer which is why you will see such brutal performance when compared to a device. It only gets worse when working with the iPad resolution and GLES2

Regarding #4: Memory allowance is really dependant on the device type. There is a very low memory barrier of 24MB when working on the 3G or earlier, but this was lifted for the 3GS and newer devices. Memory management is still important even with the restrictions lifted (i.e. on the iPad you can allocate 70-100MB before you get the low memory warning 3 kill) but there are also various alternatives such as using mmap() if you want to stream/load textures, etc.

Regarding #9: I used to absolutely hate XCode back in the day, but eventually I got used to it and now with version 4 it is much better. Your current opinion is most likely due to the old "I hate what is unfamiliar" and once you get used to it you won't have any problems. Now I'm not claiming it is better than VS or anything like that, just that for building iOS applications it is quite usable and I really don't see what would be missing. Not to mention getting an LLVM backend and a compiler that supports standards including C99, much of C++0x, etc.

scratt:
Shark isn't available on iOS 4. They just... turned it off (?!) The Instruments profiler is sufficient though. What I was more thinking of were the memory tracking tools (like Leaks).

Thanks Saruman. To further respond to some of your points:

#2: MonoTouch has always been at the back of my mind, but \$400 is a bit pricey for me right now. I hadn't considered coupling it with GL, though, which is a good idea.

#3: Thanks! I should've realized it was a software renderer but didn't.

#9: I've been using XCode for about a year, so while I wouldn't call myself an expert, I'm comfortable enough with it to work with it. To give an indication of a few of the things I've found lacking: it hangs/crashes on me an obscene amount, the debugger is pretty unstable and often won't let me inspect certain objects, the intellisense is erratic at best, and the 'Find All' is *super* slow in a big codebase. I haven't tried version 4 yet, but I've heard it's an improvement. I can function with the environment, and I might even like it better than Eclipse, but I've had much nicer experiences with VS.

I use both XCode and VS and I must say I really like XCode better. The only thing I don't like is how the windows are all over the place. I prefer how VS has tabs but that might be because I'm relatively new to OSX.

PS Check out [url="http://headsoft.com.au/index.php?category=texpack"]Texture Packer[/url] for creating texture atalases. It's been a very handy tool for our game.

I second the Texture Packer recommendation. We purchased licenses for it and it has saved us a bunch of time not having to build the tool in-house, it is well maintained and always updated (including some nice updates today!)

Actually the Texture Packer I wrote is free.

Oops my bad I only saw the name but didn't check the link! I was referring to [url="http://www.texturepacker.com"]TexturePacker.com[/url] which we decided to use so we wouldn't have to build a tool and it supported the dithering we wanted for the png textures we want loaded as 16bpp.

Thanks for the recommendations guys.

Saruman: I tried out Texture Packer. Is there a way to get it to take a larger set of textures and generate multiple atlases? In the free version it looks like you have to hand-manage all that - preferable for the places where I want to keep a close eye on the atlases to group like images, but a bit of a pain if I want to throw a bunch of general purpose images together and let the packer sort out what to do. At the very least, a project organization system would be nice. Maybe the pro version has those?

Headkaze: I haven't tried yours yet because my primary dev environment these days is a Mac. Does it support command-line operation? That'd be super useful for creating a one-click build step.

## Create an account

Register a new account

• ### What is your GameDev Story?

In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.