Since I accidentally ended up with a 80Gb PS3 the other day I decided that I might as well go an pre-order LittleBigPlanet - so I have 
While I have some fears over MM pulling this off to the level of hype it had been getting I am going to support them in this since the industry desperately needs it in order to get out of it’s ‘me too’ loop of game development.
My first iPhone game has resulted in an engine that I can use for other iPhone games. It’s pretty light-weight and 2D at the moment but a good starting point. I am also porting it to SDL so that it can run on PC and OSX (and Linux at a push - but I don’t have a Linux install so I can’t work on that personally) and it occurred to me that this small engine might be of use to other developers. As I say, at the moment it is pretty light-weight and to be honest just contains enough to do the game I have just submitted to Apple but as I begin to make more games the engine will be expanded to include new features. I personally think that the iPhone is more suited to 2D games rather than full 3D due to the nature of how and when games will be played on it (i.e. at the end of it all its a phone) but there is no reason why 3D will not make its way into it. In fact the next game will probably work within a 3D world but still remain 2D in essence (if that makes sense :|).
The question then rises, if I make this engine available do I make it free, donation supported or out-right charge for it? What are your views on this? Would an iPhone game engine be useful to you? If so what kind of licensing model would you prefer?
If you look at the sidebar you will notice that I removed the google Adsense ad. It was doing absolutely nothing for me - no income at all and there wasn’t even an eCPM value associated with it which is odd. So rather than keep displaying ads for google for free I removed it. It was only an experiment to begin with so no loss
My first game ‘Boxes’ is with Apple going through their submission process so while this is happening I would like to share with you my experience of developing a game for the iPhone.
My first game took me 2 weeks part time to develop. It’s not a massive game and it hasn’t got a huge amount of levels but given the app stores update facility I aim to expand upon as time goes by. The actual process of developing it however has been a roller-coaster ride. I would like to congratulate Apple on the installation process of all the tools and the instructions contained in the developer portal as getting the whole tool chain up and running to having an app running on the iPhone was painless. Where they fall down is the code support level. For instance, while testing your iPhone app will exit and give a status code upon exit. Now, apparently these numbers mean something but nowhere are these codes listed and emails to Apple don’t get you anywhere - but this may be because it is in Apple’s interest for you to take out an ADC subscription.
The approach I took in developing the game was a hybrid Objective-C and C++ route. So the Objective-C side takes care of the necessary parts of the iPhone setup and asset loading and the C++ side is the actual game. I must admit this approach works very well for me since I have no real desire to learn Objective-C. The XCode compiler makes the 2 languages merge very well and there were no major issues. I was very impressed with this.
The iPhone hardware is impressive. Reading the accelerometers and translating the information you get into something meaningful is a dream. I imagined it would be a lot harder than it was. The graphical power is something to behold as well. I was able to push around a lot of particles without any real slow down and I must confess that my first generation engine is the most inefficient engine you could write for OpenGLES.
Instruments is an application I fell in love with straight away. It does stats gathering on your application and it helped me locate bugs that were causing my frame rate to dive. I want this kind of app for all of my game development now - not just on iPhone! I know there are other tools out there that do a similar thing but Instruments does it so well.
The submission process. Apple have attempted to make this a seamless process and to the most part it is. Their documentation needs a little help though. An example, they want you to provide 2 icons. The first is the 57×57 one that appears on the iPhone and a 512×512 one that appears in the app store. Nowhere does it mention that these two have to be identical - in fact my first round submission failed because I used different images. The process of uploading your game is also flawed in that the second time you attempt it you get stuck in a ‘waiting for upload’ loop and their separate application loader exe is broken. Once you have your game uploaded it enters a ‘review’ stage and this is the part I hate the most because there is no indication of how long it will take and I find myself looking at the page every day to spot a change.
More later as I get more and more into the process.
You can hide the main status bar by adding this following code to some point in your ‘applicationDidFinishLaunching’ function:
[application setStatusBarHidden:YES animated:NO];
So, my game just uses the tilt sensors to move around and yet after a few seconds the iPhone would dim the screen causing the user to tap the screen to bring it back to life. This was annoying and it took me a while to discover how to stop it. So, if you are having the same issues then place the following line in your app delegate:
application.idleTimerDisabled = YES;
Seems simple now doesn’t it
Attending Alex Evan’s talk at Develop this year was an eye opener, especially when Alex opened the talk with ‘We made all the same mistakes that Lionhead did’. See that scares me - mainly because I used to work for Lionhead and I remember what it was like to be a coder there. Don’t get me wrong, Lionhead was a fantastic place to work and has some amazing talent there but one factor that was missing at my time there was planning and it appears this is what Alex is referring to. One of the exciting aspects of working for Lionhead was the relative freedom to experiment with different systems and techniques in coding however this was also its downfall because you found that you had a lot of code that was written, dumped, written again, dumped again and written yet another time. An example of this was a newspaper system I was working on for the console verison of the Movies. I found after we dumped it that at least three or four other coders had implemented the same kind of system and also had theirs dumped - not because it was bad code but because once it was coded it was decided that it didn’t really fit and then they dumped it only to be re-coded when somebody declares that ‘wouldn’t it be great if we had a newspaper system in the game?’. This kind of iterative re-factoring is expensive to projects and I have seen it at a lot more games companies that just Lionhead and I am sure I will see it again. The way Alex was telling it he seemed to believe that LBP had it bad and as a result they are having to pull stupid hours to finish it. His one advice to everyone - place constraints and adhere to them.
So why could this spell doom for Little Big Planet? Mainly because what you end up with on these types of projects is a mixture of messy code masquerading as design that sometimes works but often doesn’t. It worries me that the innovation that is Little Big Planet will not be able to deliver on its basic promise of a social networking game because the approach to delivering that vision was flawed. We need Little Big Planet to be different and we need it to be damn good if we are to change how this industry keeps pumping out ‘me-too’ games.
The ray of sunshine we have is that Alex has a brain the size of a planet so he should be able to pull the game out of the quagmire it appears to be in.
Zombie cow studios (he of Gibbage fame) has put together $400 that he wants to give away to to some aspiring indie developer that needs it. It’s not a scam so check it out if you need some cash to buy assets or something else:
