Slashdot Mirror
Using Agile Methodologies To Make Games?
simoniker writes "Using Agile methodologies for programming is a concept that's been around for a while now, but some firms are now applying the concept to video game development." There has been a lot of talk lately about what the 'next big thing' in development will be. Could this be it? Or is this just another step along the way? From the article: "Agile puts the emphasis on producing demonstrable iterations of a game almost immediately into production, creating prioritized vertical slices that iterate on the most critical elements and features. The method also puts great emphasis on the organization of teams and the relationships therein, as well as the cycles in which teams must plan and carry out their project objectives."
When I was in the game industry, this was how we always did it, even EA does it to an extent. Why? Because the publishers want results. Usually every month or you won't get paid. So as a result we had incremental releases with more and more features added in, and as a bonus, sometimes working. X-D
P.S. With few exceptions, most game teams do NOT have specs or docs. If they're lucky, they have concept art and some clue what the game is supposed to be. I remember having to code up front-end screens and the artist & I had to figure out what they were supposed to do because the game designer was still writing the specs for the screen we finished last week.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
With games it is UNBELIEVABLY difficult to write unit tests that effectively catch problems. With animation, physics, AI, the built in randomness with the game, the human interaction, etc. it's unbelievably difficult to write unit tests that can get the job done.
It's easy to write a unit test that says, "When I shoot a dude with this gun, make sure his health goes down by 50". But it's an entirely different thing to say something like, "Make sure that when a battle is going on nobody gets caught up on geometry and can't path to their movement goal."
Sure it's possible to write small little unit tests that make sure a dude can get from point A to point B, and that this guy knows how to path around a dynamic object if a crate falls in his way, but this isn't something you can effectively break up into little parts. I've fixed too many bugs that are a strange and unfortunate combination of all the aforementioned systems to fall into the trap of thinking isolated unit tests are going to get the job done.
I am a big fan of the idea in theory, but I can't imagine it being implemented effectively in practice. I would love for somebody to prove me wrong!
You need to refactor the system when you add the features so that the system stays in balance with the new feature. Otherwise its just a hack.
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." -- Albert Einstein
Some methdologies develop each subsystem fully then integrate them in a big bang at the end. Agile practitioners develop whatever parts of each subsystem are needed to support the features in the current iteration. If you think of the subsystems as layers, the vertical slice is the part of each layer that is being developed in the current iteration. The features should be prioritized in order of importance, so each iteration is working on the next most important feature or features. The idea behind all this is to always have some sort of working application.
The studio I'm in uses this process and it really helps keep all the teams on the same page.
;)
Our team meets every morning at 11:00am and we discuss our progress and share any issues that come up. Interopability problems come to light very quickly and are dealt with in a few hours / days instead of months down the road.
One thing that we say in our SCRUM meetings is, no sitting! Keeps it short, sweet, to the point and people are alert through-out the meeting.
We try to break up all our tasks in to two day work chunks and keep a backlog of all items needed to complete the project (well, at least to reach our milestone goals). So we have a meeting at the start of each block, a meeting in the middle, and a meeting at the end of the block/start of the next. It's flexible and actually keeps stress to a minimum.
One thing to keep in mind, SCRUM is not a place to discuss deep details of the system. It's mostly to keep everyone in touch and in the loop so try to stay on topic and not derail the SCRUM. Otherwise it's just a regular meeting
"creating prioritized vertical slices that iterate on the most critical elements and features"
Can someone tell me what this means?
Sure. It means get something simple working as quickly as possible and improving it over and over.
prioritized - Pick your most important features and implement them first. For example, if you're writing a word processor the ability to save a file probably has a higher proiority than a spell checker.
vertical - This means "specific" as opposed to "general" (also called horizontal). So you work on specific features (like the saving of a file mentioned above) rather than more general ones (like optimiztion).
iterate - You're not going to do things all at once. As an example, perhaps your first iteration of saving a file only saves text and no formating information. You're second may add formatting, your third may add additional formats.
LOL. I'm laughing because usually I'd agree :-) But why? Well, because most games studios I've worked involved near constant death-marches to ship product. I'm now a Senior Architect at High Moon (where Rory works) and I'm amazed to say that (a) I have spare time and (b) our productivity is much higher than any other place I've worked. Now I admit that being a total geek I end up working late a lot anyway, but its on interesting avenues and experiments rather than fixing the bugs that I introduced when I was asleep at the wheel 2am the night before as used to happen.
You were right about him hanging outside smoking though.
Bad Management is Dangerous. Always. This is not a problem with XP, this is a symptom of some basic problems:
The Product Manager does not know the real business value of the features she is requesting. If the business value in profits was known, she would understand what the priorities of the team really should be. She would also know what the "MINIMUM" set of features are that the product needs to be profitable for her market/audience.
The Project Manager does not understand that "HARD CHOICES" are required "EVERY ITERATION" by the Product Manager. You cannot add scope to a fixed team without moving the date. This is basic 101 project management, it is true no matter what methodology you use.
The team does not know their velocity, and/or have not helped management understand what their velocity is, that it is fixed, and how changes in scope may not affect delivery dates, but addition of scope surely will.
A very innovative gaming company uses XP and Scrum, they are http://www.highmoonstudios.com/ and they are very successful at delivery, without abusing their development teams, and harming the people in them... a rarity as I understand the broken painful world of software game development.