Ugh, sorry for the lack of updates, I feel like I’ve been clawing my way through a giant pile of manure and have barely gotten my head out into the air.

If you recall, my current task on SpyParty has been to get the folks at the party to be able to pick things up, like books, magazines, martinis, cigarettes, top secret plans for a nuclear device, etc.  Well, steps 3 and 4 on that task were the following:

3.  Add non-character dynamic items as a concept to the code.
4.  Add a simple attachment system to the character AI and rendering code.

Oh boy.  These look pretty simple, but since I’ve been 100% focused on getting the gameplay prototyped, the actual game code had gotten a little, shall we say, funky smelling.  It was never very clean, having started from the Indie Game Jam 3 engine source code, which was not in great shape itself, but my singular focus on getting gameplay in without regard to how I got it in has made matters worse.

It became clear that I needed to clean things up before I could move forward.  My friend and executive producer at Maxis, Lucy Bradshaw, used to bristle whenever a programmer would mention the word “refactoring” because it had a perfect trifecta of badness1, but it was time.  I couldn’t figure out how to attach an object to another object in the old system without hacks even more heinous than I was willing to attempt.

This kind of task gets to the heart of the “game object system” issue.  I’ve got a good powerpoint by Doug Church on my site on the topic, and I’m going to write more about my new system soon, but I wanted to at least post something to indicate that I’m not dead.

Briefly, I choose a fairly simple component based object system architecture.  There are really two basic options when you’re doing object systems:  inheritance-based and component-based.  I’ll have much more to say about this later after I’ve used it for a bit and worked out the kinks, but for my usage I thought components were the way to go.  These terms are pretty loose; they don’t necessarily directly correspond to C++ (or whatever) definitions when you use them in this general way.

The other thing I am finally starting to test out is my new namespace-centric coding style I’ve been simmering on for the past 5 years.  I’ll also write more about that soon as well.  I’ve been styleless for a long time, after becoming dissatisfied with my previous programming style, and not seeing any others I really liked.

The final thing I wanted to mention was that even after 20 years of programming, I still need constant reminders to figure out ways to keep changes small.  I started writing the new object system and porting all the code over to it in one big change, and after bogging down in that for days and days, I finally rolled back to the old object system and figured out a way to incrementally change over.  It’s more hacked code in the interim with the two object systems fighting for attention, but having a compiling and working piece of software you can test incrementally is so important it’s hard to overstate.  I had two object.h’s in the project for a few days (the old one renamed to _object.h), but it let me move things over piecemeal and keep testing, and I was finally able to delete the old object.h last night.

Also, source code control is your friend and it saved me when I realized I’d bitten off more than I could chew in one bite during the refactor.  I currently use Subversion and have for years, but have been thinking about switching to Mercurial or Bazaar.  I wish these distributed systems dealt with large binary files like those found in games better, though.

1. 1) refactoring takes a long time, 2) it adds bugs to the code, 3) even when it works perfectly, it has no visible improvement on the game [↩]

Martin Davies from PC Gamer UK just posted an interview with me to accompany his SpyParty preview in the print magazine where I talk a bit about some of the aesthetic goals for the game and how it got started:

http://www.computerandvideogames.com/article.php?id=245666&site=pcg

And, Alice Bonasio from The Escapist posted an interview/article about games as an art form and film and comics and all the usual stuff I babble about incessantly:

http://www.escapistmagazine.com/articles/view/issues/issue_252/7496-Better-Than-Film

It’s really wonderful that people in the press are giving more and more attention to indies these days, I think it’s great for the industry.  I mean, not just because I’m getting some of it, but in general!  :)

According to this, the new PC Gamer UK has a SpyParty preview?

Anybody have a scan of it?

Update: As you can see in the comments, Simples was awesome and scanned it for us!

Continue reading ‘SpyParty in PC Gamer UK Issue 214’ »

I just read this interview with the Lost executive producers, Carlton Cuse and Damon Lindelof, and it’s got some pretty interesting comments in it that relate to some of my current thoughts about game design.

This first quote speaks to a concept Jonathan Blow and I talk about all the time when discussing game design and development, namely, bottom-up versus top-down game design, and listening to your game as you develop it and being able to react to what it’s telling you:

Lindelof: I think one of the most profound lessons I’ve learned over time as a show runner is that the more you listen to the show, the better your show.

I was struck that Lindelof used the exact same phrase when talking about developing Lost.  I’m being a bit hyperbolic here, but I think there’s a general belief in the game industry that you can top-down design games, that if your design document is good enough, you can just type it in, that making a game becomes predictable, but I really don’t think this is true if you’re going for greatness.  This is not to say you just start typing without any idea of what you’re going for, you definitely have to have aesthetic goals, but you need to have the freedom to listen to the game.

I also think this is why hybrid developers, like programmer-designers, and artist-designers, and artist-programmers are more effective, because the game speaks to you at many levels of detail and in many languages, and you’ll miss some of them if there’s a tin-can-and-string telephone between you and the game…sometimes late at night the game whispers something to the programmer about design or to the artist about programming, and he or she needs to be able to react to it.

This is also related to the rant I gave at GDC this year; you need more than a few days of development for your game to start saying important things to you.

The Lost guys also talk about how much they knew when they were creating the early episodes, and this relates to the ability to react to how the show itself is coming together:

Lindelof: We have to have the answers to the mysteries so that there is something to work towards, but what we don’t have are the stories. J.K. Rowling can sit down and say, here’s how Harry Potter’s parents were killed, and here’s who killed them, but how am I going to reveal that information to the audience in the most emotionally impactful way? So we know what we want to do, but we have very little idea of how and when we’re going to do it.

There’s a really great Bill Moyers interview with David Simon about The Wire that touches on this topic in a very similar way:

Simon: And, you know, I’m not suggesting we have everything planned to the nth degree. But we knew, for example when we wrote that scene in the beginning of the first season, that by the end of the run those three characters would have been treated as pawns in a chess game.

And we knew that character that cited what was ailing post-industrial America, he happened to be a union captain and one of the longshoreman. That he would be speaking to, at the time, what we were reacting to with Enron and things like– and WorldCom and the first sort of– first shots across our bow, economically. That people were trading crap and calling it gold. And that’s what THE WIRE was about. It was about that which is– has no value, being emphasized as being meaningful. And that which is– has genuine meaning, being given low regard.

The part at the end of this also speaks to me, because I’m constantly thinking about how games can have deeper meaning.  The talk I gave last year at the IGDA Leadership Forum asked,” Why are we making games?”  It’s really clear, listening to these guys talk, that they have meaningful things they’re trying to say with their art.

Carroll: Do you still see that as the central issue, man of faith versus man of science?

Lindelof: The paradigm has shifted from that to, were we brought here for a very specific reason, and what is that reason?

They’re even thinking about how their audience is thinking about their work:

Lindelof: Locke is now the voice of a very large subset of the audience who believes that when Lost is all said and done, we will have wasted six years of our lives, that we were making it up as we went along, and that there’s really no purpose.

I think games occasionally try to do some self-referential things like this, like the protagonist in Uncharted 2 saying things like “I’m so sick of climbing stuff”, but it’s happening at a much more surface level, and it’s not directly speaking through the interactivity, the way we need to be doing to come into our own as an art and entertainment form.

On the topic of actually answering questions, and making the meaning plain, they understand the perils:

Carroll: Is there a worry that there exists questions for which any possible answer is not as interesting as the question would be before you knew the answer?

Lindelof: Absolutely.

This is something Brian Moriarty has lectured on in the past.  He’s a gifted presenter, and his lectures The Secret of Psalm 46 and Who Buried Paul? are master classes on the topic.  J.J. Abrams gave a TED talk about his “mystery box”, which is a fine talk, but not as good as Moriarty’s.

Finally, I think this is something Jonathan did really well in Braid.  Iroqouis Pliskin gave an excellent talk at GDC about his interpretation of the meaning behind Braid.

I’ll relate all of this back to SpyParty in a future post.  Or maybe I won’t.  :)

Let’s be clear:  I love making games, and I hope to do it for a few more decades, fate willing.

That said—like in other creative endeavors—the pursuit of awesomeness in game development is often mind-numbingly tedious and mundane.  Case in point:  my last week and a half.

It all started when I decided the next cool thing to work on would be to get the partygoers to be able to pick up stuff, like books, sculptures, drinks, cigarettes, and any other MacGuffins I come up with for the Spy missions.  Let’s ignore the fact that it’s 2010 and game developers still need to think about and do work to get characters to pick up objects in game worlds.  Sigh.

Okay, this seems like a reasonable short term programming goal that will allow me to further explore the design space.  For example, it will allow the characters to carry books away from the bookshelves, making it harder for the Sniper to keep track of what’s going on, etc.

Easy!  What could possibly go wrong?

I broke this high level task down into bite-sized components:

1. Add an event track to the animation system so the animations can tell the AI when the object should be attached.
2. Make an animation for picking up the object and have it fire an attachment event.
3. Add non-character dynamic items as a concept to the code.
4. Add a simple attachment system to the character AI and rendering code.
5. Write a quick full body IK system so the character doesn’t have to align with the item exactly1.
6. Hook it all up.

I start on Step 1, and get it done relatively quickly.  There was a bit of an issue of figuring out how to represent the event track in the modeling tool, but once I figured that out (with help from the awesome Ryan Ellis), it went pretty smoothly.

Okay, so next up, Step 2, the rough animation to pick up an item.  Of course, when doing an animation referencing an item in the world, you want that item in the view while you’re doing the animation.  I load up the pedestal with the statue on it into the file with the character rig, and get this:

That’s a very tiny pedestal you have there.

Hmm, that’s odd…

Continue reading ‘Game development is tedious, let’s go shopping!’ »

1. This is a step that might give some people pause, but I’ve written so many IK solvers over the years that I figure I can whip this out in a day or so.  Famous last words. [↩]