I’m certainly glad I did as I’ve learnt so much this week, met some great people, and realised how much fun development of software is, even if it does have it’s plain irritating moments too.

When I first arrived on Monday at 10am I was introduced to everyone again which was great as I’d completely forgotten every ones names, and no doubt will forget a few again. I got a desk next to the main iPhone developer there and started to continue working on my app. It wasn’t before too long that Max the developer there suggested I work on the actual game logic and forget about the GUI for now, I took his advice and began working on the logic which in this case is a version of Conway’s Game of Life which will run the GUI and the sound engine when that is implemented.

Luckily I had access to an Open Source version of the game logic I was going to be using, however this was written in Objective-C and for a desktop platform so my first job was to re-write this into Objective-C 2.0 and also port it across to the iPhone platform. This took the best part of a day and a half as I’ve never used Objective-C in any way so this was a great learning experience for me!

Once the logic was coded I had to prove that it still worked. Before I started working on any of this I had already begun working on a test GUI for the app so was going to use that to test the logic, however this was advised against by Max and it was decided to test the logic I would use good old printf to output to console and forget the GUI elements for now.

For some reason my brain just would not engage on how to output the grid which is stored in two arrays to the console, my dad sat down with me one night and helped me to think logically about things again, when he did I realised pretty quick what I was doing wrong and had the output going to console.

The next job was to get a simple GUI working with a sample set of cells which I wrote some utility methods to do some of the work for me. These utility methods take a grid location and then convert those into screen co-ordinates for determining the location of some sprites on the screen. Up until this point I had been using a single sprite object and either add it to the layer or removing it, the problem with this way was that each time the sprite was placed each sprite used another chunk of memory, which there is precious little of on the iPhone and iPod Touch. Max told me about the AtlasSpriteManager in cocos2d-iPhone 0.8.2 and said that I should use that instead.

While saying this he also suggested I upgrade to the cocos2d-iPhone 0.9-Beta 2 framework to work with as AtlasSprites had been integrated with Sprites. We had a chat about it and I decided to give it a go. This began the headache of re-writing about 30% of the code I had worked on to make use of the new changes between the frameworks, I started a new project to do this just incase things didn’t work as planned ao I didn’t have to revert my code back to the previous version.

After spending a morning converting all my code it was working as before so I started to work on the sprites. This took most of the afternoon as I was pretty much on my own as Max didn’t know what did what in the 0.9 release the documentation for cocos2d definitely came in very helpful at this point! By the end of the day I had a working prototype working with the test cell setup method I had written when using console.

My next task was to make each cell in the grid I’d created respond to touch events. This required me to subclass CCSprite in my own sprite object, there was very little documentation about creating touchable sprites in the documentation or on the wiki site so I was going it pretty much alone on this, with only help from the forums for the older AtlasSprite way of doing things. I hit a lot of stumbling blocks along the way and after a day of trying to get this working and even with Max’s help still could not figure out what wasn’t working, I decided that the best course of action would be to revert back to using cocos2d-iPhone 0.8.2 as there are a lot more resources available for help, and if I need to ask Max for help he has used the framework.

As I had a copy of my 0.8.2 code on SVN I checked that back out and got about to re-writing it using my 0.9 code as a guide, this didn’t take too long as after a week of developing I was getting a much better understanding of the way things were working and what did what. After about an hour I had the code to the same point as my previous 0.9 code and everything was working. I tested everything was still working on both my iPhone 3GS and The Pavment iPod Touch 3rd gen, which to my joy everything worked with no problem.

At this point it was Friday evening, I had made a lot of progress and then gone backwards, then forwards again. I don’t see this as a bad thing as I was using a BETA framework which has not been adopted by a lot of people so I really was working on the breaking edge of things, the decision to revert back will hopefully mean that things can progress much faster from this point onwards. When the 0.9 framework has been used more widely I will look into moving my app back across to that as it was marginally faster.

My next task on the app is to create a few variables to store the previous state of a cell, then only redraw the AtlasSprite for that cell if it has changed from it’s previous state, as currently every cell is being redrawn in every step of the grid which will start to cripple the frame rate when there are a lot of cells in the grid at one time. I’m currently working with a 16 * 24 grid which is splitting the iPhone screen into 20 pixel cells, while this is ok for testing the eventual goal is to have a much finer cell size making the GUI look more impressive as generations increase.

Tweet This Post

I have started to get the hang of using Xcode after using it for a longer time now. I’m not overly keen on the Interface Builder however as I’m using Cocos2d-iPhone I shouldn’t need to make much use of Interface Builder. I feel that after really learning how it all works and what does what then it is a really powerful tool, however currently it just seems to be quicker for me to hand-code what I’m trying to do. This could be a stupid idea on my part but only time will tell.

My application has started to take shape finally after a few weeks of sitting in a state where I could register taps on the screen as screen co-ordinates in console, which seems to be pretty much game development 101 sort of stuff. Now moving on a bit from that I have (with a bit of back down to earth help from my dad) managed to get a virtual 20x20px grid working in my touch layer of the game so that a touch within a certain 20x20px cell is registered as one location on screen, for example, if a user touched the screen at screen co-ordinates (3,19) then that would be cell (1,1) in the console, however if a user touches (25,19) then that would be grid cell (2,1).

This has taken me a while to get working as for some reason I completely forgot that screen co-ordinates are only numbers, and there can only be a certain amount of pixels on the screen, once my dad had reminded me of this fact I was away and could finally get my grid working. Currently the only thing it can do is log the start location, end location, and also track a drag through the grid cells to the console.

The next step for me is to get a 20x20px sprite to stick to the location where the user has tapped but to use the grid cell as its reference, for example, if cell (1,1) is screen co-ordinate (0-19, 0-19) and a user touched (13, 5) then the sprite would not use (13, 5) as its anchor point, but instead will use (0, 0) as its anchor, sprites should anchor from the bottom left corner using this method. Once I have a single sprite working I will then look into getting multiple sprites working at once, and then onto tracking a drag work either placing a sprite or removing an instance of one depending on where the user has dragged their finger.

Once I have this working I’ll actually get around to posting some example code in a short post soon.

Tweet This Post

I had a meeting with the MD Andy of The Pavement in London who I’m working with to get this application built. They are acting as the client for this project however this project wasn’t originally a dissertation project. I’m not completely sure how many details I can actually give away about application itself as this is a real app, and will be available on the App Store in 2010 hopefully.

The meeting on Friday really cleared everything up in my mind, and also gave us some very interesting ideas. I’ve received a pre-release copy of the content for the app, which I’m still unsure whether to call it a game or not. The application is going to be music based which will more than likely involve me having to sample certain aspects of some recordings, or even having to get some custom made sounds that I can sample from the musicians in question.

I’m looking into a few different frameworks to build this app/game and I’m thinking that I’m going to end up using Cocos2d which is an OpenGL ES 2d game framework. Cocos2d has features such as touch/accelerometer support, sound support, tile map support, particle system, among others but most importantly the whole thing is Open Source. I’ve been playing with Unity Pro and Unity iPhone recently on a machine one of the staff at uni has lent me, however the licenses for these products are pretty expensive so I wouldn’t be able to continue to develop apps after I leave uni without buying my own licenses.

I know there isn’t much actual information about the application here, however I’m not completely sure on how much I can say just yet. I’m having another meeting with Andy on Friday 18th December so will find out just how much I can give away then. I also don’t want to give away too much of the concept we’ve got. I may do some mock visuals soon.

Tweet This Post