Game Dev Blog

Ok, final post on BallZup since it’s now out and in the wild.

Quick sales figure update. Based on the weekly reports, the demo version sold 295 copies up to the 23rd of November. In the two days the full version has been up (at the 3.99ukp price point), I’ve shifted 30 copies. This is with no reviews or press of any sort really, just appearing in the new releases section of the App Store and getting listed in the large collection of App Release aggregators on the web.

The figures are pretty consistent for the demo. While it’s in the top 25 listings for new releases on the app store it shifts 25+ copies a day. Once it drops off that list it does about 4 or 5 copies a day, if that. This pattern has been pretty much the same for the 3 updates I’ve put out, so you do need to keep bouncing your application with new releases.

Updating at the weekend doesn’t seem to make any difference to sales. In fact, this weekend they dipped compared to the mid-week update I did for 1.2. So, it’s a bit hard to figure out if there’s a more attractive time to be visible. Updating on a Monday morning seems to work best for me atm, as I’m normally in the store on Weds and squeeze 2 days in the list. Of course, everyone else is up to the same trick, so if you’re unlucky, 25 other games have been updated, you’re the first to get listed and fall out of the hot zone straight away. This happened to the full version’s 1.0 release this week. Probably because I was Ready For Sale on Weds afternoon, but opted to hide it until Friday.

Some Stuff That Went Wrong

Few lessons learnt from the whole experience:

Nicking Apple’s Crash Landing Code: I used this as a framework for the port from the Unofficial Tool Chain to the Official SDK, completely replacing all my software rendering and png loading with the texture2d class and OGLView setup in that demo. It gave me a great kick start on the port but had a few problems:

• The double buffered contexts would randomly corrupt at runtime. I was never able to reproduce this in the debugger although it was ever present in the 2.0 SDK. It only ever appeared on the actual hardware as well… I thought it’d had disappeared when I moved to 2.1, but it popped up again on the final release version, meaning I had to completely replace the OGLView classes at the last minute. Not a huge task, but it was annoying. No idea what caused this but I think it might have been a timing issue somewhere, probably in my code
• The sprite class ended up being split between ObjC and C++. Lots of function overhead I could have avoided and in the end it actually restricted some of the stuff I wanted to do. I also couldn’t take proper advantage of the OGL state meaning there are too many texture binds, and I didn’t spend the time to make sure all the blended blits were done at the last pass. On the next game I’m going to use a single texture page, get a bit more flexibility with the UV co-ords and manage the blit orders myself to squeeze them all out in one lump… I should have just spent the time to do a proper sprite/draw manager and decoupled this more from the game logic.

I’d been pretty good with my C++ code for most of the project, but once the game was essentially complete and I was adding niceties like the score upload and saving, stuff got messy really quickly. This is due to a complete lack of thought/design as I’d been dealing with the ObjC as setup and the C++ as “my game”, not thinking about how stuff was actually communicating until too late. But for future reference I should have:

• Spawned different classes so I could properly delegate UI messages in the ObjC, or just handled it as part of my game-state in the C++ side. The latter would have been tidier, the former probably quicker to write.
• Batched up the responses from the Async stuff like the score upload and only handled it when I was ready to, in the game. Like the input events. What I ended up with is a fucking mess of conditional code in delegate functions that really shouldn’t be there. And some very hacking state changes for the game…

The other massive downside to all this was my lack of knowledge of ObjC. Lots of time was spent working out the magic voodoo that would convert Apple’s core types to something I could use, or formatting my stuff into something the Apple stuff would use. I understand a lot more about all the core types now, and it’ll be a lot easier the second time around, but toward the end of the project a lot of time was spent googling…

And then, right at the end, I learnt a big lesson about having a clean XCode project. It took well over a day to get the provisions sorted, have the build compiling with the right code signing and build a version for release. Not to mention learn the nuances of the iTunes Connect process. This is all easy now, but it was a hair pulling day of frustration when all I wanted to do was release a version…

More minor stuff:

• My textwriter is rubbish…
• Speed could definitely be better. 46-50fps avg in the profiler isn’t good enough really.
• I never did fix that click in the audio
• I really really should have put in an option for save and quit after every level. So people could restart when ever they wanted
• And because I can’t save state, the game quits when a call is received.

All of which I’ll fix for the next game

But Stuff I Am Quite Happy About…

• Getting it done
• Nicking Gaz’s interface setup. The Mac version fell out in a couple of hours…
• The collisions! Line intersections melted my brain for 2 days but proved solid as a rock once running.

It’s actually quite playable in the end. And I do like the multipliers. If you treat it as a high-score run, then you do really need to use stuff like the Minty Saves and free Zapper to manage your ball speed and give yourself a chance of maximising the multipliers from a level. Small things, but enough to make me pleased with the result.

It sounds good (although K hates the intro level tune, thinks it sounds like a game show, which has only made me love it more) and it looks a lot better than I thought it would. Big props to Gman for tarting up my initial stuff and a big Woot for OGL. My SW rendering stuff just wasn’t as tasty in the end

Keep forgetting to update, so this is useless as a dev blog

Anyway, after seeing the nasty grams sent out about the Breakout clones on the App store, I’ve spent a few days putting together a Mac OS X build of the game, just in case.

The first day was a serious falling out between me and XCode. I just wanted to add another target to the project file and then build them all from the same project without having different windows open. Obviously there’d be some changes in what files were compiled, but there’s a target ownership flag that Gaz pointed me out which would do the job. Although, to be fair, he also said to just create a new project as it’s easier, but I figured it’d be nice to actually get all the targets working from the same project. More fool me

I must have spent 4 or 5 hours trying to get this to work, but despite the settings saying one thing, the actual build process seemed to do something different. Even going through the pbxproj files showed different things In the end, the pre-compiled AppKit headers would get built twice (or more) and the nib wouldn’t reference properly either of which would result in a billion errors and no build. Not to mention all the resources getting copied to different places in the application bundle. Lots of stress, no fun and I never did suss it out, so instead I created a new project file with just the Mac Target in, which with the *exact* same settings, worked absolutely fine first time. I’ll take the advice in future

The actual port was cool. UIKit/AppKit and the UI*/NS* classes are largely the same when it comes down to it, the changes I found were for stuff that’s understandably iPhone specific. The only really gotcha I tripped up on was the lack of simple way to get a CGImageRef from an NSImage, something my texture code was doing in one line on the iPhone. Meant a couple of hours of nothing visible in my window, which was a let down, but once sussed, the game popped straight up.

Actually, that’s my biggest gripe about coding with Apple libs. There’re loads of built in types, many of which on the face of it look largely similar, so it’s always confusing to know which to use. I’ve found a few times that I’ve used the wrong type initially, so when, say, saving stuff out, I’ve either had to re-write a load of code to put everything to the right type, or do some voodoo conversion at the last minute. And ObjC just doesn’t look nice in the editor. It’s hard to format clearly…

Despite that, a lot of the Mac SDK is starting to make sense now, and tbh that’s been my only real frustration. The flip side has been a super speedy knocking up windows, text boxes, inputs or whatever and the docs have always provided really solid examples that I’ve been able to bend about. There’re some slight changes to the game for the Mac version: Slightly bigger ball (Rik’s advice :D), it’s locked in at 60fps (instead of 50) and you don’t get to touch the screen to enter your name, but other than that I’ve hardly had to do any specific tweaks or code changes which is awesome

I’m really really surprised at how quick and pleasant the whole experience has been, tbh. I was expecting a massive faff

I’ve just got the Mac XML-RPC stuff to do, then it’s decision time as to what to do with each version…

Quick Demo Movie…

Progress is going well

I’ve moved the old code over to the new 2.1 SDK for the iPhone. It’s doing roughly 60fps in the simulator and 46-52 on the device. There’s probably room for improvement as I’m not too hot on optimising, or OpenGL, but even a steady 50 would do me, tbh.

I’ve added in the support for xml-rpc uploading of High Scores, which you can see at the end of the movie. It’s only going to a server on my local machine atm, but it looks like it won’t be too much heart ache to get this going on the net.

Small list of things to do, mainly tiding up transitions and adding a few options on the menu, oh, and a load of levels. But the big stuff is done.

Managed to get to grips with the getting my code signed and runnable on production iPhone. It’s a bit of a pallaver to be honest and I don’t really want to go into any detail for fear of breaking any NDAs. However the good news is that it does work, the bad news is GR+++ runs incredibly slowly.

It’s shouldn’t take long to sort out, I’m confident the main code is plenty fast enough; the unofficial SDK version proves that’s the case.

The likely culprit is the OpenGL code that downloads the game screen into a texture. I had a problem similar to this on the mac version a long while ago. I’d created the texture in GL_UNSIGNED_SHORT_5_6_5 format, the same format that the game itself runs in and this went really slow. The reason was that the HW itself doesn’t seem to support this format natively and the driver itself was doing a very inefficient conversion to RGBA. The solution was changing the texture to RGBA8 and doing my own rather nippier conversion from 565. It wouldn’t surprise me if that was the case this time as well. Gareth mentioned he’d seen someone on a messageboard say they’d had problems with something similar. It’ll be that or the sound I’m sure.

In other news a chap on the yakyak forum has written a really nice looking iPhone game called Rolando, you can see it here. It’s a nice OpenGL based title that uses tilt a lot and has a bit of a LocoRoco aesthetic going on. The web page has an ace little animation showing the game working and I asked him how he’d recorded this and he pointed me in the direction of Screenium by Synium. This little app allows you to make a video of an area of the macs screen which in turn means you can run your game in the iPhone simulator and grab the output of that. Neato. I did a quick (and in much needed of improvement) test here.

It’s been a pretty good few days for random apps on the mac. I can recommend having a look at these:

Viscosity: a great OpenVPN front end for the mac that replaces TunnelBlick which was okay but a bit flakey at times. Even though it’s only in beta Vicosiy has been rock solid the last few days.

Cornerstone: A very slick looking SVN front end. I quite like using SVN from the command line but this is quite nice. Would be handy for artists innit

I’ve downloaded the latest iPhone SDK yesterday and had a quick fiddle to see about converting GR++ from the unofficial hack SDK onto Apple’s proper bit of kit.

After an hour and a bit of fiddling everything compiles nicely and the game is running. Unfortunately it’s in Helen Keller mode, it receives no input and doesn’t display anything but it is running in there, honest
The Unofficial SDK version got stuff on the display using an API called CoreSurface which unfortunately doesn’t exist in the official release so I’ve had a look at OpenGL ES. GR++ software blits to a 200×320 surface that’s made up of 16 bit RGB words in a 5-6-5 configuration and I need that copied up to the iPhones 400×640 rez screen.

Rather than software scale the plan is to create a texture that I’ll use glTexImage2D to dump the GR++ screen into each frame. After that I’ll print a quad using that texture scaled to the screen size. This is how the mac version worked so. In fact I’ve got this mechanism working by copying over the mac code, all I have to do now is make sure the GR++ screen gets dumped in. I’ve made the texture the same 5-6-5 format as the GR++ screen, which -should- be the fastest way to get this working which it should be in the next hour or so
After that I need to complete my official developer registration so I can check the game on an actual iPhone, I’m currently using the simulator. Unfortunately emulating the iPhone at full speed is a little bit beyond my macbook air right now so I’m devving back on the Mac Pro for a little while.

EDIT

Here we go, some obvious mistakes

buy cialisbuy cialisbuy levitrabuy levitrabuy propeciabuy propeciabuy somabuy somabuy levitrabuy cialisbuy propeciabuy levitrabuy somabuy cialisbuy propeciabuy levitrabuy somabuy cialisbuy levitrabuy propeciabuy soma

Latest version is online, now with added audio The update should appear in the installer, so check the Xen Ports category.

Thanks to Swith for the awesome jingles

Successfully nicked Gaz’s audio code today and got it in game. So that’s pretty much the last big thing left to do. Apart from drop shadows. But I did finally put the high score entry stuff in earlier in the week, and that’s nice and tidy…

I can’t believe how much of a difference a bit o audio makes. It’s put a right smile on my face, even if I’ve just discovered my sound design skillz ain’t brilliant atm…

I’ve got a firm deadline for the end of the month, so it’s proper heads down content fiddling now to try and get it as polished as possible. I wanted to put fluff effects in for the menus (plasmas and shit) and high score table, but I think that’s gonna have to slide for now. Still, it feels good to have this much out of the way. It’s a proper little game

I’ll stick an updated build up later next week so you can have a play…

Okie doke, I’ve put today’s version online so you can have a quick look-see.

If you’re hacked and using Installer.app: Tap the sources button at the bottom right of the app, tap Edit (top right), tap Add (top left) and put the following URL in:

http://kor.gazaxian.com/iPhone/installer.xml

Let it refresh and if all goes to plan, next time you tap the “Install” button, you’ll have a shiny-new category at the very bottom of your list: “Xen Ports”. Tap on that and BallZup should be there for you to download. Once it’s installed the Xen Ports category will only reappear when I update the app. That confused me for a while

Anyway, customary build waffle:

- Front end is totally place holder. Tap BallZup to start a game
- There be no audio
- Only about 15 or 16 levels in there atm.
- This build’s not got the high score stuff working properly. If you get one, move your finger about the screen. There’s a hotspot somewhere that’ll exit you back to the main menu.

Think that’s about it for serious issues

And the emulator now supports OpenGL ES.

This is good as I should be able to get Gridrunner++ working on it now.

Very busy right now but I should be able to have a look-see over the weekend Woohoo!

And you can get it here:

http://developer.apple.com/iphone/library/releasenotes/Miscellaneous/RN-iPhoneBetaAPIDiffs/index.html

It’s getting there.

Lost a bit of steam the last couple of days, but the previous couple of weeks have been really good. I’ve got a game. It’s kinda close to an alpha ‘done’, I’ve got some finished levels, working transitions and the high scores are in, and for the most part, it’s looking nice and stable.

I’ve learnt a lot. Especially about how bad a couple of design decisions were, as far as drawing to screen was concerned. The collision’s been simplified, so I’m no longer brute forcing everything and I’ve had a look at improving the draw updates. My basic sprite class was ok, but there was lots of overdraw and the speed was bad because of that. I spent 2 or 3 days hacking in a dirty-ish rect solution, using some tips Gaz gave me, and although the code isn’t too great anymore, the multi-buffer approach he suggested has made the speed more than good enough. I can chuck loads of multipliers, balls and shit around the screen, so the later levels should be pretty hectic. Lesson learnt about making that sorta change late on in the project though. I’ve probably spent as long sorting out little issues that have fallen out of the change as I did actually coding it.

I’ve got a hefty list of things to polish, but bar audio, it’s getting very close to the point where I’m just tweaking stuff and making the levels. I think the only possible large-ish stuff left is changing the brickhandling to support different sized bricks and possibly looking at online high-scores. Not sure if I’ll do the latter though

I’ll chuck a build up once there’re a few more levels, so you can decide for yourself