Microsoft has added the ability to share game binaries to XNA Studio:

Officials from Microsoft have announced an incremental update to its XNA Game Studio Express, the software toolset aimed at Windows and Xbox 360 homebrew programmers and students, now containing a utility to let users share binaries for both PC and 360 platforms.

This leaves several hoops for indie game developers to jump through to get some money for their XNA Studio-created console games. First is the barrier to entry for purchases: They have to be a member of the XNA creator’s club, which involves paying Microsoft $99 per year and installing XNA studio on their own. The second is that there is still no direct method of charging for a game. You could generate your own unlock codes or charge a fee at download, but there’s no way for someone to pay some points and get your game.

This is the first hurdle, though. I expect Microsoft to address the other two by the end of the year.

I recently read two things struck me funny. Both are examples of how out of touch someone in another field can seem from my perspective here in the game industry. The first is an essay by Paul Graham of Y Combinator titled “Microsoft is Dead”. The second was in a comment in Stevey’s Blog Rant about the Next Big Language: “Its the reason C++ won over Eiffel or Smalltalk, and probably had a lot to do with Java wining [sic] over C++.” Both “Microsoft is Dead” and “Java winning over C++” are patently false in the game industry.

Microsoft is dead?

Paul Graham’s essay deserves a little more explanation. His point isn’t that Microsoft is going out of business, but that Microsoft is just no longer the big company that everyone is afraid of. This part of his essay, in particular struck me as wrong:

The last nail in the coffin came, of all places, from Apple. Thanks to OS X, Apple has come back from the dead in a way that is extremely rare in technology. Their victory is so complete that I’m now surprised when I come across a computer running Windows. Nearly all the people we fund at Y Combinator use Apple laptops. It was the same in the audience at startup school. All the computer people use Macs or Linux now. Windows is for grandmas, like Macs used to be in the 90s. So not only does the desktop no longer matter, no one who cares about computers uses Microsoft’s anyway.

We have exactly two apple computers in our office. One of them runs windows exclusively and was purchased because it’s in a noise sensitive area and the Intel-based iMacs are really quiet. The other is the laptop used by the PR person who has been sharing part of our office for the last four years. None of the programmers use Macs. None of the Artists use Macs. None of the designers use Macs. A few people have them at home (our sound designer and our producer for instance), but even that is really rare. I have two Macs at my house, but neither of them has been turned on in at least 8 years.

It’s not that we’re anti-Apple, we’re just pro-market. There are far more Windows PCs than Macintoshes in the world, and we decided to write our game for the larger market. Rumor has it that for the number of copies of the Macintosh version of Shadowbane that were sold, it would have cost Wolfpack less money to just buy each of those users a PC that it did to make their game cross platform. Is anyone but Blizzard still publishing games on the Mac at this point?

We have even fewer closet Linux users in the office. Our servers run on Windows too, so we didn’t attract Linux programmers in our recruiting. As far as I know, we have only one Linux user in the whole office. The single Linux machine in the office runs non-company related stuff for one of the founders and is about 8 years old.

As a company, our bias against Linux is a little more pronounced. The founder who doubled as our IT guy for the company’s first five years used to be a program manager at Microsoft working on Exchange Server. He had no interest in learning a whole new platform to get the office up and running. And I think the development tools on Windows (read: Visual Studio), crappy as they are, are still better than developing in C++ on Linux. Plus the client has to run on Windows, so building the servers as part of the same build process and running them on the same machines reduces all of the multi-platform overhead. Performance-wise, the two platforms are not that far apart anymore, so the traditional advantage of Linux didn’t make it worth the extra ramp-up time or development time.

So how can Paul Graham be so wrong about Windows? Obviously not “all the computer people use Macs or Linux now” in our company full of computer people. Well the biggest difference is that he’s not in the game industry. He works with early-stage startup companies, most of which are building web-based software. The people who he works with are developing thin-client applications that don’t care what operating system you use. They use whatever platform they prefer for development, and their customers will be able to do the same.

In our industry Microsoft is shaping up to own the #1 platform of the current console generation, or at least be a close #2. On that console they are the sole arbiter of what games can ship (or download) for their platform. They are also the platform provider for the PC platform, and provide the APIs that both games and game hardware vendors have to build toward. On top of all that, they publish a lot of games, which makes them a significant force on the content side of the business too. Nintendo and Sony are certainly wary of Microsoft, and I bet Ubisoft, THQ, and other publishers are too.

Java is winning over C++?

As I see it there are three kinds of languages in this world:

1. Hard to write, but blazingly fast: C and C++, or even assembly if you’re really hard-core
2. Easy to write, but so slow that you have to use them sparingly: PHP, Lua, Python, Perl
3. Flash

Java fits into an awkward niche between 1 and 2. It’s easier to develop in than C++, but not enough to keep up with the scripting languages, and yet it’s far too slow to write the whole game in. Add to that the incredible pain of forcing your users to install the Java VM, and you get a non-starter of a language.

Flash is sort of an exception. It is ubiquitous, or nearly so, and as a result deployment of flash games is trivial. And it does enough for you that it’s perfectly usable for 2D sprite games. In some ways that’s the best of both worlds. Depending on how things go with XNA Studio, C# might join that third category, at least on the PC and Xbox. If it does, Microsoft’s dominance in our industry will be little stronger.

I don’t know anything about the background of the person who left that comment, other than that is name is Paul Johnson. Given his bias toward Java, I’m going to assume that he is writing enterprise software. In that world, the sort-of cross-platform nature of Java is actually enough of a benefit to outweigh the performance cost. And Java does a lot more for you than C++ so it is easier to code in. I just wouldn’t want to try keeping it running at frame rate.

Trapped in my own bubble

I spend all day at work in a PC-base MMO bubble. At the fringes of my bubble are non-combat MMOs like Second Life or A Tale in the Desert, but they are really outside of what I think about. Often fancy new web technology will come up in a “wouldn’t it be cool if we had blogs in our game” kind of way, but for the most part all of that is outside of my bubble too. It is a lot of work to get out of a bubble. The conferences I go to are game industry conferences, and it’s not always easy to convince the Powers That Be that even those are worthwhile. Even at a whole-industry conference like GDC I end up going to a lot of MMO talks in the hopes of picking up a new tidbit.

To try to keep in touch with the larger world, I read a lot about software development (past and present) so Game Programming Gems won’t be my sole source of engineering advice. I also read a lot about innovation in general and the origins of some of the destructively creative companies of the past thirty years. In practice, that means reading about a lot of successful startups. All of this has helped me to be a little more informed about what’s going on outside of my bubble. It doesn’t really change the fact that ten or so hours out of every day are spent diving deeper into the PC MMO bubble to get the game launched. It will probably come into play a little more when we’re planning a NEW project than at this late stage of an existing one.

It’s obvious that I’m not the only one trying to not get trapped into MMO-think or game-think. Danc is studying product development methodologies that aren’t even from software development, let alone games. Raph spends almost as much time talking about recent web developments and broader media topics as he does MMOs. I suspect that one reason these two express their thoughts so cogently is this drive toward diversification. It allows them to see the same issues everyone else sees, but from a new perspective.

What do you think? Do you think this perspective-limiting effect is actually a problem? What do you do to deal with it?

A few days ago Ian Landsman posted on the subject of distinguishing between features you don’t have because they are inappropriate for your product and features you don’t have out of sheer arrogance. We recently ran into a case of the latter that has cost us many man-hours to deal with. That feature is label support in Perforce.

But Perforce has labels, you might say. Well they have labels, but they don’t have labels that you can use like you would in any other version control tool. If you try, you will end up with a dog-slow Perforce repository and a bunch of unhappy employees. Perforce supports labels, but they simply don’t scale to real-project sizes. We found label support in Perforce and, assuming that they had support for them, set up the daily build script to operate something like this:

1. Get the latest version of all the files out of perforce
2. Build the game
3. Label the version of all the files that were synched at step 1 with the version number of the build

This is the same build process I’ve used in RCS, Starteam, ClearCase, and Visual Source Safe. It’s just what you do. You can use that label to sync a very specific version of all the files out of the repository, and we often do. Labels are central enough to the Perforce experience that there’s an entire menu dedicated to them on the top of their UI. The only clue we had that labels might not be the best choice in Perforce was this note from the label documentation:

Before you assume that a label is required, consider whether simply referring to a changelist number might fulfill your requirements.

Well fast forward four and a half years and run a build every work day. Over that time our Perforce repository accumulated over 1100 labels. That’s certainly a lot of labels, but since almost all of them were sitting inert in the database, it didn’t seem like a problem. But over the past 4-6 months our Perforce performance has really started to bog down. As of last week, simple operations were taking 5 minutes or more. And by “simple” I mean refreshing the UI.

We tried upgrading our Perforce server first. It was 4 years old, so that seemed like a reasonable explanation, but it actually made the problem worse. When we finally called Perforce support to find out what was going on, they were shocked that we had the gall to use labels. After all they, only included them in the product to ease the transition from other version control systems, not because anyone was supposed to use them. At the end of the support call, after rolling back to an old server version and occupying one programmer and one IT guy for an entire day, they sent an email that included this gem:

You will see better performance even before you delete the labels — using changes instead of labels is far less intensive in terms of resources. Also, they may grumble about it now, but I suspect your developers will be much happier when they realize that they don’t have to create and maintain labels any more — the change number system is automatic.

Excuse me? I don’t “have to” create and maintain labels now. I type “build” and the labels just happen. The level of “our way is better, and we know what’s best for you” in this email is astounding. It mirrors earlier comments made over the phone by the same support guy.

Now, I don’t really care about the labels vs. changelist numbers debate. They want us to use changelist numbers, and if we had known labels didn’t really work from the start, we would have written our build system around changelist numbers instead. What offends me is that a feature they display so prominently is something we aren’t supposed to use, but they couldn’t be bothered to tell us this anywhere in the documentation. If labels are such a problem for them, they should put something like “Labels have serious performance implications for large repositories. Use changelist numbers instead.” somewhere in their documentation.

And what’s with the attitude? We paid nearly $40,000 for this product (for our 50 seats.) We pay them $8,000 per year to keep our license up to date so we can add new licenses when we need to. That’s an awful lot of money to pay for them to tell us in a snooty voice we’re wrong for using a documented feature in their product.
Yesterday I wrote a quick one-off script to delete all the build labels that were more than a month old and which didn’t point to a version of the game we ever distributed or showed to anyone. Now that those are gone, our Perforce performance seems to be back to normal. We may eventually switch to changelist numbers, but it will be on our schedule, not in some sort of emergency fix mode. We’re also looking around at other revision control systems that won’t look down on us as much as Perforce apparently does. Anybody have anything to say one way or the other about Accurev?

Submissions are due April 30th in the usual categories. In addition to those, this year also features a “people’s choice” track, where all the rejected proposals will go to fight it out Surviver-style.  Hopefully the extra input from attendees will keep this  conference from turning into GDC-Texas.

Scott Jacobs, editor of Game Programming Gems 7, posted the following to the gdalgorithms list:

Abstracts are now being accepted for consideration to be included in the 7th volume of Charles River Media’s Game Programming Gems book series. Original articles detailing techniques in the specializations of Graphics, Programming, AI, Networking, Scripting, Physics, Mathematics, Audio are desired. Preference is given to articles that conform to the Gems spirit of presenting practical ideas with working cross-platform code that can be put to use immediately in game projects that are currently under development. Submissions should be made using the form at http://www.gameprogramminggems.com/subform.html

The deadline for proposals is May 10th. (Please note that this date is one month earlier than some previously published submission deadlines, so if you had already been planning to submit, double check your calendar!)

For additional details, visit the Game Programming Gems website at http://www.gameprogramminggems.com/ or feel free to reply to me directly.

Submission Guidelines: http://www.gameprogramminggems.com/guidelines.html

I don’t think I’ll be submitting anything, personally. My experience writing those two articles in Massively Multiplayer Game Development 2 taught me that a “you should develop stuff like this” article with no code examples falls kind of flat. I wasn’t able to include any code for those articles because everything at FLS is dependent on Alchemy, which is redistributable. Since I’m not likely to come up with anything that I _can_ distribute for an article by summer, I’m going to let this one go by. Maybe GPG 8 will be accepting submissions sometime after Pirates launches.