The powerpoint presentation and the two movies that go with it contain more information, however, including notes for each slide that loosely reflect what I was talking about in the presentation. They are all available on DICE’s publication page.

I’ll try to turn this presentation into a post in a way that makes more sense online eventually. If you’re subscribed to the AIGameDev web site you will be able to watch the presentation video online eventually as well.

Enjoy!

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!)

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:

Some 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.

I’m hoping I’ll be able to write more again soon.

For now, I urge you to try the Playstation 3 beta of Battlefield: Bad Company 2, which opened yesterday. I have a couple of beta codes laying around (EU ones), so drop a comment here if you’ve got a PS3 and haven’t been able to get one.

I missed the link run this weekend, but for now, here’s a bunch of Battlefield news that are going around. Starting out with the one that has everyone excited:

• Yes, we’re working on Battlefield 3.
• No, we’re not telling you more than that. Do appreciate all the excited comments though, just don’t have any more information for you at this point.
• My colleague Demize99 has started to blog over at battlefield.com, starting out with a post about medics in BC2. Must-read, and I love the class.
• Inside XBox did an interview with Patrick Liu, producer for Battlefield 1943, about the game out soon on Playstation Network and XBox Live Arcade — asking, “is this really an arcade title?“

• Seth Godin has a commentary on Microsoft’s new initiative, Bing, that predictably is meant to be the next Google.
• And while on the subject of Google, they’re busy actually inventing new stuff: Google Wave, which looks extremely cool, and might completely take communications on the web to a new level. If you’ve got any kind of interest in web technology, watch their keynote demo — it’s an hour long, but well worth the time.
• Hanselman posts some interesting reflections on the result of Twitter becoming popular with marketers.
• The Messy Notebook has some advice on how to build something real in your spare time — it’s something I recommend to every programmer.
• Another event in the everlasting debate about piracy: A Canadian study has now been exposed as plagiarizing other reports, and of presenting numbers that were pure guesswork.
• If you’re into the Sci-Fi thing, check out this brain-controlled wheelchair. Human repairs are getting better and better.
• Some Battlefield 1943 news (boy, there’s lots of those): There’s a fourth map, Coral Sea, which will unlock with 43M total kills on each platform. And music4games has an article on the Abbey Road recording session for the soundtrack.
• I especially enjoyed this discussion on the BFBC2 multiplayer trailer, including a flamewar about whether the spotting system is cheating and a wallhack (hint: it’s not cheating if it’s the same for everyone).
• And time for another asshole of the week award, which is easily won by the Canon president who thinks there isn’t enough stress already — up your pace!

• Check out this awesome Mirror’s Edge cosplay photo set. Some serious dedication there.
• A video (by now a year old) of Project Trico has leaked onto the ‘net… this is the new shiny from the team behind ICO. Looks great to me, can’t wait for more info.
• The multiplayer teaser trailer thingie for BF: Bad Company 2 has been released, together with an interview with our Senior Producer Patrick Bach. I especially like the fact that the trailer is open, but you have to verify your age to watch the interview… he sure is a danger to all kids out there.
• Ned Bachelder reports on a challenge to compress images to fit in twitter messages. Awesome result considering it comes from 140 characters.
• Tech Crunch reports of claims that last.fm user info slipping and sliding into the hands of RIAA. Remarkable claims in itself, but the thing that interests me most is this quote from the email in there: “We’re just trying to help them stay afloat here it’s not like Pro memberships are earning any revenue!” — Might be smart to figure out how you’re going to make money before you start something like that.
• And finally I can’t help but sneak in yet another recommendation of Steve Yegge’s latest “article”, which is a Sci-Fi story.

Anyway, the debut trailer is up for Battlefield: Bad Company 2. What do you think?