Of course, I don’t think these are as *indie* as games could/should be, but compared to EA or Activision, I guess they’re indie enough: Indie Video Game Developers Have Room To Play.

The Database Programmer: Minimize Code, Maximize Data: an excellent description of something I’ve learned as I’ve worked with game development tools over the last 10 years (warning: quickly becomes SQL-focused). It always distinguishes game makers who come from an art/design background and game makers who come from an engineering/scripting background.

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.”

Text-to-Movie by xtranormal. Very cool. Reading the “about us” page sounds familiar. They’re clearly wanting to do the same thing with movies that we’re doing with games.

Nice metaphor they’ve taken advantage of is the notion of a “script” (i.e. typed dialogue and stage direction) as a fundamental component of movies. People get that, they can wrap their heads around it. I think we’re close to finding the same thing with games, but the metaphor is not quite as concrete yet.

In my last post, I suggested that someone needed to update the Obama game to feature McCain and Palin. Well, since no one jumped on that suggestion, I did…

Obama Is Campaigning on Xbox 360!. This is so last spring… we launched with a user-generated Obama game! Now someone just needs to change this one to feature John McCain and Sarah Palin…

I’ve seen this discussed several times in my REST research (including the original REST paper), but I found this to be the most straightforward explanation of why it’s advantageous:

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…

Mockingbird was the first end-to-end Flex application I’ve built, and definitely the largest application I’ve built using any technology. Over the last two years, I’ve learned a whole lot about application architecture.

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.

Wouldn’t this be interesting…

Mockingbird: iPhone Edition

A few days ago, our first “advergame” was launched built on top of the Mockingbird platform:

Madagascar: Escape 2 Africa: Mad Dash

We worked with Addicting Games and DreamWorks to build a small make-your-own-level platformer. Short and sweet, nothing too complicated. It was a good first exercise, though, as it demonstrated areas I need to streamline in the code so as to be more flexible for future branded experiences.

If we’d had more time (and a bigger budget) I would have loved to build a more customized UI. Our ‘kits’ UI is designed to accommodate a lot of personalization of any random game off our site. For this version — which is very strictly focused in order to put their IP in the best light and to prevent “subversion” of it — we could have rolled something quite a bit more fun and engaging with the same underlying functionality.

That being said, I’m pretty happy with the results. And better, Addicting Games and DreamWorks seem to be *very* happy with the app. We’ll see how it does over the next few weeks to find out how good of a promotional item it is for them (and us!).

I’m starting the process of refactoring the core and components of Mockingbird. Now that we’ve settled on a featureset and UI, it’s time to go back and clean up all those unused abstractions, unnecessary architecture and *hacks* that litter the code (the byproduct of a single engineer writing all of it!).

First up: singletons (or any global state). I’m a big OOP fan. I’m a big pattern fan. I’m a big GOF fan. I don’t like singletons. Or rather, I don’t like programmers pretending that singletons are “good OOP” and that they’re somehow different than old fashioned globals. I’ve always reminded other developers, “if you’re using singletons as globals, that’s fine, it’s the proper way to do it in an OOP language. But don’t kid yourself! It’s a global with different syntax! It’s got all of the same problems!”

Singleton I love you, but you’re bringing me down | // Coding Without Comments.

This article really sums up everything much better than I could and is what inspired me to write this post. Mockingbird’s singletons have nagged me for a long time, and I resisted having them for a long time before then. I was basically using Dependency Injection, which worked, but felt like more typing and repetition than necessary for the *potential* of configurability down the road. I eventually caved and refactored those parts of the architecture around singletons. It simplified the code quite a bit (in the short term), and made prototyping much faster as I now had a nice global dumping ground for quick hacks.

But, it’s definitely given the code an awful smell. And it’s made it very brittle. Up until I saw the above post, my plan was to just convert everything back to Dependency Injection and just live with the extra boilerplate. But, there’s a better route! Factories!

So, in the above post there’s a link to the blog of the testing expert over at Google. His suggestion is to never mix object construction with logic. Simple, yes? Instead of manually handling dependency injection in each place where you need to construct an object (which has a cascading effect wherein you need more and more dependency injection!) you consolidate all of that boilerplate code to a factory. A clear example of separation of concerns.

Now, I used to be in love with factories. When I developed in C/C++ I used factories all of the time because it allowed me to consolidate memory management into the factory and strip all the mallocs out of my logic. But I cast that lesson aside when I moved to managed languages. But factories still solve the same fundamental issue of allocation as a *part* of configuration (which is what factories generically do). Obvious, yes, but I’d never seen it put quite like this.

Needless to say, it’s clicked for me. I’m now going to be introducing factories in lots of places inside of Mockingbird. Creating elements of our Game Object Model? Factory! Creating runtime instances? Factory!

To be honest, I was actually employing a bit of the factory pattern in most of the instances already. The problem was that I was not being formal enough about it, or rather I wasn’t *completely and cleanly* separating my concerns.