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

4 of 236 comments (clear)

  1. But that's how most games were made... by MagikSlinger · · Score: 3, Informative

    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
  2. I've thought about this by th1ckasabr1ck · · Score: 3, Informative
    I program games and I've thought about this a lot. I kind of like the agile approach, and I think that a lot of the concepts could be useful. One of the major components of being "agile" is building unit tests and relying (at least somewhat) on those as a way to make sure that these rapid checkins are not breaking semi-related systems.

    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!

  3. Re:Buzzwords aplenty by rwhansen · · Score: 3, Informative

    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.

  4. Re:Buzzwords aplenty by magicjava · · Score: 5, Informative

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