Game Dev


31
Mar 10

Club Treasure World

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.


29
May 09

TAG Presentation

I presented early this morning (7am!) at TAG Austin. Nice crowd, very interested, very receptive. I spoke for about 45 minutes, slides presented below.

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


8
Feb 09

The Unfinished Swan

The Unfinished Swan is a beautiful concept for a game. And, judging by the video provided, is being beautifully implemented. Within seconds of seeing it my whole perspective on first-person mechanics was flipped on its head.


19
Jan 09

Building Gaming’s Future

This morning I read Edge’s article on building gaming’s future. It’s a decent summary of the growing audience/market for consumer game making. Of course, we’ve been talking about this at Mockingbird for a few years now, but Edge really hits it home with all of their examples that it’s truly becoming a mainstream activity (for gamers).

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. ;-)


22
Dec 08

Deconstructing Adventure Games

Great article on the interface of Adventure Games, the components that go into them, and their evolution over time [via Kottke]:

Strange Horizons Articles: Searching Under the Rug: Interfaces, Puzzles, and the Evolution of Adventure Games, by Mark Newheiser.


1
Nov 08

Cute.

SIDEROLLER.


28
Oct 08

NPR story about “indie” game developers

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.


24
Oct 08

Minimize Code, Maximize Data

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


7
Oct 08

Magical Wasteland

Magical Wasteland. Wow. Simply the best video game writing I’ve ever read.


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? ;-)