Phil Hassey - game dev blog
Phil Hassey as Wolverine
"What kind of
arrogant jerk
has a website like this?"

Archive for August, 2011

Day 1: Random side-hobby game for iCade

Wednesday, August 31st, 2011

Hey, 90 minutes later, I have this, with working iCade controls to cruise the ship around the endless galaxy!

Totally fun messing with a hobby game project!


From 0 to iCade in 3 hours 16 minutes

Tuesday, August 30th, 2011


1. The Arrival and Assembly (30 min)

So my iCade arrived at 2:58pm today. It took me 30 minutes to unbox the parts and put the whole thing together with a hex-screwdriver. The completed item looks 110% win!!! There are tons of detailed unboxing guides on the internet, so I’ll just give you a shot of mine:

2. Testing it out with GAMES (30 min)

I had to check it out with a real game, so I went to the definitive touchArcade post on the subject. I realized I already had several of those titles on my iPad, so I dove right in with Velocispider which was totally awesome on the iCade!! I can only hope more devs add support! 30 minutes elapsed “fun time”.

3. Downloading the iCade SDK (1 min)

The “official” SDK is sort of useless, it’s just a manual telling us what we already knew. The great bit is there is an Open Source SDK (MIT) that is ready to go! I downloaded and unzipped that and began adding it into my project. 1 minute.

4. Being stupid (2 hours)

I then proceeded to brilliantly comment out the two lines of code that make the iCade code work. And then spend 2 hours realizing it. /facepalm

5. The iCade Integration (15 min)

Once I fixed my error, the integration took approximately 15 minutes. The bulk of the code was just a switch statement that converted the iCade SDK events to my own internal framework events. I already had keyboard support, so it was no trouble at all.

- (void)setState:(BOOL)state forButton:(iCadeState)button {
    int v = 0; unsigned char c;
    switch(button) {
        case iCadeButtonA: v=KEY_a; c='a'; break;
        case iCadeButtonB: v=KEY_b; c='b'; break;
        case iCadeButtonC: v=KEY_c; c='c'; break;
        case iCadeButtonD: v=KEY_d; c='d'; break;
        case iCadeButtonE: v=KEY_e; c='e'; break;
        case iCadeButtonF: v=KEY_f; c='f'; break;
        case iCadeButtonG: v=KEY_g; c='g'; break;
        case iCadeButtonH: v=KEY_h; c='h'; break;
        case iCadeJoystickUp: v=KEY_UP; c=0; break;
        case iCadeJoystickRight: v=KEY_RIGHT; c=0; break;
        case iCadeJoystickDown: v=KEY_DOWN; c=0; break;
        case iCadeJoystickLeft: v=KEY_LEFT; c=0; break;
    Event e;
    e.v = v;
    e.c = c;
    e.type = state?EVT_KEYDOWN:EVT_KEYUP;

I also had to go ahead and add Universal (iPad) support to the game, this didn’t take too long as my framework has smarts for doing that pretty easily.

6. In conclusion …

I’ve submitted my update to the App Store, so hopefully it’ll be in your hands within a week.

In conclusion, integrating iCade into your iOS game only takes 15 minutes, unless you’re as stupid as I am. I encourage all devs who have appropriate games to do this so that I can play more games on my iCade!!! Go GO GO GO!


Scaling custom WordPress: the lessons learned

Thursday, August 25th, 2011


I’m the dev / admin behind the Ludum Dare 48 hour game developer competition. This past weekend our competition grew from 350 contestants to 600 contestants thanks to @notch. Not only that but his live video blog of the event and twittering drove a TON of people over to the site just to spectate the event. This led to a ton of press coverage on. In short, 48 hour game development BECAME a spectator sport. Which is totally not something I had anticipated – here’s a completely inaccurate motivational poster I created a few years ago:

Anyway, that wasn’t the case, and this is what happened. (Short version: $8 shared hosting server burned to the ground and we got kicked off and had to find greener pastures, and then do a ton of optimizing.) I want to give a shout out to Mike Kasprzak for keeping the masses at bay and helping to endlessly test the site and hold my hand while I worked through all the mess. Here’s the lessons learned:

1. Profile site database use.

You can find out what queries are killing your site by using the WPDB Profiling plugin. This was a HUGE deal for us. We were able to see exactly what queries were destroying us. Without any debate this is the #1 tip I have, because if you don’t know what the problem is you can’t fix it!

2. Remove inessential plugins.

Not all WordPress plugins are developed with massing scaling in mind. We found by disabling all the plugins except for the essential plugins we were able to go much faster. Not only that but even efficient plugins add a CPU drain to the site just by having their PHP files loaded.

3. Clear out the sidebar.

Sidebar stuff can also be a huge drain. We just plain removed the sidebar for the competition. We’ll probably re-enable some of it eventually, but be careful, even some of the WordPress issued functions have some monster queries in them.

4. Optimize slow 3rd party plugins.

One plugin we wanted to keep using I like this is really cool, but it uses a table that is not indexed and it adds an extra query per-post on the front page of your site. I indexed the columns in the custom table it had as well as removed the unnecessary per-post query it was issuing. Now we can use that cool plugin without any notable slowdown. Here’s my bug report / patch.

5. Add in custom caching to 3rd party plugins.

Our custom competition plugin was really un-optimzed. I had written it to just work, and it worked great under low load. I used a number of techniques to reduce the load:

– I added in my own mini profiler so I could track how often certain functions were being called and how long they were taking. This helped me track down the issues to an even finer detail than I was able to with the WPDB Profiling plugin.

– I was using the get_userdata($uid) function from WordPress as many as 600 times on a page, so I cached that data with the records in my database so I would almost never have to call it, that was probably the biggest issue and was causing 600 database queries on those pages.

– I added paging to the various views so that instead of seeing all 600 entries at once, you only see 24 at a time, this really reduced load in terms of queries and images being loaded off the site in one request.

– I also added some page caching for the few pages that calculate results, this is largely a CPU save because generating those pages is pretty intensive

6. Be smart with 3rd party caching solutions.

Pre-made caching solutions for WordPress can’t save you if your site is largely driven by custom plugins and signed-in users using web apps (like our compo system), in fact those caching plugins actually can slow down the site quite a bit. They are designed more for static content blogs (which is more typical for blogs) and probably work great for those, but for us they didn’t work so hot.

… Conclusion.

I’m now quite happy with how the site is performing. We’ve reduced the load on our new VPS from 70 or so (meaning that we had about 30x as many processes wanting to use the CPU as the server could handle) down to about 0.5 which means we’ve got room to handle spikes again. I hope 🙂


The Exterminator – game for charity comes to App Store!

Wednesday, August 17th, 2011

Phil Hassey from Galcon-land here. A game I developed with five teens for charity just went live on the App Store! The game is an effort to help raise the $200,000 needed to get the down payment to buy a building for a local community outreach center in Rye, CO.

The game is called “The Exterminator” and it’s about a motorcyclist defending the earth from mega-sized mutant bugs. It’s an endless runner-type game with a totally rocking original electric guitar soundtrack. The gameplay is super addictive and feels a bit like a 1942 + Canabalt mashup. If you get going over 75 MPH it goes into “guitar-solo” mode where all points double. Combos (sequential shots without misses) gain you increasingly more points. For fun I added in GameCenter leader boards so you can compete with your friends. It’s only $0.99 and all the money we get goes towards the building fund. (Apple’s take is 30%.)

Developing the game with the teens was a really great experience. The project started out with us discussing what charity the teens wanted to raise funds for. The group was unanimous that they wanted to help raise money for the local community center because it would give future teens a great place to hang out. Rye, CO is a small rural town and there aren’t any actual hangouts outside of school activities.

After that we decided on a game theme. Wes really wanted to do a motorcycle oriented game and Shamoa was interested in some kind of game where we’d destroy mutant bugs. By combining those ideas we came up with “The Exterminator.” From there we spent two days developing the artwork, music, sound effects, and the actual game. Matt put together the electric guitar soundtrack using GarageBand. Wes, Shamoa, Shadrack, and Cameron all worked on the artwork. Most everyone did some sound effects. We also spent a lot of time eating food and generally goofing off. We wrapped up the project with some solid play-testing and tweaking and we were all really happy with how it came out. As a game developer I totally enjoyed the experience of working with teens and developing a game idea that I would have never come up with on my own!

Here’s a page that includes an overview of the community center plans and includes a PDF with a more detailed description.

Charity aside, it’s totally fun, so be sure to check it out!

Have fun!

P.S. I’m “philhassey” on GameCenter, just try and beat my score!

Press pack with screenshots, icons, etc