Dave Newman

0 notes &

Run bash scripts on Heroku

So all I wanted was to run a script every 10 minutes to check whether Mojang had gone and released a new version of the Minecraft server. This helps us stay on top of updates at Minefold.

Here’s the check in it’s entirety:

Check the etag on the minecraft server, check it against a value stored in OpenKeyval and if it changed use twilio to send me a text. Simple!

I wanted to run this check on Heroku since most of our stuff is running there days and it makes life so damn easy.

The trick to getting this running on Heroku is to use Keith Rarick’s buildpack: https://github.com/kr/heroku-buildpack-inline

This neat little buildpack allows apps to build themselves. Since all we need on the dyno is bash and curl, our app doesn’t need to install anything. All we need is basically empty scripts in bin/detect, bin/compile and bin/release.

This might be the smallest slug on Heroku.

Check out the code on github

UPDATE Ryan Smith pointed me to his null buildpack which makes it even simpler.

Filed under minefold minecraft heroku

3 notes &

From LUA to JSON

I was planning on writing an article about how to integrate LUA into a game using iPhone Wax. This is how I wrote the AI for iBots Launch and how I wrote the first prototype of Chicken Pox. There were a few advantages to this strategy but I think in the end there were a lot more disadvantages. So this is an article on why I’m not using wax or LUA any more.

Why use LUA anyway?

I’m used to coding in ruby and javascript which are much more concise languages with a lot more runtime flexibility than objective-c. Also I really like using closures and I was targeting iOS 3.2 so no blocks.

The other main reason is I wanted a run-time interpreter. I’m a firm believer that shorter development cycles have a massive productivity boost. My goal is to get the time it takes to make a change and see it running live down to zero. In iBots I could telnet into the game and execute arbitrary code which helped a lot during development (Thanks Miguel!).

So what where the problems??


Compared to the visibility that Xcode’s Instruments gives you over your objective-c code, LUA is a black box. Wax does some really clever object mapping between the two languages and releases and retains objects as necessary. Unfortunately you can run into situations where LUA is holding objects alive and it’s hard to see why or where it’s happening. I ended up spending a fair amount of time debugging LUA code in iBots Launch looking for retained variables.


This was fine for the AI code in iBots, but I wrote 99% of the Chicken Pox prototype in LUA and it was sloooooooow. It’s hard to say whether the speed issues where in the LUA VM or the iPhone Wax bridge but it was clear that it wasn’t the correct approach.

So where to now?

Right now i’ve rewritten Chicken Pox in objective-c and it’s back to 60Hz and plays much nicer.

I’m also trying to tackle the live updating with a different approach. Instead of running arbitrary LUA code at runtime I’m limiting myself to live updating data. My scene graphs are defined in json files which look something like this:

  "GameScene": {

    "children": [{ 
      "name": "hud", "type": "layer",

      "children": [{
          "type": "sprite", "frame": "pause_menu_bg.png",
          "position": [291,142],

I then have the game start a zeromq server when it launches, I start a local filewatcher to watch the json files, and anytime I edit and save a file I transfer it to the device which parses it and updates the scene graph. This also works for arbitrary data which when used with KVO makes live changes possible.

Stay tuned to see some more detail on how this stuff works because it’s really fun!

Filed under idevblogaday

3 notes &

Free as in Ads

This is my second post in the idevblogaday series and it’s going to be a short one because I’m at WWDC and I’m writing this post at the NGMOCO night of meat!

For those who caught my last post in the series you’ll know that our iPad game iBots Launch has been getting less than stellar sales. After a decent initial peak the number has fallen to roughly 10 sales a day.

So as an experiment I decided to make the game free for a weekend and see what difference it made. Well I can tell you it made quite a difference:

In just two days I had received around 30,000 downloads. Interestingly most of these were from China. I’m not sure exactly why, maybe there was a Chinese blog feature, maybe they just love robots!

It was a crazy two days, I got to watch the game cruise up through the charts again. I was especially fascinated this time because I had done zero marketing beyond making the game free. I did notice that there were a lot of twitter robots that announced that it had gone free but beyond that I can’t account for the rise in ranking.

Anyhoo obviously I haven’t been monetizing this game correctly!

So I’ve decided to try providing the game for free with iAds. The last few days have been spent adding ad support to various parts of the game and analytics to help me understand how people play it. As of today I’m ready to submit an update to the app store. 

Stay tuned to see if I can turn my financial situation around with the new strategy!

Ps. I have a few technical posts up my sleeve, one exciting piece to look forward to is a system that live updates the game while it’s running on the device. I have been using this system a lot in the development of our upcoming game.

Filed under idevblogaday

5 notes &

Automate your iOS projects with rake

Rake is make for ruby, but it’s so damn good I use it on every project no matter what language i’m in. Ruby is the perfect glue language for getting stuff done and Rake makes it easy to write a set of tasks for each project. It’s also convenient because it’s already installed on Mac OS X!

Today I’m going to show how we can create tasks to build spritesheets from images, build the app and publish it to TestFlight for beta testers.

Building spritesheets

I like to build my spritesheets based on directory structures. This makes things easy to manage, just group sprite files into directories and they get combined into spritesheets. Something like this:

├── spritesheets
│   ├── charlie_walk
│   │   ├── charlie_walk.00.png
│   │   ├── charlie_walk.01.png
│   │   ├── charlie_walk.02.png
│   │   ├── charlie_walk.03.png
│   │   ├── charlie_walk.04.png
│   │   └── charlie_walk.05.png
│   ├── charlie_run
│   │   ├── charlie_run.00.png
│   │   ├── charlie_run.01.png
│   │   ├── charlie_run.02.png
│   │   ├── charlie_run.03.png
│   │   ├── charlie_run.04.png
│   │   └── charlie_run.05.png

In this example I’m combining animation frames into spritesheets. I use TexturePacker to create spritesheets. Using command line tools like this is great, it keeps things flexible and easy to change.

So here’s a Rake task which extracts path information and uses that to build the spritesheets:

This will create cocos2d specific spritesheets but can be modified for other formats. It also creates the retina spritesheet at full resolution and a half scaled one for older devices. Now first lets see how we can list out the available tasks:

⚡ rake -T
rake spritesheets:update  # Recreates spritesheets that are out of date

Cool, so it tells us that we have a spritesheets:update task, let’s try it out!

⚡ rake spritesheets:update
Writing sprite sheet to assets/spritesheets/charlie_walk-hd.png
Writing data for cocos2d to assets/spritesheets/charlie_walk-hd.plist
Resulting sprite sheet is 256x1024.
Writing sprite sheet to assets/spritesheets/charlie_run-hd.png
Writing data for cocos2d to assets/spritesheets/charlie_run-hd.plist
Resulting sprite sheet is 256x1024.

Alright! Now if we want to change the spritesheets, it’s just a matter of regrouping the sprite files into directories and running that task.k.

Auto build and publish to TestFlight

Another great aspect of using Ruby is you get access to thousands of gem packages which are really easy to install and use. We’re going to use wox to help us out now. First you need to install the gem. This is as simple as:

⚡ gem install wox
Successfully installed wox-0.0.8
1 gem installed

Now we can require this gem from our Rakefile and use it to configure the build:

# Rakefile
require 'wox'

# make sure the info_plist argument points to the right file! 
Wox::Tasks.create :info_plist => 'assets/Info.plist' do

This will create a few tasks for us, let’s have a look:

⚡ rake -T
rake info:configurations  # List available configurations
rake info:sdks            # List available sdks
rake info:targets         # List project targets
rake spritesheets:update  # Recreates spritesheets that are out of date

There’s a few info tasks there, let’s see what they tell us:

⚡ rake info:configurations

⚡ rake info:sdks

⚡ rake info:targets

Ok, so lets create a task which will build the chickenpox target in Release mode with iphoneos4.3 sdk. Wox makes this fairly simple:

Wox::Tasks.create :info_plist => 'assets/Info.plist' do
  build :release, :configuration => 'Release', :sdk => 'iphoneos4.3', :target => 'chickenpox'

⚡ rake build:release
Building chickenpox 0.2 configuration:Release
Success. Results in build/build-Release.log

Great! Now we have a build we can run from the command line which we could easily call from a Continuous Integration service like Jenkins.

The last step is to create the ipa file and have it publish to TestFlight. In order to do this we’ll need a couple of things. For the ipa we need to know which developer certificate and provisioning profile we want to use to sign the app bundle.

For the TestFlight publish you need your API token and Team token. Grab the API token from the Account page. The Team token you can get from clicking edit next to the team on the top left.

Now change the wox section of your Rakefile to this:

Now we have some extra tasks:

⚡ rake -T
rake build:release        # Build chickenpox 0.2 with Release configuration
rake ipa:adhoc            # Creates build/chickenpox-0.2-Release-adhoc.ipa
rake testflight:publish   # Publishes build/chickenpox-0.2-Release-adhoc.ipa to testflight

Let’s try it out!

⚡ rake testflight:publish
Building chickenpox 0.2 configuration:Release
Success. Results in build/build-Release.log

Creating build/chickenpox-0.2-Release-adhoc.ipa
Success. Results in build/ipa.log

Publishing to TestFlight
File: build/chickenpox-0.2-Release-adhoc.ipa (1.0 megabyte)
Accessible To: Internal
After publish will notify team members
######################################################################## 100.0%
Success. Results in build/testflight.log

This one command line now builds the app, creates an ipa file, uploads it and sends emails to all of your beta testers with a link to install the new version. TestFlight is an amazing service, if you’re not signed up you’re missing out!

That’s it for now, feel free to share any more automation tips in the comments.

Filed under idevblogaday

29 notes &

The development of iBots Launch

I’ve spent the last 10 years as a web developer. My partner in crime (actually graphic design) is a lawyer. What the hell were we doing creating an iPad game!?

I’d wanted to make games since I played King’s Quest when I was 12. My first “game” was a double dragon remake for the commodore 64 with ascii graphics. My older brothers thought it was hilarious. When I got a 486 pc it was all about plasma fires, spinning cubes, starfields and the mandelbrot set all lovingly coded in Turbo Pascal 6.

A taste of real game development came during University. We had a PS2 running linux and a fat manual on how the chips worked. It took me a week to get a 10 line assembly program running that wouldn’t crash the system. It took 2 minutes for the system to restart. I loved it.

The days and nights of Uni game dev ended alas and I was thrown into the real world, where the only offers of professional game dev positions I received seemed to consist of 80 hour weeks and a janitor’s salary. At the same time there were all these companies offering comfy positions with good pay, all you had to do was code .net!


Fast forward 10 years

I’d been making good money as a .net consultant for a while now and I was at the end of a contract. I had cash in the bank, a buddy I grew up playing video games with who had an eye for design and an iPhone in my pocket. It was time.

Day 1 was exhilarating

We knew the game we wanted to make. It was a remake of an old arcade game we’d sunk a lot of coins into. We were going to make it exclusively for the iPad. In 4 hours I had a running prototype:

An early prototype

This was going to be totally awesome.

Andy started rushing to get graphics in. Years of design projects on the side had given him wizard like photoshop skills. We also knew where we needed help.

The theme: super cool futuristic action space game. With robots. We needed 3d models. Luckily you can buy them fairly cheaply from turbo squid. We found an animator who we worked with remotely to rig up the characters and create all the animations we needed.

The next 6 months

Given that I had a working prototype in 4 hours, I didn’t expect it to take six months to get the game out the door.

The first problem I had to tackle was learning Xcode, objective-c and cocos2d. Luckily I like learning new languages. I had a pretty thorough understanding of c, c#, javascript and ruby plus I was casually familiar with a lot more languages and language patterns. It took me some time to get up to speed with manual memory management but I’d used smart pointers before in c++ so I understood the concept. Xcode itself wasn’t too bad, but I did miss a lot of things from visual studio.

Cocos2d turned out to be a fantastic choice. It’s put together really well with an intuitive API. The community is large and active too. I strongly recommend looking at it for 2d games.

The Tortoise and the Hare

We rushed our prototype to a visually polished game in a few months. We had the menus done, full graphics and animations for all the characters, the sounds and the soundtrack all in place.

There was a problem though. The game wasn’t fun.

The controls are too hard!

We reworked the controls three times. Each time we created new graphics and recoded the control code.

We need powerups!

We did the powerups twice. The first time we had them activate as soon as you picked them up. But this didn’t work well because we wanted to have offensive and defensive powerups and the defensive powerups you wanted to wait to use at the right moment.

We need a single player mode!

This was a pretty late addition and some of the most difficult code I wrote for the game. I tried to make my life easier by embedding Lua to write the AI so I could iterate faster. This turned out good and bad. I was able to get the AI up and running a lot faster than if I’d coded it in objective-c but now I had some tough memory leaks to track down.

Instruments in Xcode gives you some pretty amazing tools for tracking memory leaks and performance issues, but with the Lua VM it was a black box. After a lot of trial and error I did get the memory issues sorted out but I spent a lot more time on that than I would have liked.

The release date kept getting pushed back. Like the fabled hare we’d rushed too fast to the finish line when we should have been iterating the game design much earlier. This was much longer than we intended to be in development for and we sorely wanted real market feedback to justify further development. We had to make some tough decisions, cut out a lot of things that we wanted to ship with and just get the game out the door.

Show me the money!

So we released! I announced it on twitter, facebook, my blog, forums I used and told as many people as I could. The spike up was fun. Thanks to App Figures I was able to obsessively watch the game rise through the rankings.

We got a very thorough and positive review on Touch Reviews. Also the app store reviews from around the world were fantastic:

LOVE LOVE!!! Just got my iPad, one of first games I’ve downloaded & I’m totally addicted!

Fast fun and furious…. This is what iPad was made for ! I think this game ROCKS. I’ve bee looking for a good fast pace multiplayer game to play against my kids and whoop my wife at too :-). The game is great even the AI is very challenging. Make sure you play in ARCADE mode cause that where it’s at !!! Great action very polished and balanced gameplay and the perfect balance of power ups. Well done developer, this is what the iPads touch screen is perfectly suited for.

Très bon surprise ! Simple mais diablement efficace ! Jouabiliter au top, et très tactique. Possédant le jeu de hockey (le très connu), et étant fan de ce genre de jeu “2 joueur 1 iPad” je ne peu que sucomber a cette approche plus tactique et plus maniable de ce jeu.

Unfortunately this didn’t translate into great sales numbers:


We made it to #45 in Games in Australia which is where I live and I was pretty happy with that. And then we crashed! Unfortunately we didn’t make much of a dent in the US rankings.

We did get the feedback we were looking for though: The game has potential. People liked it despite its flaws, and for a few days there it sold OK. If it had climbed as high in the US as it did in Australia and the sales were maintained I would be a happy man and wouldn’t have to go straight back to building web apps to pay the bills!

What needs to be done

I think there’s a pretty good game hiding in here. Here are a few things I know would improve the game:

  • More content. Levels, characters, in game variations
  • A more interesting single player game. Tournament style, rewards/achievements
  • Internet multiplay. Challenge a friend or stranger, have a worldwide leaderboard.

More reviews and ratings and press wouldn’t hurt either.

What I learned

While the game hasn’t bought me an island in the Caribbean, staffed with robot servants, it has provided me with one piece of knowledge:

Transitioning from a freelance web developer to a self supported indie game developer is not a pipe dream.

I’ve had a taste of the app store market and I want more! There’s a lot more work to be done, on this game, on the next one and the one after that. But I’m not giving up.

Filed under ibots idevblogaday

12 notes &

The Wizard strikes again!

Continuing my quest for automating everything via the command line I present to you:

The Wizard of Xcode!!!

I extracted the build tasks I use on iOS apps into a handy library and dsl you can use in your own Rakefile. This will let you set up rake tasks to build your app, create ipa files and publish to testflight.

Looks something like this:

$ rake -T
rake build:debug          # Build angry_turds 0.1 with Debug configuration
rake build:release        # Build angry_turds 0.1 with Release configuration
rake info:configurations  # List available configurations
rake info:sdks            # List available sdks
rake ipa:adhoc            # Creates build/angry_turds-0.1-release-adhoc.ipa
rake ipa:app_store        # Creates build/angry_turds-0.1-release-app_store.ipa
rake testflight:publish   # Publishes build/angry_turds-0.1-release-adhoc.ipa to testflight

Along with wod we’ll make sure you never have to click through silly web pages again!

For install and usage instructions see the README over on github

Filed under automation xcode rake cli

1 note &

iBots Launch Launches!

After about six months of hard work, sweat and tears I’ve finally let loose the iBots!


iBots is unique in that it’s designed specifically for the iPad and as a (mostly) two player game. It’s been compared to pong, air hockey and speedball but it’s most influenced by an old arcade game called Windjammers.

I’ll be posting updates on the game’s progress and also look forward to a project retrospective!

In the mean time, go buy it! ; )

Filed under ibots

1 note &

Introducing the Wizard Of Dev center

I’m slowly getting around to easing the pain of managing beta testing iOS applications. TestFlight has made one part of that process really nice and easy but currently there are a few friction points. One of those is creating a build and submitting it to TestFlight which I have a Rakefile for. Another part is managing the device list on the Apple Dev center.

Previously this involved going to the site, logging in, getting to the device page and then adding the UDID.

Well this is now as easy as:

$ gem install wod
$ wod devices:add "Dave's iPhone 5" 2d84d56ceg52c49379537413d3b9865ae2b12345

I’m going to add more functionality to this tool as I need it, but feel free to fork the code and add more features.

3 notes &

Write your cocos2d game in Lua!

Yep, screw objective-c. With iPhone Wax it’s now super easy to get Lua going in your IOS apps. I’m going to write more about how this works in the future, but right now I’m just going to link to my example app on github.


Here are the interesting parts:


wax_startWithExtensions(luaopen_wax_http, luaopen_wax_json, luaopen_wax_xml, nil);

Starts up the wax Lua environment. Also loads a few extensions.


waxClass{ "LuaScene", CCScene }
function init(self)

This is where the actual Scene is created in Lua. waxClass creates “LuaScene” as both a Lua object and an objective-c class.


[[CCDirector sharedDirector] runWithScene: 
  [[[NSClassFromString(@"LuaScene") alloc] init] autorelease]];     

Creates the instance of the lua scene in objective-c and runs it as normal.


Copies the data directory with all the Lua scripts into the application bundle.

Happy hacking!

Filed under lua cocos2d