For want of a nail...

"Hubris!" a friend of mine exclaimed as he watched the pomp and circumstance of a recent pep rally at our school as we prepared to face a team better prepared than our previous opponents. "Hubris!"

I mention this, because I was congratulating myself on how clean my code was. When I wanted to add a new feature - hints for the player who is stuck - it was a relatively easy addition to make because my code was broken down well and documented. "Hubris!"

As you might guess, I've been hunting a bug, and finding others along the way...

The bug I was after was one that was causing the program to freeze and crash whenever the chips needed to disappear from the back of the screen. I had just been adding in the hints code and was in the process of fixing a glitch where some pieces wouldn't stop spinning. I looked all over the game manager code where I had been working, ran the debugger to isolate the line, checked and double-checked the memory management code, even ran instruments!

I found two tiny memory leaks in Instruments, but they didn't fix my bug. Finally, after the better part of a week of searching, I found it tonight. It was a change inside the Chip class, where I had been modifying the "description" method to add one mo piece of information - and pit the new code outside of the square brackets. Somehow, it escaped the debugger, and caused me nightmares.

Once that tiny line was repaired the problem went away, and I was able to fix my unstoppable spinning chips in no time at all. Fixing the leaks seems to have made some memory warnings go away, as well!

Sure enough, our football team was down by 16 points going into the fourth quarter. (I must confess, I had gone home already....) But you know what?

They rallied back and won.

Just like they are going to next week, too.

- Posted using BlogPress from my iPad

The joys of a long weekend

Got some work done this weekend - labor day has been good to me. I got the advanced pieces finished in blender and started in on a hints system.

The pieces came together faster than I had expected, and I have come to realize that I was dreading the fight with Blender more than I realized. I was avoiding the project. I am glad to get over that hurdle!

At Clay's suggestion, I added in a feature to show possible moves to people who were stuck. Right now, it scans the current selector through the whole grid, in every orientation to see whether there are moves. Whenever it finds a working move, it picks one square at random from the four selected and starts it spinning.

Clay's original suggestion was to make this happen when the player does a three finger double-tap. However, I am finding that this interferes with the single-finger double-tap that is used to make a selection, usually resulting in a scratch. It also sometimes got interpreted as a swipe, selecting the next chip. I think I will change the controls so that a horizontal three-finger swipe passes the selector, and a vertical three-finger swipe shows the hint. I may also have the spinning "time out" after a little while.

I still need to balance the difficulty level - the rings are a non-issue in the game - they disappear too quickly. At the same time, I don't want to stress out the beginning player.

I have a couple of lingering bugs: the spinning chips don't fall inwards when the time runs out, and occasionally don't stop spinning when there is a new selector. But we are closing in!

Back in the swing...

I had a great trip last week with the freshmen- on the drive home I gave a colleague a preview of Implosion. Rave reviews! (He even foisted it on some freshmen...)

He also gave me an opportunity to talk up some ideas for balancing the difficulty level and aiding the beginning player. Clay had some great ideas!

Tonight, I finally had some time to work on it again, and I've been tackling blender once more. I now have the shapes drawn for the extra selectors. I just need to add in the fills via Photoshop, and we'll be in very good shape.

I had hoped to get this app to market by the end of summer, but that just wasn't meant to be. I'm glad to get some of this blender business behind me - it will be good to get back to my element.

- Posted using BlogPress from my iPad

Getting back...

Between work and trips, I've had to step away from. My programming lately. Every time I start getting back into it, I have to spend an hour or two updating my iPad or Xcode. Tonight I'm going to have to redo the provisioning in my iPad.

So I'm having a hard time getting back in the swing of things. In particular, I left off some stuff in blender, and I have to figure out how to do that again. I'm starting to wonder if sio2 and blender were a mistake.


- Posted using BlogPress from my iPad

Memory problems...

I have been having a frustrating time with implosion. I had to take a week off for a conference, but even then, I've been avoiding it a little, in the hopes that something would come to me. And because I am frustrated.

As soon as my program starts, I get a memory warning, level 1. Soon thereafter, I get a level 2 warning, and the game crashes.

I finally got Instruments to show my memory leaks - it didn't find any. But it did show some large allocations at the beginning of the program. I found some code to tell me the remaining memory (http://adeem.me/blog/2009/04/01/get-the-amount-of-free-memory-available) and inserted into my startup routines.

Pretty quickly, I found that loading my main logo image, which was 1024 x1024 pixels, took up 5MB of my available 28MB. A bit steep-the file size was about a quarter of that, but I suppose it was compressed. So I reduced the file to 512x512, which reduced the memory used.

But I still got a memory warning.

A little investigation revealed that the memory warning was coming the second time the menu rendered. I soon found out that the first time the logo and buttons were drawn on the screen, it ate another 5MB, and the second time it ate an additional 5MB. But not the third. (I am guessing that this is a result of double-buffeting?)

So a quick loss of 15MB over a few seconds on a system where I start with only 28MB? No wonder the iPad was freaking out.

But there are two things bothering me at the moment.
1) something must be wrong with my numbers - the iPad I have is supposed to be 32GB, not MB. -- oops. I'm confusing storage space with RAM. It's pretty late as I write this.
2) when I take out the code that draws my logo and buttons, it still takes 5MB of RAM each time, even though it is not drawing anything! I am starting to think this is not my fault...

So I will have to research this online. Perhaps there is a fix for this, perhaps I can find a workaround, or perhaps... I don't know.

As I said, I am frustrated.
- Posted using BlogPress from my iPad

Progress, progress, progress!

I got some great stuff done the last day or so...

1) Menus - There is now a starting menu with the logo I showed off in the previous post. It also has a "Play" button and a button for instructions. Clicking the play button starts the game and the instructions button shows a page with rules of the game (a tap on the screen returns to the menu).

2) Pause - based on the same "sio2 widget" technology, there is now a pause feature. During the game, if you flip the ipad to face downwards (or accelerate it downwards at 2g) it will go into pause mode - the clock will stop, but there is a graphic covering up the game board. A single tap resumes.

3) Game over - when the player runs out of time, the selector disappears, all the doors open, and the chips start to fall towards the center. They make a tiny ball, which then explodes outwards. It is very satisfying in the OpenGL 3-d world! It reminds me of the original Tron and (spoiler!) what happens to the MCP at the end.

4) The game moves between the modes pretty fluidly, and you can restart the game.

Along the way, I was getting some distressing messages from the debugger. I use the "NSLog" command quite a bit, so I suspect these have been getting lost in the clutter - they were memory warnings. Somehow, I was running out of RAM space. Mostly, they were just level 1 errors, but I actually got a level 2 one tonight. This didn't seem likely, since my chips are of a finite number, and there just aren't that many polygons and variables in this game, compared to most 3d fare...

So I wondered if I had too many graphics loaded in memory at one time. I rewrote the menus and buttons (widgets) code so they loaded when needed and unloaded when they were done. It was a bit of a pain, and I worry a little bit about the speed at which they will load now. That didn't fix it.

I stumbled upon the answer when a memory warning showed up between two closely spaced NSLogs - in fact the only thing I did between them was move a Chip! It turns out that every time I moved one of the chips, I created a new 3d vector to represent the displacement of the Chip on that animation interval - and I never relinquished the memory. Multiply that by 100 chips and multiply it again by the number of animation steps during the game - it became a pretty big leak! So with one line, I patched that one... I wonder how many more I have missed.

What's left?

• Reworking the timing of the Ring chips
• Adding in the strange shaped selectors
• Redoing the sound at the end of the game to match up with the animation
• Possibly changing the single-click behavior to a double-click one.
• Auditing for memory leaks
• Figuring out how to get this thing into the store!

Dare I say I'm in the home stretch?

Fix it, yourself

Ah, the Internet. You can usually find the answer there (if you know what to search for). Elsewhere in the discussion board, I found the answer - it was a cheat of sorts. You need to invert the y-component in the portion of the code that calculates where you touched. This fixed the widget button problem perfectly, but it meant that I had to invert the way I handled the y-coordinate in the rest of my code. As it turns out, this was a small thing - I had already inverted it to compensate months ago, so now I just needed to change three lines to undo my previous inversions. That's working much better now.

But now, as I test my program, I have found a bug. Sometimes, the chips aren't sliding all the way in, or are just disappearing so that there is a blank spot in the grid - which never goes away - the user is in a bind. I need to figure out what is going on! (I wonder if this has to do with the timed pieces I just added recently- I'll start there.)

Presuming I get that fixed, coming up are (in no particular order):

• an instruction screen
• a pause menu
• animation on the title screen
• in-game instructions
• a second green ring in the timer
• improved timer chip placement
• a game over animation
• scores on the title screen
• additional selectors for higher levels

... and I think I can post the game! W00t!