Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Llopis and Friginal's Casey's Contraptions
View All     RSS
September 22, 2019
arrowPress Releases
September 22, 2019
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Postmortem: Llopis and Friginal's Casey's Contraptions

June 22, 2011 Article Start Previous Page 4 of 4

4. Not Enough Unit-Testing

Noel is a big fan of unit testing and test-driven development (TDD). Those are some techniques we used in past projects to very good effect and something we definitely wanted to carry into Casey's Contraptions as well.

The goal was never to have 100 percent unit-test coverage or write every single line of code through TDD, but to write only the tests that would benefit the project. That usually meant some code that a lot of other code relied on (the game item management), or something complicated (toolbox interaction), or something prone to breaking (rope manipulation).

In the end, we slipped to the side of not having as many unit tests as we would have liked. Some things like object attachments kept repeatedly giving me headaches during development because of the complicated, untested code. By the time we noticed those problems and wanted to start adding tests, it was too late because some of that code relied on non-unit test friendly APIs like UIKit or Box2d.

We should have taken the time when those problems started appearing to start writing some tests and slowly refactor the code as we fixed the bugs and added new features. Instead, since we seemed to be constantly "just a few months away from shipping", we decided to skip that and definitely paid the price later on. We even shipped with a few off edge cases that we knew were buggy but we didn't dare fix weeks before submission.

We're already working on updates and and an iPhone version of Casey's Contraptions, so we'll continue dealing with that code for quite a while to come. We'll slowly introduce unit tests in areas of the code that we need to revisit during this time.

5. Fixed Price Model

The pricing model is something we went back and forth about several times during development. In spite the long-term success of Flower Garden and other free games with microtransactions on the App Store, we chose to go with a fixed-price model for Casey's Contraptions.

We thought our audience would appreciate a traditional fixed-price model better than a microtransaction-based one. We also figured it was a model that was working well for other similar iPad games such as Angry Birds or Cut the Rope, so it made sense to follow their lead on that.

Unfortunately it seems that might have been the wrong decision from a financial point of view. After a really strong initial launch, Casey's Contraptions dropped down the charts very rapidly after just a few weeks. Since revenue follows a very sharp exponential drop off, even being in the top 100 iPad games means very little revenue per day, and points to a very thin "tail" to the sales curve.

In spite of the bad reputation microtransaction games have in traditional game development circles, they're a lot harder to develop than single-purchase, fixed-price games. Not only do you need to implement very robust server features, but you need to finely balance the in-game economy, the pace of rewards, and the cost of new purchases. Our optimistic estimate was that it would add at least a full month to the development time (and given how our estimates were, it probably meant two months for real).

A possible alternative would be to have a traditionally-priced game, but offer new levels or locations as extra purchases. This would have been a lot simpler to implement, but it probably wouldn't have made much difference in revenue. Usually, only about between 2 and 5 percent of the players buy any extra content, so for microtransactions to really pay off, they need to be unlimited (in-game currency, fertilizer, etc), or have a very large user base. With a small, fixed amount of possible things to buy, we would need to rely on having lots of players to make much of a difference.

We're hoping releasing the iPhone version will generate lots of renewed interest in Casey's Contraptions, spur lots of sales on both platforms, and hopefully increase the long-term chart staying power. If that's not the case, we can always consider the possibility of experimenting by changing the pricing model in the future.


We're extremely happy with the development of Casey's Contraptions and with the initial launch. We managed to create a unique game around creativity that was very well received critically and from a sales point of view.

The first free update should be available by the time you read this. It adds the ability to share contraptions with everybody through the web site, as well as browing public contraptions, which should increase the popularity of that feature quite a bit. It also adds some of the most-requested features, such as multiple player profiles for all the parents playing Casey's Contraptions with their children out there.

Unlike a traditional retail game though, the story is far from over. What we do in the next few months will have a very significant impact on the long-term success of the game.

Data Box

- Release date: May 19, 2011 (iPad). Summer 2011 (iPhone)

- Development time: 8 months

- Team size: 2 (full time)

- Development cost: Cost of living for 8 months + a tad over $1000

- Open source code: Box2d, UnitTest++

- Primary tools: Xcode, svn, Versions, Trac, TexturePacker, Adobe Illustrator, Audacity

- Lines of code: 46,518

- Raw asset size: 510 MB

- Total app size: 12.2 MB

- Subversion commits: 2442

- Trac tickets closed: 683

- Gallons of tea brewed: 77

- Shots of espresso consumed: around 1500

Article Start Previous Page 4 of 4

Related Jobs

Insomniac Games
Insomniac Games — Burbank, California, United States

Lead Environment Artist
University of Exeter
University of Exeter — Exeter, England, United Kingdom

Serious Games Developer
innogames — Hamburg, Germany

PHP Developer - Tribal Wars
Insomniac Games
Insomniac Games — Burbank, California, United States

Sr. Project Manager

Loading Comments

loader image