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.

The presentation was broadly about Mockingbird, but Mockingbird-specific talk really just occupied the first and last five minutes, everything in between was a discussion of what games are, what their history and place is in human culture, what their potential is as a form of expression, and what elements of that expression are critical in order to make “making” as accessible as possible.

As with previous presentations, the slides by themselves may not be that useful, but for those that heard the presentation the slides should serve as useful reminders.

SWF Export from Keynote
PDF Export from Keynote

Needless to say, I’m bummed that we didn’t even warrant a mention, even though we were one of the first in the present push to get out there and do this. I’m cool with that because I know all of the other folks mentioned in the article (XNA, Whirled, LittleBigPlanet, Playcrafter) know who we are. ;-)

Virtual Worlds News: Mattel Developing Digital Network; Adding Game Creation to Funkeys.

I can say that we’re apart of the strategy mentioned in this press release, and that I don’t consider Mattel a competitor. :-)

Over the next week, we’re going to rework this version of Mockingbird and re-integrate it into our site. New things on the way…

Non-programmers only have data to work with so they solve their design problems by pushing different/more data into a fixed toolset. Programmers solve design problems by writing software. Unfortunately, the way software ecosystems work, the data-side of the equation is less error-prone and is the fastest to iterate on.

One thing we’ve tried to do with Mockingbird is build a game development toolset for non-programmers. Not folks who don’t program (yet), but non-programmers — folks who won’t ever be (by choice) programmers. HTML does the same thing (which Mockingbird is closely modeled after). That’s one of the big reasons “it works.”

Peter Williams – Hypermedia as the Engine of Application State.

Mockingbird’s REST API is pretty straightforward because documents are constructed on the client and the server API essentially just loads and saves whole documents. But it’s intriguing that it could be completely encapsulated on the server by simply doing what the server already does for humans…

As I’ve mentioned previously, we didn’t always have time to properly architect everything. Of course, I knew we’d pay a “code tax” on each shortcut. And boy, have we paid them over time. In order to make each new set of changes within a reasonable amount of time my previous hacks require even worse hacks!

In fact, code hacks are exactly the same thing as telling lies. They start small, but the more often you do it the more it snowballs. The hacks (lies) have to get bigger each time in order to incorporate (and compensate for) the earlier hacks (lies).

I’ve looked at Cairngorm many, many times over the last two years wanting to apply it to Mockingbird. At first, I didn’t have a firm enough grasp on Cairngorm to implement it effectively. And once I did, we didn’t have the time to refactor Mockingbird to leverage it.

Well, it’s time to pay the taxman.

Rapid and consistent development with Cairngorm and Flex. Definitely the clearest explanation of Cairngorm. It’s a tidy summary of the entire micro-architecture end-to-end. Also includes an example feature addition and its implementation. This is the sixth (and final) part in a series on Cairngorm that goes into all the pieces in more detail. Definitely recommended reading for the Flex developers out there.