Wouldn’t this be interesting…
Mockingbird: iPhone Edition
Mockingbird
9
Oct 08
Madagascar: Escape 2 Africa: Mad Dash
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!).
9
Oct 08
Refactoring Mockingbird: Singletons
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.
5
Oct 08
Games and Themes
Danc had this to say on theme and game design.
I think what Danc is calling theme would be considered aesthetics by the MDA school of thought (which is how I break down interactive design).
I think it’s a bit unfair to compare games to books in regard to breadth of themes. There are more books by a factor of, I don’t know, a million, spanning the last millennium of human civilization? It would be a bit more interesting to compare the range to something filling a more equivalent role in cultural artifacts. You know, our old stand-by: movies!
I’m not going to pretend we’re on par with movies. But if you think about how many movies feature a variation on a cop and a criminal for it’s built-in context you’ll see our clustering is not so crazy. How many war movies? How many romantic comedies?
I do think Danc plays theme too much as a second fiddle to game mechanics. I think this is a trap many game designers fall into, much in the same way I’m sure many filmmakers do the same. We too often build a game from the mechanics outward, or claim that the mechanics and dynamics — the elements unique to our medium — are paramount to the end experience.
But thinking about Mockingbird over the last two years has cemented a very different perspective on theme/aesthetics and games in general. To the broader audience, theme is more relevant than mechanics. As a result, the broader audience is going to bond with your game due to its theme.
That is, if the mechanics and dynamics don’t get in the way. Think about movies: a bad director is noticed while a good director is invisible.
Myst is the ultimate example at one extreme of the spectrum. The mechanics and dynamics are so transparent as to be the fundamentals of web surfing: click on items of interest, maintain some very limited memory of previous items of interest explored, have some vague goal of curiosity pushing you forward. The reason people are drawn into it, though, the reason it made an emotional impact on so many people — besides its perfect timing in regards to presentation technology — is all in its aesthetics, it’s theme.
I have a presentation I’ve given a few times recently that has as its climax the declaration, “replay is a myth!” That’s followed-up shortly with, “gameplay is secondary.” Heretical ramblings? Trying to get a rise out of the audience? No. I believe it to be “the way things are.” I think that’s the reality that the game industry is not accepting as fully as it should.
I listen to regular people describe the idea of their own game. I remember when I “designed” games as a kid. Was I thinking about mechanics? No. I was, at most, mashing together a few similar games to get an idealized set of mechanics. The real “design” is in the aesthetics, the characters, the themes, the reason for playing, the relevancy.
Have I mentioned that I think games should be more relevant? ;-)
23
Sep 08
Richard Garriott’s Asteroids
Richard Garriott’s Asteroids as seen on the Colbert Report. I knocked this up in Mockingbird in about 10 minutes. Very hackish, just downloaded a Garriott picture from Wikipedia and an Asteroids screenshot, cutting out the various pieces. Dead simple.
3
Sep 08
BuiLD YouR WiLD SeLF
BuiLD YouR WiLD SeLF. Great example of avatar creation. Love the art style. I’d love to get a create-a-character this slick inside of Mockingbird.
30
Aug 08
How to get rid of mx:Script blocks in your MXML
UPDATE: Okay, so maybe I just wasn’t really paying attention when I’ve googled this in the past, or maybe I just know more about Flex now and I better understand what’s being discussed in the comments… but there’s a blog post about code-behind that draws exactly the distinction I outline below and in the comments, some of the Flash/Flex gurus go through the pro’s and con’s. It’s reassuring, at least!
I know, not a very clever title, but I want this post to be easily googled as I would have been elated to get this information 2 years ago when I started using Flex. If anyone know where I could find these details elsewhere, please let me know, as this is exactly the technique I’ve wanted for a long time.
There’s a debate in the Flex community about how AS3 code should be mixed with MXML. There’s a code-behind camp that suggests first creating a base class containing your AS3 code (in a .as file) which your MXML code then extends. This has all sorts of drawbacks, like having to declare all instances you want the AS3 code to access in the base class, which kinda defeats the whole purpose of separating the MXML and AS3! Then there’s the code-in-front camp that suggests having your AS3 code inherit from your MXML class. Same issues appear, though, just from a different direction.
And finally, there’s the more common approach of just using an ugly <mx:Script/> block in your MXML, which is ugly because AS3 code has to first be wrapped in a CDATA block because of the special reserved characters used (angle brackets, double-quotes) and things like “Organize Imports” doesn’t work. The end result is a very ugly chunk of non-declarative code in the middle of nice declarative XML.
Of course, some may argue that means you should just probably slice up your code along MVC lines and then you’ll have a minimal amount of code in your MXML. Sure, but the reality is that it’s never that straightforward, and besides, even with a proper amount of code I’d like to have the automatic import organizing.
And I almost forgot… when you’re working in a team situation it’s likely that the MXML and the underlying AS3 are developed by different individuals (designer and developer, respectively). Sure, the merging won’t be too heinous with the script block, but it would still be required (this is another argument for code-behind/in-front).
So today, entirely by accident, I found the solution. If you include an AS file from exactly one other file (either an AS or MXML file), the Flex Builder editor will treat that included AS file as if it was actually in that file in regards to auto-complete. In other words, if you hit CTRL+SPACE while working in the include file you’ll get the context-appropriate auto-complete pop-up as if the file was already included where you used the include directive. If you refer to the included file from two different places in your code, then it won’t work (you get whatever is common between the locations).
Oh yeah, and organize imports works perfectly.
So, now in your MXML files you can just do this:
<mx:Script source="my-source-code.as" />
And put all your AS3 code there, neatly tucked away from all your MXML. Nice. All you gotta do is come up with a naming scheme to keep your AS and MXML files grouped (for your convenience only). The MXML compiler actually produces an AS file with the same name as the MXML file, so you can’t use that. But you can use a clever variation (that doesn’t appear to break anything). The pattern I’m using right now is this:
MyViewComponent.mxml
MyViewComponent.mxml.as
Cool, huh? It almost seems too good to be true. Am I missing something?
28
Jul 08
Mockingbird selected for Austin Indie Game Fest Showcase
Mockingbird: The Game Making Game has been selected for the Austin GDC’s Independent Game Festival Showcase. Looks like we’re in a pretty good crowd as well. I’m a bit curious about the inclusion of a few titles that are published by Gamecock (and, as far as I know, funded by them as well). It raises (again) the question about what’s an indie game/developer and what’s an indie that’s simply “new”. I’d love to hear what people think (in the comments), in particular if anyone has any links to good discussions on the subject.
15
Jun 08
Mockingbird in the News
We showed up in the Austin American-Statesman for Tech Monday (out on the web this evening). Digg it. Spread the word. Check it out. Pretty good write-up.
UPDATE: I didn’t notice this, but there’s also a video clip. Interesting…
30
Apr 08
Mockingbird – The Game Making Game
Told you it’d be released in April 2008… ;-) Just barely…