GameDevBlog

More Press

A lengthy article on XNA and Schizoid here:

http://www.shacknews.com/extras/2007/032607_youtube_schizoid_1.x

And an article I participated in that has almost nothing to do with Schizoid here:

http://www.1up.com/do/previewPage?cId=3158264

Time Management Part IV: The Isle Of Dreams

Part One
Part Two
Part Three

Dave Allen, author of *Getting Things Done*, says that we should write EVERYTHING down.  Everything we ever think we might ever do maybe possibly someday. As a result, you end up with a long list of things you're never going to get to - paradoxically, writing a task down becomes a way of giving yourself permission to not do it!  We see this in the game industry as those priority 4 and 5 bugs and tasks. 

Mary Poppendieck, in this video (which I discovered thanks to Clinton Keith's blog), says the opposite:  having a long queue of things to do prevents agility, because you're so busy working on the next thing you don't have time to do the right thing.  She says to dump the queues.  "Dump them where?" a Google guy asks.  "On the floor," she says. "If you aren't going to get to them anyway, at least be honest about it."

If I had to choose between the two viewpoints, I'd take David Allen's.  A nice thing about getting those tasks you're never going to actually do onto the wishlist is it means you can stop freaking talking about them!  If you don't write it down, then the same conversation keeps popping up: 

"I think we should do this"

"It's a good idea but it would take too much time"

"Isn't there something else we can cut to get this in?"

"Didn't we have this conversation before?"

etc.

But if you get it on the wishlist, it becomes:

"I think we should do this"

"Yeah.  It's on the wishlist."

But that is a little disingenuous, isn't it?  Passive agressive, if you will.  You're saying "Yeah, we'll do that," when you know you won't.  It prevents an argument now but leads to disappointment later.

Lately, I've reconciled the two viewpoints like so.  Whenever a good idea is put on the wishlist, I'm honest about its chances:  "We'll put that on the wishlist, and I'd really like to get to it, but the truth is stuff on the wishlist almost never happens." 

"The Isle of Dreams," Richard Garfield called it.

And it seems like that extra dose of honesty really does help.  Because of it, we've been prioritizing features more accurately and more aggressively - the end result, a closer eye on scope.  Why that's important I'll get to in another article.

Writing these has been fun - it's like I've revived Manager In A Strange Land here in my blog.

Some Answers

How is the approval process going with Microsoft?

To get an Xbox Live Arcade game approved, there's various stages and greenlight meetings you have to get through.  First you've got to get somebody there excited enough to get it into a greenlight meeting in the first place.  We showed a prototype to a manager from the XBLA team and he was excited enough to evangelize it. 

The next stage is the "Concept Greenlight" - they regularly have a group get-together to review proposals and decide whether they want to pass on them or not.  Apparently, at our greenlight, we were the only concept that had a prototype.  So a prototype will definitely help you stand out.  "Don't build it and they won't come."  Our prototype, by the way, was only three man-months of work.

The next stage is a due diligence meeting.  Here, they want to establish that you can actually execute, and finish the game before your launch window.  Any red flags or concerns they have will be raised.  For example, they wanted to know how long we could survive if the game slipped;  they wanted to know if we had a test plan.  For us, I think it helped that everybody on the team has an established track record.

And that's where we are now.  Coming up later is the certification or TRC - the "technical requirements checklist" - all the console manufacturers do this.  And games that have network play have much more elaborate requirements than ones that don't.  It takes two weeks to get through cert - and if you fail, it resets.  You have to take another two weeks. 

What do you think XNA's strong and weak points are?

Strong points: 

C# is a great language.  I'd much rather write in C# than any of the proprietary scripting languages that has been invented for any existing game engine.  I'd much rather write in C# than C++.  Someone once said in the comment section of this blog:  "When you're happy, you're more productive."  Fast build times, managed memory, array bounds checking, no stale pointers, higher-order functions, good refactoring and auto-complete in the editor, NUnit, happy. 

XNA is a great API.  I used Managed DirectX a bit and it took me a day just to get the gamepad working the way I wanted.  XNA did it with two lines of code.  I mentioned this to a friend who liked MDX and he said, "Well, you only have to write the code once."  But if you have to spend a day on overhead for every component in your game, you're going to be investing a week or two before you even get to start on the gameplay.

XNA is fast.  You look at the stuff that's coming out of the XNA community and compare it to other popular game-prototyping languages, like Pygame or Java, and already, even though XNA is in its infancy, the games just smash the competition.

Weak points:

No portability.  If we want to see Schizoid on non-Microsoft platforms we're going to have to rewrite the whole thing in C++.  (Or maybe Mono's an option...?)  I'm not concerned:  C# and C++ are close enough neighbors that this isn't the end of the world.  And "portability is for canoes" - Steve McCarthy.  Since this game is a new concept it makes sense to get it to one platform as efficiently as possible and then, if it's succesful, to move it to others.

No interoperability with C++ on the 360.  When I first started using it, I figured, "Hey - I'll use this and if something's too slow I'll rewrite it in C."  Due to technical restrictions on the console this isn't possible.  If they solve this, then it would be practically a no-brainer to use XNA for any game.  As it stands, you're not going to be able to make a *Halo 3* killer with XNA.  But people are already making really good looking stuff, stuff that looks as good as a lot of Dreamcast and PS2 and Xbox titles.

Some of my favorite things about C# aren't efficient on the 360.  Currently you have to make sure you don't generate a lot of garbage on the heap - which makes you ask "What's the point of having garbage collection if I can't generate garbage?"  So a lot of our objects get allocated in reusable fixed pools - I hate fixed pools (http://www.gamedevblog.com/2006/08/stl_memory_allo.html) because you spend a lot of time tuning the sizes;  if you're wrong in one direction the game crashes and if you're wrong in the other direction the game uses more memory than it needs to - and closures (http://www.gamedevblog.com/2006/08/siren_song_or_h.html) generate garbage, so no closures that get called more than, say, once per frame.  Still, it suited me fine to get the prototype up and running quickly, with lots of garbage generation and closures, to show it off to Microsoft, and to then optimize that stuff out later.

What you think of the cost of doing "casual" games...?

I prefer the term "downloadable" because our players aren't going to be casual.  And, well, hey, it's cheap.  Really cheap.  A story went over Reuters today that said my alma mater - Spider-Man 3 - may cost $35 million.  Schizoid will cost over two orders of magnitude less than that.  And I believe it'll be just as fun.  You could make over a hundred Schizoids for the cost of a Spider-Man 3! 

Does that mean that
1) you have a pre-version of XNAGS Pro?
2) you're using the EE right now, planing to switch to the Pro version when it'll be released?

Up until now we've been doing all our development with the same consumer stuff that everybody can get.  Just now we got a pre-version of pro, sort of a "pre-pre-alpha" they're calling it, and to do the network play we have to get actual dev kits, which we don't have yet, but Any Day Now (tm). 

So we're the first guinea pig - we'll be finding the kinks in the system so people who use pro in the future will have the same ease of adoption as they do with the rest of Game Studio.

Living The Dream

As some of you noticed, the cat's out of the bag.  We're actually making a game - Schizoid for Xbox Live Arcade - and we got a couple of great write-ups:

http://www.1up.com/do/previewPage?cId=3157790

http://kotaku.com/gaming/gdc07/gdc07-torpex-games-on-xna-242020.php?mail2=true

So - yes - it's what every game developer dreams of.  The opportunity to do something that's never been done before...unprecedented levels of creative control...a small, kick-ass team...and without having to go for the housewife market: we're going for a market of people who are, for the most part, better at "Geometry Wars" than we are.  So it's still the kind of game we like to play. 

Not to mention, since we're using XNA Game Studio, we get to write in a nice, high-level, well-designed language instead of having to continue to live under the shackles of C++.

I'll tell you, though, we were spinning our wheels for a long time before we got here.  Starting a company is...impossible.

Anyhow, some of you probably have some questions.  Fire away - we're not talking about the game yet but we can talk about developing it and getting it approved.

Horrifying Videogame Patents

For the record, I'm not opposed to game patents.  Currently, they seem to be the only way that people who do what we do - invent game mechanics - can get the same sort of protection that authors get from copyrights.  In fact, I'm more predisposed to them than software patents - with software, you can protect yourself with trade secrets *and* copyright.  Game mechanics not so.

That said.

Abstract

When a player instructs a movement of a player character from an input device, a control section obtains a position of the player character during a current frame period. The control section obtains a distance between the position of the player character during the current period and a position of a view point of a virtual camera during a previous frame period. If the obtained distance is less than a predetermined critical near distance, the control section moves the position of the view point away from the player character. If the obtained distance exceeds a critical far distance, the control section moves the position of the view point towards the player character. If the obtained distance is in the range between the critical near distance and the critical far      distance, the control section does not move the position of the view point.

This was brought to you by Square in 2001.  #7,170,508.  Is it saying what I think it's saying?  Surely there was prior art?  I'd love to see them file suit with a company that could afford to fight back.

Yeah.  Patent reform.  All for it.