cult-of-tech.net

Ars Technica is reporting on a Penny Arcade article that’s reporting on a blog post by Computer and Video games.com on how buying used games hurts the game developers.

Okay first things first, I ain’t go no dog in the horse race. I’m not a gamer, I’m not in their market to start with. Well that’s not completely true, I do play some games, at this point their becoming rather antiquated games, but new game releases that I have any interest in are few and far between.

What bothers me, why I even bring this whole thing up, is that apparently somewhere some large portion of the population stopped participating in the logical world and started off on some other past.

The argument that game developers are making is this.

1. Games cost money to make and support for online multiplayer play.
2. That money comes from the sales of the game
3. There are no secondary income sources in the gaming industry, like concerts; game releases are like a movie’s theater release with no DVD to follow.
4. Ergo when people sell games, they hurt the developer because the money that trades hands doesn’t support the developer’s ability to keep the game’s servers online. (I assume nobody gives a shit about single player games anymore, now that we have the magical internet.)

The problem with this is well 4 does not follow 3. When the seller relinquishes their game disk they also relinquish the ability to play the game. This is what all that DRM that’s suppose to keep people from pirating games is for, you don’t get to keep a copy to play when you give the media away. Because of all that fun DRM, there’s no increase in the number of players. As far as the game companies know, the original user’s IP address changed–yes I know it’s more complicated than that with accounts and what not.

The point is, from the developer’s perspective the costs to run the server for some period of time into the future was paid for when the game was originally sold. There’s no difference in costs between:

1. The original player playing online for 3 years
2. The original player playing online for 1 year then selling the game to another buyer who plays online for 2 years.
3. The original player playing online for 1 year, the selling to someone else who plays online for 1 year, then selling to a third party who plays online for 1 year.

The point is, so long as the play time online is the same, the costs are the same.

The failure in reasoning is really maddening.

However, what might be the most telling from all of this is what it means about the way the developers budget for multilayer capacity. What the developers are really admitting is that they are, in the long term, over selling their servers. That is they don’t really expect anybody to play the game for 3 years, they expect people to play the game for 6 months and then go play the next game they release.

Of course this problem is mostly their doing as well. Since multiple player play is now, almost exclusively, handled though a developer/publisher owned server, ostensibly for piracy reasons. The cost of running those servers falls exclusively on the shoulders of the developers.

By comparison, games that have stand alone servers shift the burden of hosting the multilayer games onto the community. If the community is big enough to support continued access some years down the road, the community, not the developer/publisher, will find a way to foot the bills for those multilayer games.

By tightening their noose around how people can play online they cut their own necks when it comes to who foots the bill for online play.

When it comes to software providing a feature or function that’s broken  is worse than not providing the feature at all.

Let me weave the story of broken functionality from this weekend.

Google’s Apps for Domains provides 2 ways to reset your administrative password, either you have an alternative address configured and a check-box checked allowing Apps for Domains to reset your password using that address. Alternatively, if you missed that configuration option you can go though an alternative process that involves creating a DNS record with a value provided by Google to verify that you own the domain.

From what I’ve gathered, the functionality is suppose to work like this; you create a CNAME record with a value provided by Google and point that at google.com. Google’s system is then supposed to look up that CNAME record and verify that it points to google’s domain. If it does, the instructions for resetting your password are sent to the email address you provide when you go though the recovery process.

The problem is, the system is broken right now.

What should happen, and what’s actually happened are two different things. In reality I’ve received 2 automated responses form Google indicating that the system couldn’t verify the CNAME record. After searching the Google Apps support forums it turns out that the CNAME method is currently broken and that Google is aware of the issue but hasn’t bothered updating anything on their site to note that or temporarily disable the function.

Since the functionality was present and failed in the same way one would expect it to fail if you had simply configured something wrong the result is spinning your wheels with no results. If Google had disabled the functionality or provided a link to their support request system in the resulting email, I could have at least opened a ticket after the first failure instead of going though the process again double checking everything.

the least they could have done was provided a link to their support ticketing system. The worst possible thing to do to a customer is make it look like their spinning their wheels. In this case at a minimum the auto-reply email for a failure should include a way to open a ticket on the issue instead of just sending you back to the same process with a generic error.

The moral? If you’re a developer and you realize that some functionality you’re providing isn’t functional, disable it until you’ve fixed it. If that means you have to deal with more support tickets for a while so be it. This is even more important in a customer service situation like resetting a password.

Needless to say, if you use Google Apps for Domains and your administrator account doesn’t have a secondary email address that can be used for resetting the password, set that up post haste. On top of that, it might not be a bad idea to create a second administrator account with a long random character password that’s stored in a safe place. With a second admin you could use that to log in and reset the primary admin account’s password as well.

Windows 7 never ceases to amaze me. I recently brought up a Win 7 Home pro box using, some pretty archaic by modern standards hardware. While not the most stellar performer, it does surf the web well enough and considering that was it’s intended mission I’d say it’s been successful.

Actual specs are:

• Intel P4 2.4GHz Northwood Core (overclocked to 2.6GHz)
• Asus P4P800 (865PE chipset) motherboard
  • 3COM 3C940 Giga-e LOM
  • On board ADI AD1985 Audio
  • On board VIA 6309 firewire controller
  • SATA via IHC5R
  • 2 UDMA 133 ports via VIA 6410
• 1.5GB of DDR RAM in dual channel mode (2x 512MB sticks 2x 256MB sticks)
• nVidia Geforce FX 5700LE
• 500GB Western Digital SATA Caviar drive

I was utterly impress that not only did everything work, but everything was detected and worked right out of the box. Even installing to the SATA controller which was always a problem for Windows XP. Though I guess I really shouldn’t be so surprised by 9 years of OS development.

None the less, the real concern was performance. Of which the machine scores a blister, okay not really, 3.2 on the Windows Performance index. The limiting factor actually being the CPU.

I don’t know what I found to be more surprising, the fact that all the old hardware worked under the new OS or that the system is just as usable with more features and better security as XP SP3 was on the same hardware.