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