Last week saw the launch of Club Treasure World, the latest project powered by Mockingbird. Built in collaboration with Aspyr over the last four months, it’s the biggest project yet using our game making tech.
I suggest visiting CTW to get the full run-down of what’s offered, but a quick description: CTW is place for kids (and adults!) to build their own games and “chat worlds” to share with their friends. Everything is built from treasures that folks can purchase through micro-transactions or earn using the Nintendo DS game Treasure World which Aspyr shipped last year.
CTW was the first project I used Robotlegs on. Even though we didn’t use it extensively—the other developer on the project was not familiar with dependency injection—it provided a nice solid architecture to jump off of. And due to its minimal nature, even when we weren’t leveraging it, it was never in the way.
While we were working on this project I also started several other smaller projects leveraging Robotlegs (none yet released) and have gradually refined my own workflow with it. I’m still a fan, though I’m quite curious about Swiz because it appears to be even more minimal, if that can be believed. I am completely sold on the idea of dependency injection and have started applying it to my API designs.
My latest Robotlegs project is also my first project to leverage Rob Penner’s excellent AS3 Signals. These two together have significantly cleaned up my code and are definitely quashing many of the architectural issues I ran into when developing the original Mockingbird app. In fact, I’m itching to go back and rebuild the whole app and site—not to add features but to clean up the codebase in such a way that it’d be ready for some rapid feature addition in the future. Robotlegs definitely provides a very agile framework.
For CTW we also used SmartFoxServer for the first time. In the end, I was less enthused about this choice. While it got us up and running really fast with it’s simple API and built-in chat functionality, it was a pain to develop with and debug, and I wouldn’t choose to use it again. The API originates from AS1/AS2, so there’s very little type safety and none of the current AS3 conventions. The documentation leaves out a huge amount of caveats present in the API that don’t necessarily make sense, even though it’s clear from the support forums that developer after developer encounter the same issue. The next time around I plan on using a more robust option, like ElectroServer, or possibly the still-in-alpha Union Platform.