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."
That said, I've found the hardest part of the process to be finding a client who is willing to put up with the constant back-&-forth and interminable beta testing. Customers generally just want to tell you what they want, go away and then have you magically deduce what they actually need, and can be irritable when you tell them you really can't do that because ... you know ... agile!
there is no need to sign your posts. this isn't usenet. your username is right there above your post. stop it.
games have pushed the envolope more than any other area in computer software development
... a fully autonomous systems that can operate a *power plant*. Once those two things happen, humans are toast. I'd estimate that to be about 2060.
the current rising tsunami happening right now with agile development for web applications (like Ruby on Rails, and similar approaches happening in Perl, Python, java and others)... will take games by storm, in my opinion. there are a few factors here that will make games really interesting:
there will be much more scripting in games,
there will be much more meta-programming (code writing code)
there willo be more layering and customization in the languages we use - with more powerful and expressive languages deep underneith, but with tightly constrained, layered (or mixed-in) frameworks that enforce best practices built on top. we have seen this progression going forward for the last 10 years or so, and it's starting to get really interesting now.
and on the next 5-10 year horizon, we will see applications (driving mostly by desire for better AI in games) that are human-competative in reasoning and interaction - I offer this conjecture without proof, but with significant anecdotal evidence to support the assertion.
I watching for signs of two important things in computer development: a code base that can write another codebase (metaprogram) that is (1) aware of what it just did and (2) can communicate in a complex novel way with the new code set (I'm being vague here, but you get the idea -- think compiler theory for AI), and
At my current gig (OnGame ie. PokerRoom.com) we've been using a kind of modified Scrum. The idea is to start "El Project Grande", spend a day breaking the project into parts and deciding what depends on what, then spend another day in groups breaking down the parts into parts until you have tiny pieces which ideally will take less than 16 man hours a piece.
You now have a big pile of tasks, sub-tasks, sub-sub-tasks and so forth with dependencies and time estimates (all set by the programmers themselves.) It's then up to the Scrum Master aka. "Get-those-assholes-off-our-back-person" to show the results to the customer and decide priorites.
The priorities are passed to programming team, and they then plan the first "iteration". Now, the goal of every "iteration", which typically spans max one month, is to produce a fully implemented, tested and launchable subset of the complete product.
Every day, all the coders have a *short* meeting (10-30 min). Each individual states what he is working on, what he's done since the last meeting, what he's planning to do until the next meeting and most importantly he's strongly encouraged to cry for help if he's blocked in any way.
In addition to this there's an evil, buggy Excel sheet with all the (sub-sub-sub)tasks along the vertical, and days along the horizontal. It's each programmers responsibility to update estimated hours left for tasks he has been working on each day. NB! *hours left* It's prefectly alright to up the time remaining if you have unexpected problems. So a certain task may go "16 12 4 56" hours left.
The main points of Scrum (for a programmer):
I choose to remain celibate, like my father and his father before him.
I know it's tired old hat, and probably flameworthy in this environment, but a real manager doesn't need to know what the hell you're talking about to make a good descision. All he has to do is know his people, and be willing to listen to their experience. By the same token, the most knowledgable manager in the world can still screw everything up by trying to make everyone do it the exact way he would do it if he was doing it all himself.
You need to find someone who can keep the final goal in sight, and who is flexible enough to reorganize whenever the requirements change. Agile, Waterfall, Iterative, whatever, it doesn't matter...These are ideas put together so that mediocre managers will have some kind of method that may bring decent results. They can all work great, and they can all work poorly, and it all depends on who is doing the oversight.
Management actually is a pretty solid skill if you can do it. Too much of the flaming comes from people who've never had the good fortune to work with a good manager. I myself have never worked with one who was the total package...Either they understood the work and the clients and they couldn't deal with the higher ups, or they dealt well with the higher ups but didn't understand the work or the clients.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Why do we constantly look for the "next big thing" when the "big thing" is simply experience?
To know how important experience is, one of two things needs to be true: You either need to have it, or you need to be someone who is still interested in "wisdom" in this knowledge-centric era, and be willing to listen to those who have experience, and pick the correct people who say experience is important and believe them*.
Both are fairly rare.
The rest follows from "rarity" in the obvious manner.
(*: I believe wisdom is underrated nowadays, but I won't pretend that the problem of figuring out who to listen to is not itself hard.)
The other thing is that there are next big things, but I suspect we are slowly but surely running out of "next big things" that will be comprehensible to more than, say, 25% of practicing programmers. Switch to Ruby, learn how to really use it, and add a good automated testing philosophy in, and you've gone a long ways towards extracting all the additional productivity you can get out of your environment without a major upheaval. For instance, I think it's reasonably likely (although not certain) that functional programming is finally going to come out as a reasonable paradigm over the next 10 years as it will be best able to take advantage of multi-core systems without completely upheaving how you write programs, but we're going to lose a lot of programmers on that transition, because it just doesn't click for some people. And that's a major change.
From the blurb:
Agile puts the emphasis on producing demonstrable iterations of a game almost immediately into production
So what this does basically is get something that just barely works up for review as quickly as possible. Like throwing a lump of clay on a table and saying, "There's a vase in here, somewhere."
This IMHO will do two things. First, it will give SW managers a warm feeling caused primarily from too much optimism. "All the engineers have to do is shape that clay a bit, and it's a vase! We're ahead of schedule!" Two, since they will think they're ahead of schedule, they'll report to their superiors about how they already "have a working prototype of a vase" and that'll bump up the schedule.
The engineers who actually have to implement things will know better. And they're the ones who will get stuck with the deadline. The agile pony show where you show your manager something that boots but doesn't have 98% of the functionality in it will bite you in the rear later on.
This method doesn't seem well suited to making software. However, it does seem well suited to making managers feel good. I'd avoid it.
Weaselmancer
rediculous.
We're in the process of implementing further unit tests under the agile model (though not gaming related, it is a heavily interactive app). The idea behind unit testing is to:
1) find bug
2) write unit test for bug.
3) write fix.
4) verify unit test/program both work. If unit test works, but program fails, go to step 2.
1) In your example, a tester/coder would find see some soldier dude getting stuck in the middle of battle.
2) So do it again, saving the game before the bug occurs. Write a unit test which loads this save and then check after x seconds to see where the soldier is and then fail the unit test cause he's stuck behind the crate. The unit test will is not in any way general. It's not meant to test all your pathfinding issues, just this one.
3) Rework the pathfinding code.
4) After you notice the unit test passes, go in and see if the bug is still physically in the game. If it's not, you've fixed it. If it still is, well, write another test. You may end up with a dozen pathfinding unit tests this way all of which "fix" some sort of bug.
The idea behind this methodology is that let's say your new pathfinding algo causes a bug which developer B fixes, but which causes the original case to break. Your unit test will now "clue you in" before a checkin occurs. It also free testing to do more "battle" and "feel" stuff.
-- Political fascism requires a Fuhrer.