GamingYourWay - iPhone

Whoring ourselves again

Squize — Sat, 05 Jun 2010 22:38:53 GMT

We don't often pimp other peoples stuff. It's not that we don't like other peoples stuff, we just don't like other people.

But for the second time we're going to explain to you why you should be buying one of Marks games for your iDevice, and hopefully he'll finally return the negatives and we won't have to do this again.

Actually rather than explain, a couple of screen shots and then a quick bit of blurb should do it, so roll up roll up, for Lil Racerz < App Store link, it's nice to have a warning as it'll open iTunes and that's a real pain when you're not expecting it.

I was lucky enough to play it in beta form, and it rocked even way back then, but the final package has had so much more love and content thrown at it. A racing game either feels right, or it doesn't, and Lil Racerz does. Ignore the fact that I'm credited in it, or that we got sent promo codes ( Although after I'd already bought it, cheers for that. Tight ) it really is worth a couple of quid.

If you should buy it after reading this blog and think it sucks, then no worries, I can give you Marks address and you can direct your hate mail directly to him, so it's a win win.

< Update, Matthew linked to a youTube clip in the comments, so it more than makes sense to shove it in here, http://www.youtube.com/watch?v=CJxfXGz7ARI >

Squize.

Zap and some Flash CS5/iPhone tips

Squize — Fri, 26 Feb 2010 13:32:12 GMT

I hate using such a search engine friendly title to a blog post, we normally bask in the willfully obscure, but as this may actually contain something of interest as opposed to the usual random words I figured it was worth at least trying to vaguely flag it up.

Let's start with a big caveat. I developed Zap using the beta version(s) of Flash CS5, and due to it's very nature it's not the final finished product. That means a couple of things, firstly that the launch version is going to be better than the one I used, the Flash team are really breaking their necks with the iPhone exporter and just doing great work. Secondly as it was beta software things are pretty fluid. I really honestly doubt that there are going to be any major changes so soon to release, but some of these tips may not be valid on release.
One last thing, being on the beta program means being under a NDA. In terms of this post it means I won't be going into technical things, performance or new API's etc. Think of this more as a primer which can hopefully give you a little head start than a sneak peek at what's under the hood.

Ok, the main thing is eeking out as much performance as you can.

* Vectors / Drawing API / Gradients. No, no and no. We're bitmaps all the way baby.
* BlendModes. Think more about burning the effect you want onto the bitmap itself.
* MovieClips. Save them for intros and title screens, avoid them in-game, as you just can't cache them efficiently so you're hitting the slower vector plotter.
* Text. It's slow enough when running in a swf. Time to code yourself a text plotter using bitmaps ( Like Movieclips, for in-game anyway. Top and Tails performance is never really a big issue )
* CacheAsBitmap. He's going to be your new best friend, love him and cherish him, as he'll give you much better performance ( There is a new cache command too, but NDA and all that ).
Some things to keep in mind, setting sprite.visible=false wipes the cache, so when you use sprite.visible=true again you're forcing a re-cache. Altering the alpha property also forces a re-cache ( As does scale etc. All the things I'm sure you're aware of any way ). One thing I didn't know before starting on Zap was that if you holder.removeChild(sprite) the cache is lost too, and that the cache only kicks in when the displayObject is first added to the stage.
In terms of how that hit my workflow, I had to change up and create all my sprites / bitmaps in each classes constructor and add them to the stage hidden off to the side.
When you first launch an app on the iPhone the "boot" picture appears straight away. Make sure that the very first thing you do is have a copy of that same image sitting topmost on your stage. Then you can call all your constructors and create all your display assets hidden under that cover, and when everything is in place you just transition that screen out. It hides any nasty stutters whilst the game makes everything it needs ( Using Zap as an example, the boot pic is our logo with "loading" text displayed on it, with the same image minus the loading text in the game itself, so the change from bootpic to game is pretty seamless ).
* Every pixel counts. Only plot what you need to, abuse the swf background colour as much as you can to save plotting.
* Pooling. Hopefully this is something you're used to doing anyway, but it's really vital when exporting to iPhone. During the constructor stage of my game I created all the pools too. Just using a simple Vector list, or linked lists. Pooling is such a simple thing to do and avoids any more object creation / deletion and stops the garbage collector being a big fat processor hog.
* Music. That loop that doesn't sound too bad on your PC at 32kps sounds really nasty on your iPod, funny what with it being a music player first and foremost. It's not a web game, push that bitrate up.
* scrollRect. I usually use that for animating bobs ( Blitter objects, ie sprites you plot with copyPixels or by adding the Bitmap directly to your stage ), using it to view a window on a sprite sheet to make it look like a sprite is animating, all nice simple stuff. I only had the briefest of tests with it on the iPhone, and I think it could be a texture memory hog, so the best way may be to just copyPixel each frame as you need it ( I've really not tested this to death so this could be complete arse, I was using a really big sprite sheet, so for now take this point with a pinch of salt ).
* Think blitter. Our good friend Rich showed me a blitter engine running on the iPod and it was really impressive. Blitting really is the way to go, just one canvas and plot all your pixels to it. I've just finished our own blitter engine for the up coming "Destroy More Cars" game which will be handy for future iPhone games. I'll post more details about that another time ( I'm tempted to open source it, but I really can't be doing with "This feature doesn't work" feedback. It doesn't ? Write your fucking own then ).
* Petty things. Mark your classes as final where you can, don't divide by two when you can multiply by 0.5, stop events from propagating. All tiny tiny things, but every little helps.
* Remember startDrag ? Sure you do, we all used it back in Flash 5. You're designing for the sexy iPhone now, it's not a mouse interface, let the player drag things around in a sexy way, they'll love you that little bit more for it. Apple have lots and lots of style guide docs, give them a read, it still applies to us even if we're Flash kids.

In terms of workflow, if you use Flex or FlashDevelop then you're not wanting to go back to the IDE in a hurry, it's too much of a shock to the system. I stuck with Flex ( By that I mean coding as3 in it, not mxml, there's still so much confusion about it even now ) and with including the AIR swc got auto-complete goodness on all the new commands. Lovely. Because Zap doesn't use anything really iPhone specific that needs to be on the device to test, I just added a simple test. If it's running via Flex check the keyboard and use that, if it's on the device don't run the keyboard code and revert to just mouse events.
I can't emphasis how much time this saved. You surely know the difference in compile time from Flex / FD compared to the IDE anyway, who wants to go running back to that ? It's not always going to be possible, but where you can make a version that can be tested off the device.
( In saying that, still test often on your device just to ensure that you're getting the performance you expect ).

How I set it up was having an empty fla with the iPhone publish settings in it, which just pulled in my classes. With CS4/5 supporting <embed> you don't have to change a line of your code, just use a different fla for laying out your assets for import. Using an empty fla just feels cleaner to me ( In actual fact I used two, one for testing and one for distribution, as you have to use different certs / profiles for each, more on that below ).

Moving on to Apple related things, brace yourself, this isn't the same as uploading a game to newgrounds. We've all read that getting a game published on the App Store is so easy and pain free, but that's mainly coming from people who are more used to the hell of developing for consoles, not Flash.
You're going to have to pay your $99 or whatever it is to register as a developer with Apple. My advice here is just register as a person rather than a company, it's a lot less hoops to jump through, plus when it comes to the App Store you can use a company name anyway which is searchable.

Next up is getting a cert and provisioning profile so you can test the game on your device. On the Mac that's fairly straight forward, on Windows it's a couple more things to do, our mate Iain touched on it in his blog post about his iPhone game. Come launch time I'm sure the web will be sinking under the weight of tutorials on how to do it.
One thing with the provisioning profile is that you can add devices to it. We couldn't really get access to any non-3GS / 3rd gen devices which restricted our testing, but you really want to be bugging everyone you know with an Apple machine for their device IDs so you can send out builds of your game for testing.

Come the glorious day that your app is ready to submit remember you'll need a distribution profile and cert. Also remember to re-read all the Apple guidelines, you don't want your game knocked back because of a silly mistake. You'll need to supple a link to a support site for the app, so prepare to remember your html skills that you've forgotten ( We just used the zap preview page, added a link to the contact form and job done. We've got a pimping and support page all in one ).
One last submission tip, when setting the release date, set it off in the ( Near ) future. If you leave it as todays date then when the game is passed at least 2/3 days after todays date it will be hidden in the latest releases ( Say you submit your app today, the 26th, and leave that as the release date. The game is accepted on the 28th. Your game will be classed as being launched on the 26th even though no one can actually buy it 'til the 28th, and even then it's got to filter around all the worldwide App Stores. This means all the games released after the 26th will be shown above yours in any latest games list ).
Once the app is approved, dive into itune connect and alter the launch date to tomorrow.

I think that's it. Hopefully I've not said anything I shouldn't have and got myself into trouble. If I have then I'll just lie and say my Mum is ill and start crying, no one will give me a bollocking then. When you do finally get your hands on the brand new Flash CS5 have a good google around for Apple developer forums. Every possible problem you'll ever have with submitting game has already been covered off by other people, the iPhone development community is huge and excellent, imagine our community without all the "I need teh codez lol!" and that's pretty much it.

Squize.

The games just don't want to stop

Squize — Mon, 15 Feb 2010 01:03:30 GMT

Really busy weekend, I've been working on my new Blitter engine ( More soon ), pimping Ionic and also Zap went live at the same time.

It's available now on the App Store for $0.99 / £0.59 / Whatever. If you've not seen the preview that we posted the other day yet and want to see what it's like before you buy, why that's right here.

I'm waiting to hear from Adobe to see if I can get my NDA lifted so I can go into some detail about the CS5 iPhone packager.

Squize.

Green, it's always good

Squize — Wed, 10 Feb 2010 23:45:12 GMT

Guess what that little green light means ?

It means it's approved. With a little bit of luck our first iPhone game should be available for people to buy ( And then bitch about in the reviews ) tomorrow some time.

Word is, Zap isn't going to be the only game to spew forth from our creative loins tomorrow either.

Squize.

Zap preview

Squize — Mon, 08 Feb 2010 18:07:41 GMT

Well the game is done now, so now it's time to start the submission process and obviously the pimping process.

I've knocked up a cheeky preview video clip of it in action, and it's right here.

Now I've got to do some icons, write some copy that will wow the money out of peoples pockets and take some screenies. Nearly there.

Squize.

It's very green

Squize — Tue, 26 Jan 2010 15:15:05 GMT

Development of our first bit of iPhone goodness is coming along nicely. The game is an actual working game now, and plays quite well. As you can see the look & feel has taken a major change in direction from the first screenshot the other week.

The glow look & feel just looked toilet. Without being able to use Blendmode.ADD like you would on a normal Flash game and other feedback effects it just wasn't working. It looked like someone had just discovered the glow filter and was dropping it onto everything.
So after a bit of feedback I decided to go for the faux GameBoy look. It's what I was planning originally anyway for the game I shelved. As it progressed I realised the game was missing some character, so out came the JBJ Sisters. They were characters in only my 4th ever Flash game and the only real character based IP I think we've ever done ( You should know by now we're more big slabs of metal and big lazers than identifiable characters ).
Straight away the game got an injection of life, which I'm really pleased with. And the best thing ? I did a remix of the original JBJ Sisters, the "Milk it mix", and that was my first flirtation with making something look like a GB game. So I've got all these GB coloured assets that hardly anyone has ever seen which weren't doing anything and needing a home.

One other major plus is that all the images are 8 bit, there's no alpha blending going on there, which really improves performance. The change has been a major win all round.

The game itself is based on the skeet shooting event in HyperSports. Not the first time I've coded this game, we did a version at preloaded back in the day called Shootin' StarZ, so I knew it worked as a game, and fits the device nicely ( Those two gridded areas you can see are your thumb buttons, it just feels nice in terms of input, straight forward and direct ).

When it comes to changing my game structure for the iPhone, it's really not been too bad at all. I'm still developing it in Flex3 ( And thanks to Rich I've got auto-complete on the new API stuff too, which is really rather lovely ) and doing all the testing with a normal swf with keyboard input, and just publishing it for the device to test performance and new graphics ( They do look different on the ipod than onscreen ).
This means my workflow hasn't been hit by long publishing times, which would have stopped me working on this long ago.

The major change was to do with when to trigger my constructors. I normally don't create class instances until I need them ( Ususally in the startGame() method ) but this was causing a noticable pause when going from the title screen to the game, so I call them during the "preloader".
Basically when an app first runs a bitmap is displayed straight away, then once the app is loaded it cuts to the app itself. All I've done is made the first screen in the game match the initial bitmap ( A big GYW logo, naturally ) so when it cuts from the bitmap to the game there's no change. I can then call all the constructors there under cover, and they set up all their object pools etc. before fading that logo down to the title screen. Nice and simple and effective.

Next up is fleshing out the presentation and giving the game some love and we should be good to go.

Squize.

A different 480x320

Squize — Thu, 14 Jan 2010 23:48:04 GMT

After a week of playing I had to abort "Andrew", my first crack at an iPhone game.

It's no great loss in the grand scheme of things, I hadn't committed to it a 100% and was more a tech test hoping to evolve into a game, and as is the nature of these things, it failed.

Onwards and upwards, with a title screen grab of the current WIP, which has got what I think is the worst name I've ever come up with for a game.

It's my usual "Put a lot of glows on things so people don't spot I can't actually do art" look and feel. The transparent balls are moving around in 3D with a depth of field effect ( An overly grand way of saying blur ).

You'll notice the 3 little breadcrumbs at the bottom center, this is because it uses the usual iPhone finger slide ( Is that the term ? ) to scroll through the 3 pages of the title screen. It's actually done using the old school favourite startDrag(), which is pretty nasty in Flash, but works lovely on the iPod.

That's it for now, I'm not sure what I can and can't say under the NDA, so I don't know if I'll be able to touch on performance ( Much better than I thought, it's very impressive and they're still working on it ) or other API related things ( Other sites may be running more in-depth details about CS5, but lets be honest, I must piss more than enough people off already without adding Adobe to the list ).

Squize.