Bellevue, Washington headquartered Torpex Games is a relatively little-known independent game development studio that has garnered a fair amount of media attention thanks to its current project, Schizoid. As an upcoming title in development for Xbox Live Arcade, the game, and by association the studio, has become a poster child of sorts for Microsoft's recently announced XNA Game Studio Express, the platform on which Schizoid is being developed. Recently Gamasutra was able to speak with Torpex Games' co-founder and president Bill Dugan regarding his company, Schizoid, and his thoughts on developing using Microsoft's XNA Game Studio Express, which allows indie developers and students to develop simultaneously on Xbox 360 and PC. Torpex Games itself was co-founded by Dugan, who served as the executive producer at Activision's Treyarch studio, on Spider-Man 2, where he also met Jamie Fristrom and James Chao, both of whom are currently working on the Schizoid project. Dugan started in video games in 1986 as a scripter on the classic Interplay RPG Wasteland. He previously worked at both Wizards of the Coast, where he met Richard Garfield and Skaff Elias, also working with Torpex on the company's projects. Hi Bill, and thanks again for taking the time to speak with us. Before we talk too much about XNA and Schizoid, could you talk a bit about how Torpex Games is set up? Torpex is two programmers, one artist, two designers, one sound designer and musician, and me. Some of those are working part time. For the forthcoming Project 2, some of the above will overlap with new staff we’re seeking currently. Can you talk a bit about Schizoid, and what players can expect from the game once it is released? Schizoid [recently previewed at consumer site 1UP.com] is the most co-op game ever. Jamie came up with the idea at a game conference last year and took a few days off from writing proposals and doing schedule estimates, which we had been doing for a few months beforehand. He had a gameplay prototype up in about 4 days, using programmer art. It’s got a novel gameplay mechanic, really different, and we all had fun with the prototype, got excited about the game, and charged ahead on it. We first showed it to the Xbox Live Arcade team after about 3 months of development and they loved it. We had used XNA Game Studio Express to build the game up to this point, and had always assumed we’d need to port to C++ in order to ship it on the 360, but the XNA team heard we were doing this, and loved the game, too, and asked if we wanted to take it all the way to the goal line in C#, so here we are doing it. What is your opinion of XNA so far, and why is it the right choice for Schizoid? XNA GSE been great for us. Specifically for Schizoid it’s been great, because writing code in C# has simply been faster than writing code in C++. Because Schizoid has this novel core game mechanic, right from the beginning we were proceeding in new territory – we couldn’t draw much inspiration from games in the genre, because there aren’t any games that play like it. So there was additional pressure to make sure it was fun by playing it relentlessly and tweaking constantly – continuous, rapid iteration once we got it up on screen. This would have been slower in C++ despite our long history with it. For what sorts of games would you imagine XNA not being ideally suited? The usual concern over “managed code” is performance. We have indeed had a learning curve on C# performance, which was made more interesting by the 360 behaving differently from the PC in a variety of ways. It’s not killing us on Schizoid, though, by any means. What, in your opinion, do you think are the platform's most noteworthy benefits that it offers developers? You can get up to speed and have a functioning game remarkably quickly. It took Jamie about 4 days to move from a standing start, to having the first Schizoid gameplay prototype working. Those 4 days included learning C# along the way. If you’re a C++ programmer and are interested in rapid prototyping then you owe it to yourself to try out the platform. One of the reasons it’s great for rapid prototyping, and for learning, is that it’s relatively bulletproof – more errors are caught earlier, so many, many kinds of errors that would crash a C++ program are caught in GSE at compile time. And the preprocessor is running all the time while you’re typing code in the editor, so if you type in some code that tries to access a method or an element of a structure that’s out of scope or something, the editor just sticks a red underline under it, as if it were the spell checker in Word, and lets you go over and fix it when you want. The relative bulletproofity also encourages other people on the team to make larger contributions than they would dare to if they were using C++. I’d add that if you’re a student or a startup, another large benefit is this is the least expensive way to make a full blown console game. Conversely, what do you think are the biggest shortcomings of XNA development? I don’t want to lose all my credibility by chirping happily that there aren’t any shortcomings, but it’s hard to think of any that are really significant. From a production standpoint, for most games, another optimization pass is probably necessary as compared to what would be needed in C++ development, but that production time is more than made up for by the rapid speed of coding in C#. Do you think that games that are casual and bite-sized in scope work better on the XNA platform rather than more epic titles? How do you (abstractly) design titles to be played in download-appropriate chunks? The former question is important and hasn’t been tested yet with an epic sized game. I don’t see why you couldn’t do an epic title using GSE as well as you could in C++. The main objection would possibly be what I mentioned above about not being able to mix GSE’s C# with externally created code, but this doesn’t affect all epic-sized games, either. As for sizing the game to be a download-appropriate chunk, art and sound consume the most space, so we try to be clever on a couple of levels with these, like reflecting symmetrical artwork in code, giving you instant 50% compression right from the beginning, that kind of thing. Random content generation is another exciting tactic that is more important in downloadable games; Fate was recently notable for this. What is the biggest technical challenge or difficulty in developing for Xbox Live Arcade? The technical challenge in developing for XBLA with XNA GSE has purely been that support in GSE for multiplayer networking on the 360 is being rolled out currently. Torpex is the first group to deal with this outside of the internal team at Microsoft, so as with all bleeding-edge technology, there are going to be hiccups. It’s not bad, though, it’s nothing like trying to get a 1990 console game up and running with no documentation. And the XNA team at Microsoft has been remarkably helpful. Are you planning on targeting other platforms with Schizoid, Windows for example? What about for future projects? Schizoid is a natural for several other platforms and we’re still planning what to do here. Does Torpex practice any agile development or iterate on gameplay mechanics before implementing them, or is the team small and agile enough already without having to implement specific techniques? We really believe in agile development, and one core principle of this is that working code with a to-do list is far superior to a large design document. It’s just an axiom in the video game industry that you can’t write out a big design on paper and then fling your staff onto the design document, execute it all, and the end result will be fun. We’ve all been agreeing on this for a decade, and you’ll never find anybody in the industry who claims to disagree; but there are many, many development managers who inevitably ask the team for a big design document explaining everything that will be in the game when it ships in 18 months or whatever. The way to do it is to create something that works, usually small, and implement and play it immediately; and if it sucks, then it doesn’t cost you all that much to throw away the idea and follow an alternative line of thought. If it doesn’t suck, then make an incremental improvement that day that can be played the next day, and maybe it’s a little better. Things tend to snowball once something good is there and is playable, and the whole development process benefits from this rapid iteration because the new ideas that people generate are sort of centered in the fun gameplay that is already there on screen. So, the above philosophy sounds obvious, but to answer the question, you do have to consciously follow this method – short sprints, rapid iteration, get stuff on screen right away. Finally, what lessons were you able to take away from your earlier work on titles such as Spider-Man 2 to apply to your work on Schizoid? The two seem so incredibly different both in scope and gameplay that I'm interested to hear about any common ground. The two projects both have a great and novel core gameplay mechanic, and the word “great” is only present because they also shared the tactic of rapid iteration of the core gameplay mechanic, early in development. Jamie led the charge on Spider-Man 2’s swinging mechanic (he wrote the article on this in Game Developer) which just involved working hard on the core gameplay until it was great. I think the Spider-Man 2 swinging was groundbreaking as a result. If the team had just taken the first Spider-Man movie game’s swinging mechanic and improved it by 20% and moved on to building levels, the game would have been 80% lamer. So after Jamie came up with Schizoid’s novel gameplay mechanic, he applied that particular lesson from Spider-Man 2 and executed the same rapid iteration of the core gameplay mechanic with Schizoid, and the gameplay is great as a direct result. We still think it’s crucial to just get it working and tweak it, rather than write design documents that are going to guess at describing it. This is going to be important for our second project as well.