At WeeWorld we just released our latest iOS game, Match Mee, and I’m delighted to announce it’s our first app written using Adobe AIR. This is quite a departure for us as previously we’ve exclusively written native apps. However, given the continual improvements to the AIR SDK and the fact that Match Mee required the use of a vector rendered, it just made more sense to use our Flash expertise. Plus it puts us in a very nice position where we can relatively quickly push out an Android port when the time comes.
Match Mee’s a universal app (iPhone, iPad & iPod touch) and although Apple announced the iPhone 5 shortly before we were due to release, we managed to squeeze in support for the new resolution at the last minute. A few native extensions were also written in-house to provide support for Flurry Analytics and various ad networks. Additionally, Game Center, Facebook integration, and app rating support was provided by Milkman Games who also gave excellent support to iron out a few minor issues we were seeing on legacy hardware.
I can’t over emphasise how important Flash’s vector renderer was for us in this project. The game randomly generates WeeMee’s of varying sizes from a pool of over 200 assets. The combined size of all this vector information was just over one megabyte and, of course, scaled perfectly across the various resolutions supported across the full range of iOS devices. Keeping the file size down using a bitmap-based solution would have been very difficult.
If you have an iOS device then please take Match Mee for a spin (it’s free) and let me know what you think. At its core is a simple and fun game mechanic that’s very easy to pick up but pretty damn hard to put down.
Hopefully we’ll use Adobe AIR again for future apps as it seems to be picking up some momentum as a mobile development platform.
Oh and if you’ve got a minute to spare then jump over to our Facebook page and give MatchMee a like. Thanks!
Congrats, very nice game and great performance too. It looks like all the Mees are rendered as vectors, even though they’re pretty complex shapes. Doesn’t that reduce performance? Or is that only the case when animating them? In general, when would you recommend vectors vs. “cache as bitmap” vs. “export as bitmap”? Looks like you got the best of both worlds: small filesize AND smooth performance.
Hi Mutlu. All the Wee Mees are constructed from a library of vector assets. However, before they are displayed within the level, we convert each to a bitmap. Essentially, the vector representations for each Wee Mee never makes it onto the display list, only the bitmap representations do. The initial generation and construction of the vector representations do take a few hundred milliseconds to perform, but we’re careful to do this between levels so as not to affect the frame rate during play. So as you said, this gives us small file sizes AND smooth performance.
We needed to be able to scale our WeeMees across a large number of screen resolutions without any loss in fidelity, which meant that using vectors was the obvious choice. Of course, the fact that we didn’t have to animate the WeeMees during the level made this a viable option. For many of our other graphics assets we used bitmaps to help maximise performance. It’s all really a careful balancing act.
Regarding ‘cache as bitmap’. It makes a lot of sense to use it when working with vector artwork that doesn’t need to animate (or at least not that often). However, if there’s animation involved then cache as bitmap will seriously reduce performance as each frame of your animation will have to be rasterized and copied to memory somewhere.
Great work on the game! Tried it out and gave it a 5-star review 😉
Overall, this is a highly polished game and you guys really maximized the potential of this otherwise simple gameplay mechanic. Looking forward to your next one.
Hi Christopher, thanks for the response. I assumed the WeeMees were vectors, because they look aliased. This may be a stupid question, but why convert them to bitmaps at all? They’re not even animated.
For my project, I’m using stage.quality=low to boost performance, but that’s also why all vectors look aliased. For some assets that’s ok, but for others it’s not. So for important assets (like a logo), I use “export as bitmap”. Same performance, but smooth, anti-aliased edges. I wonder if that’s possible when you’re converting vectors programmatically on-the-fly, as you mentioned earlier.
Also, on a related issue, say I’m using a very large vector graphic, which is also animating across the stage. It’s a very simple vector (just a box), so obviously it wouldn’t take up much memory, whereas the bitmap version of it would consume quite a bit of memory, since it’s so large. To get the best performance, would you recommend leaving it as a vector, or converting it to bitmap?
Before I got into making games, using vectors was always the obvious choice. But now I’m not so sure anymore. I always thought that vectors were much easier to process, unless it’s an extremely complex vector drawing. But when it comes to mobile dev, apparently bitmaps are better, not sure why though…
Hi Mutlu. We also use low stage quality, which is why we convert the vector WeeMees to bitmap. By using BitmapData.drawWithQuality() we are able to render the vector WeeMees at a higher quality independent of the stage.
As for the performance benefits of a simple vector vs. a large bitmap. While bitmaps nearly almost always have an edge over vectors, in the case of a very simplistic shape, such as a rectangle, the vector might just have the edge. Or at the very least there will probably be no noticeable performance difference between the two. Of course, you might also need to take into consideration the rendering pipeline you are using since vector rendering times are different depending on whether you are using the CPU or GPU. In such situations however you really should profile your code and see which is fastest. Adobe’s new profiling tool, Scout, should be able to help you with this.
It’s really a balancing act when it comes to mobile. The GPUs on mobile devices are excellent at blitting pixels to the screen. They can chomp through bitmap data like there’s no tomorrow. They aren’t so good at the type of complex shapes that Flash’s vector render uses however. In saying that though, excessive use of bitmaps can hog memory and ultimately cripple your app. Unfortunately there’s no right or wrong answer when it comes to what to use. It really does depend on the app you are trying to create. Although generally bitmaps are faster, which is why Adobe are placing a lot of focus on the excellent Starling framework.
Thanks Christopher, those are some good tips. I used Xcode Instruments, but either I’m not using it correctly, or it’s not very helpful. I haven’t tried Scout, but will definitely look into it now.
I have been using bitmaps for most of my assets, but I’ve noticed that some of them perform much better as vectors. So I’m trying to get a better understanding of when to use vectors vs. bitmaps. I don’t have a rule of thumb yet, so it’s mostly just trial and error for now.
Anyway, thanks again for your tips. There are not many people writing about Flash for mobile dev, so it’s been very helpful.