A few years ago I built a credit card processing system. It used 2048 bit RSA encryption to encrypt the credit card data on the customer's own computer, then stored the encrypted information on our server until the order could be processed. Then that encrypted data was transferred via floppy to a PC which was never connected to the internet where the decryption key was stored so the order could be processed. That system was pretty secure against outside breaches.

I had to shut it down when the credit card PCI data security standard came out because the cost of security auditing the software plus annual third party security audits for the rest of the company combined with the potential for $500,000+ fines levied by the credit card companies in the event of a security breach made it totally not worth the hassle and financial risk.

So I feel a lot of irony today with Sony saying this about their 77 million PSN accounts:

we believe that an unauthorized person has obtained the following information that you provided: name, address (city, state, zip), country, email address, birthdate, PlayStation Network/Qriocity password and login, and handle/PSN online ID ... profile data, including purchase history and billing address (city, state, zip) ... PlayStation Network/Qriocity password security answers ... your credit card number (excluding security code) and expiration date may have been obtained.

Wow. All that information. Apparently none of it encrypted. Too bad they're big enough that those PCI fines won't really hurt. I expect their security auditor will get hung out to dry.

This week I built the other major component of my game's user interface: my own HTTP 1.1 server. The server is now built into the client to serve up web pages to my Chrome UI. At some point I might also put it into my servers so remote monitoring tools can check for server status via a simple web page request (a server I worked on previously dumped an XML file of status variables any time a browser did an HTTP GET request to it.)

Something I struggled with for quite a while was trying to figure out how to build a good-looking and functional user interface. I could certainly have built my own, but that would have been a major undertaking, as a lot goes into a user interface. You need a layout engine to manage where everything lands on the screen when you resize the window, you need widgets such as buttons, text areas, password boxes, scroll bars, radio buttons, progress bars, and more, and you need a way to author all that that is easy enough to use that if you change your mind, you can afford to do that.

That's a pretty tall order. And ideally I wanted it to be free.

There was a bit of a scandal recently when it was revealed that Rogers Cable here in Canada was throttling its World of Warcraft users. Rogers quickly came out with a release that this was a mistake, but it turns out the reason they are (still) throttling, is that World of Warcraft uses Bittorrent as the primary means to transfer its multi-gigabyte client patches. And it does it in the background while you are playing - so when Rogers throttles your connection, it kills gameplay at the same time.

This week EA banned a user from their single player games as a result of a forum ban, which got me thinking. Why is it a game company's responsibility to punish someone for bad forum behavior? They bought and paid for those games, they are customers.

Wouldn't it be better to allow each customer to choose who they ban? It seems it should be pretty easy to implement, just put a "ban this guy" button next to each user's name in the forums. Manage a global ban list for each user. Apply that ban list to forum posts, in-game chat, trade and messaging. If someone was on that list, they just don't exist as far as the player is concerned.

Now granted, some people are just troublesome, maybe the company should offer a banning service for their customers with moderators adding certain persistently troublesome players to a special section of all players' ban lists for them (that they could opt out of of course.) Maybe this is the place for the 72 hour ban the Dragon Age 2 guy got?

Now EA claims the game ban was a mistake, however given that their Terms of Service says explicitly that they can do that, I'll let you draw your own conclusions on the veracity of that claim.

One of the big pains of using OpenGL on Windows is that the Windows SDK only ships with OpenGL 1.1. There's probably a really good technical (and non-political) reason for this, but the fact remains, if you want to do anything with OpenGL on Windows, you're on your own.

What you need then, is something to bring the Windows SDK up to current standards (OpenGL 4.1 as I write this.) When I was originally trying to solve this problem (around the time of OpenGL 3.0), I came across GLee which is a cool library which makes the full OpenGL spec available easily. I didn't like their license, so I decided to write my own extension loader.

I don't think anyone should ever have to do this again, so I'm making this one public domain, do with it as you will. I'd like to hear if you use it in something, but that's not a requirement.

Sometimes you design something and it seems like it is a good solution, efficient, easy to implement, and then there's the reality.

My system for updating entities across the network was based on a simple idea. Everybody who is interested in a particular area gets updates for all entities within that area. Sounds simple right? But here's the problem. The areas are relatively small, so entities move from area to area pretty quickly.

Each time an entity moves to a new area, it needs to be synchronized with everybody interested in that area, ie the game needs to send the full entity definition to the new guys. There are a couple ways to do that, one is to send everything to everybody, the other is to send full updates only to the new guys. I implemented the latter since it is more bandwidth-efficient, but it turned out to be pretty expensive anyway. Too expensive in fact, but not in the way you'd think.

I've been trying to get my camera simulation working. Last week, I realized that the network was misbehaving resulting in multi-second packet round trips. A week of optimization work, and that issue is resolved. Now I looked at the camera motion system I worked out, and I remember that in order for the simulation to be somewhat rational, that all of the servers need to have synchronized clocks.

I was going to try to soldier on with my camera work leaving time for later, but the problem is that I've already figured out most of the time synchronization issues this morning, and if I go back to the camera work, I have to figure that out, then when I come back to the time, figure the time out again. So the efficient solution for a single developer is to do time synchronization first, and put off the gratification of seeing the camera work.

Sigh.

I've been getting anxious about having a playable to show people. It is getting really close now, so this week I expected to be getting the code running to move the camera and synchronize it with the simulation server. But as I was getting that going, I was shocked to discover that a round trip from the client to the simulation server took

SEVEN AND A HALF SECONDS

Gack!