Posts tagged: DICE

Game AI Keynote Slides

Last week I went to the Game AI conference in Paris, arranged by the AI Game Dev web site to hold a keynote titled “Building the Battlefield AI Experience”. The slides to the talk are now available on slideshare and as a downloadable powerpoint file. If you want the quick version, flick through the slides online:

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!

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

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.

Game On

I’m not dead. First of all, we’ve moved into a house and have spent a great deal of time sorting out things and selling my old apartment. And then, just as I thought I would have some more time for the blog again, we launched into crunch mode.

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.

A Tour of the Games Studio

There’s a hole slew of misconceptions and weird comments that inevitably go around as soon as any large game studio announces a game, or releases a game, or… well, just about anything else. So with this post, I’d like to welcome you to a small sightseeing tour of how a games studio works, on the inside.

I hope to give you a chance to see how a games studio works — maybe it’ll create better understanding of what it is you’re saying when you chatter around forums about the latest greatest game from some studio, or maybe it even gives you valuable insight if you’re looking to get into the games industry.

The Myth of the A-Team and the B-Team

Somewhere in the DICE Office

Somewhere in the DICE Office

As soon as a game announcement turns up, knowing fanboys will appear on all forums around, claiming grand things like “Wow, this sure is great. Now we know DICE has the A-team is working on this while the B-team was doing (other title here).” Substitute with “good team” and “bad team” or whatever you will.

The reality is not only that there isn’t any first or second-rate teams, but that the teams themselves don’t really exist as a concept. People move between teams constantly — some project doesn’t need any more audio work now, so the sound designers move over to the next one. Meanwhile, the programmers are fixing the remaining bugs and getting set to ship the game. Most of the artists left the project before that.

That means that there’s rarely a situation where a team in a large studio makes one title and then immediately goes on to make another one — more likely the team will split up and head to other projects. Some may jump on to help another project get the final bugs squashed, others may jump on to prototype a new game.

The Life of a Game Project

That leads us to the life cycle of a games project, because another misconception is that the team making a game will remain the same group of people all the way through.

A project generally starts out small. A few designers basically start up by spending some time trying to answer the simple question of “What game do we want to make?” Sometimes this is more straightforward than other times — but more often than not it is somewhat complicated and difficult. Even sequels usually start out in a state of “don’t really know what this is about”.

There’s this nice thought many people have about games as having this brilliant idea first, and then just making the game. This never happens. The project will probably get to some kind of rough concept of what they want to do, what kind of technology platform to use, what setting, and so on… and then go into pre-production.

The pre-production phase of a project is when the project starts taking on more people. Coders join, artists join, and most probably more designers join. The mission now becomes trying to prototype, test and prove all the different aspects of the game — figure out the core game mechanics, make art target concept environments, make sure all the tools needed work properly. The goal is usually to build a small section of the game as a proof of concept.

The project has probably been running for at least six months by the time it finishes pre-production and heads into production. It staffs up even more, and sets about building all the levels, missions, features and content needed for the complete game. The amount of time it takes to do this varies wildly depending on the game.

Still, through production concepts are refined. As playtests are done, the developers think of new ways to improve the game, and the new ideas are worked into the concept.

What You See Is All There Is?

By the time you hear of a project, it’ll generally be in production. Conceptual prototyping is relatively cheap, so studios can afford doing concepts for games as a test, and if they don’t turn out well then cancel the project. This means that at any time, your favourite games studios out there are probably doing cool stuff you have no clue about.

This way of doing things also means most views on the state of a game are somewhat flawed. By the time a game hits beta and you get to see it, it’s virtually completed and only bug fixing remains. Comments like “well this is an early beta, they’ll change lots of stuff” are quite common and somewhat funny to see — very few game changes will be done once a game is in beta.

That doesn’t mean quality doesn’t increase though — much of the quality you see in a game comes from the actual fixing of bugs, not the adding of features.

“Not that the devs are ever gonna care”

Gamers tend to show a pretty large dose of resentment towards game developers. In general, what you see is an announcement met with awe and comments like “this’ll be the most awesome ever”. This attitude then changes over time, until at release, the comments tend to sound more like “they messed it up”.

A strange aspect of this is that many gamers seem to be deep into the belief that game devs don’t care about them, about the games they make, or about anything at all other than earning a quick buck. This is strange because the games industry is not the place to go to make the good money while slacking — it’s generally a grind of long hours of dedicated work and not as well paid as other comparable areas (making business apps is definitely much more lucrative for a programmer).

Yet people still do it? Why? Because these people are gamers and love what they do. Maybe somewhere there are big-name execs that don’t care, but I haven’t met them yet. I’ve only met the EA execs who beat half the dev team on Battlefield: Bad Company (though dogtagging your boss is sweet indeed).

That’s all part of what makes the games industry such a great place to be if you love games — not only do you get to work with games, you get to work with gamers.

Yet most people seem to think that game developers isolate themselves in a small glass jar somewhere, and start ignoring the internet as soon as their project becomes public. Nearly every forum or blog post about a game has a bitter comment about “no chance the devs will bother to read this”.

Guess what — we do read stuff on the ‘net. Not only because we’re gamers but because we care deeply about making the best game possible. So why don’t we answer? Well, I think you could imagine what’d happen. Half the people would call you a liar, and the rest would bombard you with even more. There’s no way for a game developer to answer questions or opinions on a forum without immediately being subjected to at least twice the amount of new questions or opinions. We’d simply run out of time.

And well… at the end of the day, we have games to make.

For my own part, I’m more connected than most. Toss me a line on twitter if you have a question.

WordPress Themes