Using a API (that I can’t get mention due to NDA) I’ve set up high score submission and display in the Android version of my free game Meteor Storm.
You can try it out for yourself here: http://market.android.com/details?id=air.com.terrypaton.meteorstorm
And here’s a quick video showing it working on my phone:
Meteor Storm with highscores from Terry Paton on Vimeo.
Hooray! My first game for iOS is now published and downloadable in the Apple iTunes Store. ‘Meteor Storm TP’ is a free game for iPad only that I made using Flash and published using Adobes upcoming AIR 2.7. AIR 2.7 has changed how previous content is compiled to iOS and has DRAMATICALLY sped up performance.
First up, I’ll share a link to the game. If you have an iPad check it out, it’s free and it’s made with Flash ):
Meteor Storm TP – http://itunes.apple.com/au/app/meteorstorm-tp/id439117889?mt=8
So why am I offering the game for free?
Experience has taught me that I need to try out a market/platform before committing too many resources to it, and when there’s money involved your players get a bit more upset by simple errors and oversights. By offering Meteor Storm for free it will give me a chance to experience the development, submission, publishing and then release of a game onto the iOS platform with limited risk.
I had to name the game ‘Meteor Storm TP’ with the extra ‘TP’ (meaning Terry Paton) as the name had already been taken in the Apple iTunes Store.
Here’s a shot of a game running in progress …
How was the process of submitting a game and what tips can I share?
Well to be honest, there was little I needed to do in porting over my existing Android version of Meteor Storm. Just simply resize the game area, the menus and screens and then publish. At the time I submitted, just under a week ago I was using the cmd line to compile my content, and since have gotten access to some of the GUI solutions Adobe are about to offer.
Meteor Storm was already optimised for a mobile platform and uses a ‘blitting’ technique for rendering the game objects to the screen. This meant that publishing the game in CPU mode (rather GPU) allowed the game to perform as I wanted it to. The only other major issue I would bring up is Apples application code signing process. It’s pretty complicated and takes a while to get the hang of, but it works pretty well once you’ve got it worked out. I won’t go into the process as others have blogged about how to get setup.
I do have to say, iPad resolution is pretty large, at 768 x 1024 for vertical format. It’s pretty neat making Flash games at this size.
AIR 2.7? Gimme gimme gimme!
Yes its coming soon, Adobe engineers have done fantastic work in improving the performance over the previous versions and want to make sure the end user gets a great product. It takes beta testing to find the bugs in software, Its fun being on this edge of Flash development, but beta software isn’t typically easy to use and can be buggy. Hopefully my launch of Meteor Storm won’t reveal any new bugs, it’d be great to have it work well 
Questions about rendering methods …
I’ve been asked a lot of questions along the lines of ‘WIll my game run well if it’s using MovieClips’? Or ‘How does this compare to AIR 2.6?’ and a few others. The problem with answering questions like these is the difference in every developers coding methods. There are varied ways to set up your rendering engine for a Flash game, so I feel that any answer to those questions ultimately ends up being ‘You need to try it out’.
The way you handle MovieClips/Bitmaps/Memory is probably different to the way I do, so commenting about performance of them would be limited or take a very long time to cover all the possibilities – none of which I have time to test. My best recommendation would be, get it running well with AIR for Android 2.5/2.6 and it should run perhaps even a little better on iOS. But that is no promise. Ty it out when it comes out, if your techniques don’t work, make them more efficient.
So where to from here?
Well I’m going to be checking out the developer console for monitoring statistics etc, see if any major bugs or issues show themselves.This is new territory for me, so I’ll be keenly watching what happens here, and blog what I can about it.
I’ll be submitting more games to iOS when I can, and I’ll blog about it too.
Meteor Storm is also available to play (for free):
On Android phones: https://market.android.com/details?id=air.com.terrypaton.meteorstorm
And in web browsers: http://www.mochigames.com/game/meteor-storm_v1/
If I were you, I would definitely start preparing an iPad version of your Flash game
Here’s how the game looks in iTunes store in a browser
And on the iPad itself:
It’s been quite a while since I last tried porting one of my Flash games to Apple’s iOS and it was time I tried again. Last time I found it waaaaaay to slow for me to run one of my games unaltered.
This time I used the revised code for Meteor Storm which had been optimised a lot since my last attempts. Initially I tried the game at full res, running as an iPad app, but sadly the performance was too slow. The game uses heavy BitmapData blitting techniques and just didn’t want to run smoothly, it was close, but not anything I would be happy to publish with. So I then decided to reduce the games size down to iPhone 3G/S resolution (320×480) down from it’s original size of 480x800px – which by the way works smoothly on most Android phones. Yay for Flash!
Here’s a video of it running on my v1 iPad, still needs a little work to get the proportions changed to the iPhone screen, but it works and plays smoothly.
Meteor Storm running on iOS from Terry Paton on Vimeo.
I guess I will continue to work on this and submit this to the Apple store, I just need to balance my time as there’s so much other stuff that actually makes money to do. I would have to charge for the App (it’s free on Android and online) in order to justify the effort it takes to get this working. I also doubt that this would turn a profit due to the amount of effort often required to get sales – and my lack of time and a marketing budget … so I’m in no hurry.
The guys over at FGL have partnered with adobe for a competition developing flash games targeted at mobile devices. I’d decided I was going to be a part of this (I’d found out early that the competition was coming) and as you might be able to tell from my blog posts I’m in full swing producing content for it.
You’ll need to be a member of Flash Game License – though it’s free to sign up, and I reccomend you do if you want to make money from your games.
The competition page is here – http://www.flashgamelicense.com/sponsor_pages/adobe/
The forum for the competition is here – http://www.flashgamelicense.com/view_forum.php?forum_id=29
I don’t normally go in for competitions or even awards, but this one grabbed my attention as I’m really interested in the mobile space and the potential that is opening up there. Google have been doing great work in developing their mobile operating system so that it supports third party software and this has allowed adobe to get the flash player (version 10.1) so that it will now play flash content at something resembling desktop performance. Adobe Flash technology is a personal favourite of mine as it allows rapid prototyping and development of just about anything.
With a flash player install base on desktop computers and the rapid upgrade adoption that has been built into the player, this means that my content has been able to be played by 10’s of millions of people. What I’m looking forward to in this next phase of flash distribution, especially on the google devices is the portability of my games so that people can now play them in places and times never before accessible. Some of these instances are when traveling, waiting around, giving the phone to the kids while at a party (seen that a lot lately) and even on the toilet!
Content developed for a mobile device has it’s own particular quirks and reminds me a little of the earlier flash days where optimizing for efficiency and speed was especially important. Mobile devices are typically less than half the speed (or worse) than a desktop, and have a lot less powerful GPU’s (meaning much less powerful graphic rendering). For me personally this has meant exploring ways in which I can optimize the code i use, finding new solutions to adapt old techniques and a much deeper understanding of how to write efficient code.
One of the the major issues with developing for a mobile device is the resolution versus the actual size of the screen. What looks enormous on a desktop machines screen feels just right on my phone, so I’ve learnt a lot about testing the UI before committing to designing it. Buttons need to be about twice the size I typically make them for my normal games and this eats up screen real estate very quickly. At the same time fingers are typically very inaccurate and of various sizes so allowances need to be made that.
So far I have found it very satisfying to see my content running on a phone, being able to play with it, share it and see the people also enjoying what I’ve made. It feels like a much more personal experience to play a game with touch.
From this perspective I can highly recommend that if your a flash game developer you should be at least considering putting time into either porting one of your existing games over, or making something new for this new wave of devices that is coming. These are still very much early days, the markets are young, the devices a little immature and the money making a little uncertain – but the future is huge. Then there are the emerging tablet devices. The experience you gain from making something for this type of environment has invaluable lessons in design, optimization and problem solving – let alone the satisfaction of seeing something work beautifully.
Check it out, you may even win something – I’ve already got 3 entries in
You can view the submissions here – http://www.flashgamelicense.com/sponsor_pages/adobe/submissions.php
Written on my iPad, which needs to be able to run flash. I cannot wait till there is a good android alternative.
After some play testing of my recent game ‘Meteor Storm’ it was was obvious the game was way too easy and didn’t really provide any challenge.
Originally I was hard coding in the amount of Meteors per level and the minimum/maximum amount of time between meteors being spawned. This allows for nice customisation but I also needed to make a version of the game that can play with a potentially endless amount of levels – but getting progressively harder till it was practically impossible.
So I worked out some basic calculations for each of the values so that based on the level the amount of meteors and the timing of them would exponentially increase. I haven’t done this very often before so I started from scratch this time and came up with the following – represented by coloured lines. Although the numeric values are not shown here you’ll get the idea.
Going from left to right and the bottom of the graph equalling zero. The Black line represents the amount of meteors, Blue the minimum amount of time between meteors and Red the maximum amount of time between between meteors.
What’s neat about these type of calculations is that the graph slope can easily be adjusted to make the progression through the levels smoother or tougher.
Also as a note I am using this in conjunction with code I had written about in this post – http://pixelpaton.com/?p=2502 – where I adjust the ‘flow’ of enemies during the level. The code I did today is more about global difficulty, and the code from the previous post is about the details of difficulty within the level.
Here’s the code that generates todays graph, although it looks like a lot, most of it’s for actually drawing …
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 | import flash.display.BitmapData; import flash.display.Bitmap; import flash.geom.Point; import flash.display.Shape; var shape:Shape = new Shape(); var _bmpd:BitmapData = new BitmapData(550,400,false,0xeeeeee); var _bmp:Bitmap = new Bitmap(_bmpd); addChild(_bmp); addChild(shape); shape.graphics.lineStyle(1,0); var _p1:Point = new Point(); var _p2:Point = new Point(); var _p3:Point = new Point(); for (var _x:int = 1; _x<20; _x+=1) { // display the amount of meteors graph var factor:Number = _x * _x / .2; var _factorPercent:Number = factor / 30; var _minMeteors:Number = 10; var _y:int = 200 - factor / 10; var px:Number = _x * 10; _bmpd.setPixel(px,_y,0); if (_x > 1) { shape.graphics.lineStyle(1,0); shape.graphics.moveTo(px,_y); shape.graphics.lineTo(_p1.x,_p1.y); } _p1.x = px; _p1.y = _y; // display the minimum time _y = 200 - 20 / _x; _bmpd.setPixel(px,_y,0x0000FF); if (_x > 1) { shape.graphics.lineStyle(1,0x0000FF); shape.graphics.moveTo(px,_y); shape.graphics.lineTo(_p2.x,_p2.y); } _p2.x = px; _p2.y = _y; // display the maximum time _y = 200-(5+100/_x); _bmpd.setPixel(px,_y,0xFF0000); if (_x > 1) { shape.graphics.lineStyle(1,0xFF0000); shape.graphics.moveTo(px,_y); shape.graphics.lineTo(_p3.x,_p3.y); } _p3.x = px; _p3.y = _y; } |
