My first iPhone game 'Bubbly Eyes' has just been published on the iPhone app store.  Here's the link:  

http://itunes.apple.com/us/app/bubbly-eyes/id519511062?ls=1&mt=8

I'll submit the ad supported free version in a couple of weeks.

Thanks to monogame and monotouch!

Got a copy. Great job Omeg! Can you share some more details with us? What did you use for physics engine? What FPS are you getting? Graphics and animations look very smooth - did you end up creating hi-res textures for retina?

Thanks fchild.  I didn't use a physics engine.  Or, in other words, i did a simple one that works for this game.  I didn't measure fps rate, but I'm rendering in sync with the 60 fps.  Even with the higher resolution, higher color depth, I get a really good performance.  Having said this, I must admit I had to do a couple of optimizations for objet pooling and reduced garbage collection.  I used hi-res graphics for retina, but for the larger-than-screen background that's smoothly sliding, I actually didn't use higher resolution image.  I'm glag it's not noticable.  I will use hi-res for all images in the upcoming iPad version.

Btw, I've added your game to the Latest News Section and also the iOS games list.

D.

Good game, Omeg.  I got it and played about an hour today.

I like how your leaderboards and 'next rank' are incorporated into the gameplay.  It keeps the player immersed in 'getting that next rank'.   Biology Battle for the 360 Indie games does this really well.

Couple of questions:

Did you end up using the CADisplayLink for your gameloop timer?

Are you using monogame's implementation of the 'flick' gesture, or did you write your own handler?  I couldn't get a natural feeling experience from flick because the delta it passes is too simplistic. 

If you'd like some unbiased feedback about the game, let me know and we can talk offline.

Yes, I've used the CADDisplayLink (http://monogame.codeplex.com/discussions/351350).  I'm not using gestures.  I handle pressed/moved/released directly.  I encountered some issues and did a post here:  http://monogame.codeplex.com/discussions/351625.  My temporary workaround is non-invasive on the monogame source, and it seems to work pretty good.

I'd appreciate any feedback.

Omeg,

Can you expand on what you did for object pooling and reducing garbage collection?

Thanks.

If you do per frame object creation, it'll cause the GC to kick in frequently and cause a choppy behavior in animation.  In my game, I'm using some linq query operators, and ToList() methods.  I started using a preallocated list instead, and then reused objects that are put to a recycle queue rather than being released.  Simply put, it's something like this:

ObjectPool.Recycle(bubble); // keep the instance around so we don't have to reallocate

when you need a new object:

ObjectPool.Get();

I made an extension method for ToList() that accepts a preallocated list.  So the linq queries now look like this:

(from .....).ToList(prealloc);    // Make sure list will not be reallocated, but instead refilled

I'm wondering if there could be a mode of GC that suspends any collection and just switches a generalized from of object pooling.  So any disposed of object would go into this pool, and any new operation would reuse objects from this pool.

Hi Omeg,

  I just tried to buy your app, but it says it is iOS 5 only? Are you using some specific APIs? I've got an iPod 2nd Gen and they only do iOS 4.x

You may be missing a portion of the market.

D.

Yes it's iOS 5.  The truth is, I just wanted to push the app as quickly as possible to the iPhone rather than enabling backwards compatibility.  That's still something to consider in the near future.  I'm just not sure if I'll be able to find a stable, compatible and performant monotouch, monogame and iOS version.  The platform is really trying to push people into the newest version.  So it might be reasonable to wait for the old version users to upgrade rather than doing the investment for old version.   I'd appreciate any recommendations in this subject.

Since you asked for feedback.....

I gave up trying to support anything earlier than iPhone 3GS.  I was able to get my game running on 3G, but it was a constant battle with memory constraints and performance.  It was a poor user experience overall.   I estimate I'm losing between 5-10% of the market, but it makes my development process so much easier.

I think it's worth mentioning that my game's iPhone version is 32 MB, almost 2.5 times the WP7 version.  Some of this is caused by larger png images, but I believe it's mostly due to native code compilation and inclusion of .NET BCL, monotouch and monogame.  Does anyone have any recommendations to reduce the size?

How much space is your audio taking up?  I converted all of my assets to m4a (aac) for a nice improvement in final app size.

FYI -- If you right-click your compiled ios app in 'finder', you can explore the package and verify exactly what is in there. 

There are some wav files and png files that are pretty large.  But these are the same as wp7 version.  The major difference seems to be in the final executable size which is 17 MB.  I think, this is because of native compilation into one single file.  I'm wondering if it's possible to put only the used parts of the code into the native output, just like C/C++ linker does.

The MonoTouch linker does just include the used code.  Unused code is not linked in to the final executable.

To save some space on textures, you can use 16-bit rather than 32-bit with little to no loss in quality.  I made a custom content pipeline extension for my Windows Phone games and provide it on my blog.  Use the content pipeline extension in your Windows Phone project to build the content, then copy the XNB files to your iOS project to replace the PNG files.

p.s. Is it supposed to be "Bubly Eyes" (missing a 'b') in the title screen and icon?

Yes, I noticed the misspelling after publishing :)  Anyway, I've just submitted wp7 version with the iPhone look and corrected the title to 'Bubbly Eyes'.

Does monotouch linker do this kinda of optimization for .NET libraries as well?  Or does it include all the library code that you reference?

MonoTouch does dead-code elimination when it compiles to native code.  Since all assemblies in the package are compiled to native code, all code with no references should be eliminated.  It should be noted that even just a single reference to one class in an assembly could pull in a huge amount of code depending on what code that class references itself.  So if you have some code that is never executed but references a type in another assembly, it may be pulling in that assembly's code but that code will never be used.  Unfortunately the linker can't know this and has to pull the code in.  For more info on the linker, see the Xamarin linker documentation.

Thanks for link.  I just checked the sizes of other monogames listed.  It looks like mine is overly big (32MB) compared to those (less than 15MB).  I've started thinking I'm doing something really wrong, but I don't know what it is.

It would nice to have the linker generate a report that shows all the code it ended up compiling.  Otherwise, I don't know how to trace down where the 17 MB for the code is coming from.  In the mean time, I'll try to reduce the resource size.