It's funny that you bring that up, having also mentioned iPhone in the same breath, because you've spoken a good deal over the last few years about the enjoyability and challenge of going to lower-spec systems and trying to tweak everything for maximum optimization on that spec. Does that not exist here, simply because modern PC hardware is already so capable?

JC: The tough part of it really becomes the decision about whether [it's worth it]. I love to go fight at the hardware level. I really enjoy doing that type of work. But projects like these have to be done more, unfortunately, on business-case decisions.

If we say, "Oh, if we want to do the best possible in-browser game," well, we could spend $30 million doing the best possible browser game, and you could never make a business case close on it. So it becomes, "How much can we afford to spend on this?"

And then, given that amount of resources, how do you want to allocate it? What's going to go to rendering? What's going to go to modeling? What's going to go to level design? What's going to go to web and database development and all of that?

It's clearly not the best thing we could do in a world without resource constraints, but it's a matter of figuring out what's the best we can do and still hope to have the business case close at the end of the day.

So, are you putting Quake III on iPhone, then? Is that part of the plan?

JC: It's not tied in directly with this. I could go on for a long time, again, just about the iPhone stuff. We've got a couple things going on on that, and some things have not gone great with our working with outside companies on it.

But there are several of us that are poking around in our somewhat after-hours and discretionary time on things. It's kind of exciting to look at that. We're working with a more vanilla Quake III codebase.

But now that I'm thinking about all this stuff, if we turned this into a product, even if it's not part of the Quake Live framework, we'll probably go in and pick up all the tweaks and changes to the core gameplay and the levels that have been developed for Quake Live.

With regard to the business model, is it purely ad-supported?

MS: Yes. At launch, we'll be ad-supported completely, and probably for a couple months after that. One of the big features that our player base is asking for is the ability to run private servers. Right now, we control all of the game servers, so all of the game instances that are happening are public games.

There's really no ability to say, "I want to run my own game and only have the people playing that I want to be playing," primarily because it's free and we're paying for all that infrastructure anyway. There are huge benefits for us controlling the physical hardware that the game is running on.

So, in the couple months after launch, we will be putting together, more or less, a subscription option that allows players, for a very nominal fee -- something around like the $4.99 price point -- to also probably do other things, but the core functionality will be to allow players to, through the very elegant interface they have on the website, run their own game servers.

You say, "I want to play this game at this location. I want it to be configured this way," and then tie that into our friends list and the social aspect of it. "I want to invite this player, this player, this player, this player, this player. Start the match." Or even have that match recurring, on a calendar basis -- "Every day at six o'clock, I want to play a match against John, and I want the system to invite us both to the match, start the game for us automatically." We'll be introducing that.

The traditional model for that is publishers or developers working with a game server provider, or GSP, to provide game server rental. That's usually done around a price point of $1, $1.50, sometimes a little less, per slot. So you've got players who end up paying $25 to $30 to "rent" the game server, and it's always in the same location. It's a very static transaction, and it's pretty costly.

Because of the way we handle game servers, we can be much more flexible with it and offer it at a much lower price. If I want to run my own game, it's only going to cost me five bucks a month or so, and I can set that game up any time I want, invite whatever friends I want. It'll spin it up, and then as soon as I'm done, it spins it back down. Then, next time, if I want to start one in another location, I'm not tied to a specific physical box.

I think players will really respond to that favorably. It's something that they wanted. And we'll tie a bunch of other features, more specific to running private games, to that model as well -- being able to call time-out in a game, blocking teams, and having referees.

It's more of a competitive feature set. We'll tie to those private games, because we obviously can't run those features on a public game. It frustrates too many people.

That will be something that, shortly after we go open beta, we'll start talking about, and people will see it fairly quickly. So I presume -- I hope -- that we'll add another component to the business model outside the advertising revenue.

Are you looking tie that into official clan support, where you could set up clan servers and events and groups?

MS: Yeah. That's one step beyond. That's a lot of web interface. Right now, we allow players to enter their clan tag, but that's kind of the extent of the clan support. I'd actually like to extend our friends system to support clans. So, not only would you have your friends list, but you could have a separate list, effectively, that's your clan.

I see clan support, in general, as being able to join a clan and have that as part of your social management. I wouldn't throw that into the category of needing to pay. The pay service is really more about an extra service, this ability to run a server that we are paying for.