Beta Comics

I want to share Azarimy’s Battlefield: Bad Company 2 beta comics with you. They’ve been posted on the EA UK beta forums, but not really had the recognition or attention they deserve. It’s an amazing feeling that we’re not just making a game, but also inspiring other creative art like this.

My respect to Azarimy for some awesome comics, and my gratitude for his permission to share them with you here.

Awesome stuff. Azarimy’s got more coming, so if you like them, head on over to his thread on the forums. And on that note, I wish you all a happy new year.

(I’m a ninja, I’m a ninja, I’m a ninja, I’m a ninja!)

WordPress image upload bug fixed

When upgrading my blogs to wordpress 2.9, I found that the image upload broke. After some fiddling around I managed to get a proper error message out of it, I managed to track down the error to the file wp-admin/includes/file.php, which used a ctype_ function that, for some reason, was disabled on my php version.

Funnily, the exact same bug has apparently been a problem on wordpress before, on version 2.5, in a different file.

Anyway, I fixed the problem. If anyone wants the fixed file, here it is:


Download the archive, unzip the file.php inside and replace the one in your wp-admin/includes folder with it.

Building an Awesome Sound System

One of the reasons I’ve not been writing here much lately has been us buying and moving to a new house (that and the crunch time to get BFBC2 shipped, in which I’ve ended up in a crucial role).

As we are finally getting a bit settled in (at least the living room is free of boxes now), I’ve started thinking about a new audio and video setup for the entire house.

One thing I’m missing about the apartment we moved out of is my sound system that covered the entire place — living room, bed room, kitchen, even bathroom. The whole thing was a DIY thing involving two amps, a partially broken speaker selector, lots of wiring and speakers everywhere. I could select what rooms I wanted music in, which was awesome, but it had its issues. One thing was that there was only one input, so if one of us watched a movie there was no way to listen to music in another room, another that… well, there was lots of wiring.

I love my music!The house is a much larger space, and with it far longer wires to put up all over the place. I’m going to install a wired network that covers the place, but I’d rather not install any more wiring. Still, I’m going to want to send video signals from the digital TV box to the new TV in the bed room, which I might solve with a Slingbox PRO-HD and SlingCatcher, which seems like a cool combo with a bonus of access to my TV anywhere — if I can only figure out if it’ll work to remote control my box or not (my cable TV provider is probably Sweden’s most hated company not involved in public transport – com hem).

The audio setup is a different problem — I want a system which can play music from my media server in any room I’m in, can sync music in several rooms at once and which can also play audio from a separate input (like have the audio from a live music DVD on the PS3 on in several rooms at once). That last one seems to be tricky to pull off…

I’ve looked at several network media players, but most seem content at simply streaming media from a computer to a home entertainment system. Sonos S5 ZonePlayer seems like a popular geek choice, but sadly doesn’t do an external input (like my PS3).

The Logitech Squeezebox series seems to do (almost) what I want, but the component I’d need for the living room, a Squeezebox Transporter has some drawbacks. First of all, I can’t seem to figure out if it can stream its digital input out to other squeezeboxes — a make or break feature for me, but hardly mentioned out there on the ‘net. Second, the price tag! Holy crap, $1999? I’ll be upgrading my audio equipment, but I’m not really an audiophile of a class that needs that kind of equipment. It’d easily be the most expensive piece of equipment in the set.

I could even consider building my own system from scratch. It’d be kind of cool with a compact computer hidden away in each room, and a touch screen display system to interface with the thing. It’d probably end up cheaper than the Squeezebox option, but with a lot more work involved. Fun work, but frustrating at the moment as I don’t really have the time needed. If there’s a cheaper product out there which satisfies my three demands above, I’m a sale waiting to happen.

Do you know of any good network media player systems that fit the bill? Or do you have any experience with systems like that, good or bad? Please share any knowledge you have in the comments. I would also be happy to hear from anyone with experience of the Slingbox products.

Web Form Verification for Dummies

The standard method for interaction with computer applications has gone from being the command line to being the native GUI, to being the web form. We were awesome at verifying input when it came from the command line — that was simple. Then we were kind of ok verifying input in the native GUI, although quality varied a lot more.

Now we suck at verifying user input from web forms. The current state of code that verifies user input has both managed to take us back to the kindness of the command line when it comes to freedom of input and manages to check all the wrong kinds of things. Why is it so hard to write these checks? I suspect because people don’t really think much about them, and I bet there are more interesting things out there than to write user input verification.

These problems aren’t some beginner coder errors either — they’re rampant on even the biggest sites out there like paypal.

The most common field to get me snared is the phone number field. In 99% of all cases, the site assumes that all phone numbers in the entire world are formatted like US phone numbers. Not, as one could imagine, because I’m claiming to live in America — I clearly just told the site that I live in a European country. So anyway, inputting my actual phone number causes an “invalid phone number” error. Not that there is any mention whatsoever on the site about what the correct format of a phone number is (there are, in fact, even several ways of writing a US phone number).

This sets off a wildly unamusing guessing game of how to “convert” my phone number into a format the site will accept. This practice often costs the sites money as I end up giving up and going somewhere else, frustrated and unable to make a simple online purchase that didn’t really require that phone number anyway, did it?


Another highly amusing game is the one where web sites try to force users to choose “secure” passwords by enforcing the formats of passwords. “You must have at least 6 characters, with at least one letter and one number”. Sounds good, except in general these passwords are restricted to only contain letters and numbers. Hold on, isn’t it common wisdom to include at least one non-alphanumeric character in a secure password?

As such, out of my set of passwords, the only password which tends to pass most password verifications is my least secure one. The idea that you could fix a social problem through technology is somewhat funny anyway — “password1” is not more secure than “password” in any way that really matters.

ErrorThe same thing applies to the old trick of forcing your users to change passwords every month. This can have two potential outcomes — users append a counter to the end of their password, and increment it every time they are forced to switch, or they keep a post-it note taped to their monitor with their current password. Neither outcome is a net gain in terms of security.

Some sites even let the user set a password which is then considered invalid when the user tries to log in (ebay, for instance,¬† has done this) — causing a prompt for a new password and much annoyance.

Format wars

Parsing stuff is what computers are good at. So forcing me to input something in a strict format is always a loss. Either separate the fields and force me to select the individual parts of a date separately or actually use all that computing power at your disposal to do your user a favor. Telling me you have no idea what I mean by “2009-12-21” because you expected “20091221” is annoying the user for no good reason, even if you told me to not include dashes.

If you find yourself in a situation where you need to verify input¬† from the web, take an extra minute to consider how you could make things as convenient as possible for the user, which ones of your assumptions only hold true for the region you live in… and when you’re done, whatever you do make sure you tell the user exactly what the expected format is.

A Beta Release is Born

I’ve had a few minutes here and there to keep tabs on the EA UK forum for the BFBC2 PS3 beta, and toss in a few answers here and there. One thread turned into a discussion on the pros and cons of patching vs not patching the beta build.

There’s a limited amount of internal stability testing we can do. That testing can run down most things, but can’t test large-scale things (like server backends and what happens when 5000 people all log in at once). So, we get three things out of the beta: backend/large-scale stability tech testing, large-scale balance data and feedback from people.

I understand that people would rather see us implement our fixes resulting from all three directly into the beta. But putting out an update of the beta would require us to use up some of our internal testing to make sure the beta update is good enough. If sending a broken build to 100 people is bad, sending a broken build to 10000 people is a lot worse.

So in that situation we’re in a place where we have to choose between a spending our quality assurance resources on a beta update OR on the final product. To me, at least, that choice is quite easy. The led to this comment from poster 1Bryce1:

Isn’t a beta essentially a broken build to begin with? Any patches just eliminating problems and addressing balance issues along the way. So unless you break it more, any update would be less broken. Not only that but the “Backend/large-scale stability tech testing, large-scale balance data and feedback from people.” you get from each patched version would be more accurate to the finished game and give you better results. Wouldn’t it? I mean some of the most basic tweaks can drastically change the game and how people play. Spending some QA resources on a beta update IS contributing to the final product.

I started answering on the forum, but I figured this could be interesting for a wider audience and moved it here. A beta build is expected to be more broken than a final release — though I wouldn’t call it broken as such. A public (closed or open alike) beta is a reasonably unbroken build, from where I sit. The catch in the above line of reasoning is in this: “unless you break it more, any update would be less broken”. Essentially this is how it goes:

Lots of people in the dev team are making changes to the game. Each such change is to fix a bug or improve something. However, each time you change something, there’s a small risk of breaking something without noticing it. So together, the small risks of any one change breaking the game becomes a fairly major risk of *some* change breaking the game in one way or another.

Which means that the more work you do on a game, the bigger the risk that more stuff is broken at any given time (while, on average, the quality increases). As a developer, you can put up with that… either go back to an earlier, working, build or ignore the error for a while until fixed. Sending a build out over PSN is major though… you guys can’t just go back to an earlier build, or not jump into the tank because that crashes the game, or ignore the fact that all names in the score board come out as “PLAYERNAMEHERE_PLACEHOLDER” or whatever… a hundred small fixes can cause one large error, which you then fix as you find it.

So the way to deal with this is to stop development, test the build thoroguhly to find all the bugs. The closer you get to shipping something, the more stuff you will leave in there because of the risk of breaking something if you touch it, which means that as you get ready to ship the game off, the only bugs you fix are the really major ones. That way, when we ship, the game has been really well tested and we’re sure that it wont break.

This procedure has to be done regardless of whether it’s a beta update release or the final game… and that sucks because of the thing with “stopping development” I mentioned. So for a beta, what you do is branch the development. This essentially means you copy the entire source for the game to a separate repository, where it sits while everyone else keeps on improving (and breaking ;)) the game. The beta branch is tested, and thoroughly bug fixed. Needed bug fixes are done to both the main game line and to the beta line, while other improvements are done only on the main game line.

A slightly simplified version of this procedure as an image:

branchSome things are easy to see from this image: First of all, when the beta gets released, the main (somewhat broken) game line has already progressed a fair bit beyond the state in which the beta was branched. Second, there is no obvious way to update the beta from where it is… you need to start the entire procedure over again, branch another branch out of the main line game, and stabilize that the same way, and it is this process that takes resources away from the main development line.

I know there have been some comments that other betas do update. I’m sure they have rational reasons for that, which make the cost worth paying. MAG has come up as a name, and though this is pure speculation on my part, I’m guessing that their player count makes the game hard to test internally, which would mean that doing public beta updates is a very good choice for them.

WordPress Themes