Using Agile Methodologies To Make Games? 236
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."
An interesting approach (Score:2, Interesting)
Here's A Secret About Real Life Game Development (Score:2, Interesting)
You see them in the lunch room, outside with the smokers, hanging around in the halls of the building. Always talking about stuff with lots of buzz words, like say 'agile' for example, all sorts of very advanced sounding tech almost all of which they know very little about and rarely have had any real world experience with.
If you are reading about game development on the Net you are most likely doing more harm than good to your understanding of the topic.
Cleanroom methodology (Score:1, Interesting)
http://en.wikipedia.org/wiki/Cleanroom_Software_E
Agile methods suck (Score:2, Interesting)
SCRUM doesn't keep a history, so you have no way of checking to see if your estimates are historically too high, too low, or all of the above, and so there's no way to see if you're going to hit things on time.
There is no magic bullet. And when you've got a lot of people who need to keep working together, agile methods are useless. It's great for small groups (3-4 people), but don't bother if you've got 150 people, all with complex interdependencies. You just end up with blockage soup, and people getting pissed off.
'agile' is neat, but ... (Score:5, Interesting)
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!
pushing envelopes (Score:4, Interesting)
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
There's no magic bullet (Score:3, Interesting)
Re:Buzzwords aplenty (Score:4, Interesting)
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):
Re:Managers (Score:5, Interesting)
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.
Re:The Bane of My Existence (Score:4, Interesting)
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.
Re:Take it from me ... (Score:3, Interesting)
FWIW, I was exposed to a very rigorous and (I think effective) interview process at the second company I worked for. They had a remarkable hiring track record - a lab full of excellent engineers (most would be top-ranked at any other company) and almost non-existent turnover (over more than a decade, so it was sustained). Their process was formal and quite rigorous. Interview teams were cross-functional, even when hiring for a particular discipline (ie R&D interviewed MFG candidates and vice versa, and everyone talked to both a software and a hardware technical interviewer even if that was not their forte; we believed in hiring flexible, well-grounded generalists). Interviewers all had standard questions that they asked of every candidate - usually one 20-minute-ish technical question that was fairly open-ended and could lead to much discussion, so they could compare candidates on the same material. All of the morning interviews (usually 4) were technical. During the plant tour immedately following lunch with the candidate, the technical interviewers got together and discussed the candidate on technical merits and, if the candidate passed muster (most didn't) the managers did the "soft skills" interviews after lunch. If the technical interviews did not go well usually a short debrief with HR would close out the interview. For good candidates, the whole thing closed with a "sell job" (cool product demos, perhaps a short meeting with a high level manager to sell them on the company's prospects.
This 'agile' thing has a different goal (Score:5, Interesting)
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.
Solve specific bugs (Score:4, Interesting)
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.
Guidance on unit testing for games (Score:2, Interesting)
Check out the agile game development blog [agilegamedevelopment.com] and in particular High Moon Studios who has provided seminars at the last two GDC's [gdconf.com] on their experience with SCRUM and XP, including tips for unit testing game components. They admit that some elements of game, for example, "fun" is not something you can tests, but since games are so hideously complex, having most of your code covered by unit testing makes regression testing far easier when your 18 months and a few 100k lines of code in.
That said, I've experienced a lot of blowback in game companies about using any agile methodologies. The rank and file in most game companies are, while blindingly talented, often very stubborn and/or passive-aggressive toward anything they perceive as control. The organizations I've been in where XP, in particular, has really worked, was where most if not all of the engineers were tired of priority of the day project management from marketing, sales, etc. and where management was enlightened about the benefits of better software quality and more predictability in development. Unfortunately, to make any agile method to work requires buy-in from the top to bottom of the org chart and very few places will ever get that.
That said, I think in 5 years, most game companies will be using elements of XP, SCRUM, and other agile methodologies in their work. I don't believe game companies will be able to survive without this shift, because although some poo-poo agile for large teams, some of these techniques can work very well for large teams and game teams are only getting larger and the financial stakes of failure and missed schedules will only becoming higher. In that environment, only studios which get a handle on their development will survive. The companies that refuse will become overwhelmed by the complexity and IMHO will start losing their best people to studios that start putting agile processes in place.
Of course, EA and that ilk may continue to just chew through developers, working them 80+ hours a week for years to come, but that will not be an option for most studios and smaller publishers.
And, yes, agile comes with a lot of marketing-speak gobbledy-gook, because you usually have to sell it to management. The reality is that it's as much about controlling management as it is about controlling development, perhaps more so.
And to the example above where XP was implemented at a game company where management thought that they would simply get more features, well, that's management not understanding XP and I'd wager that in the absence of XP those same executives would have been adding the same damned features, still not dropping any features, and still kvetching that the game needs to ship for Xmas. That's the game industry folks. No process can fix that.
LQ
Re:Buzzwords aplenty (Score:3, Interesting)
The benefit in terms of reliability and maintainability is that typically multiple engineers are forced to work on any given piece of code before it reaches the maintenance stage. This will tend to force anything that is poorly written to get rewritten along the way.
Specifications (really tight specifications) are a must for this methodology to work right. I can start building you the 1.0 version as soon as you hand over a really detailed specification. When the specifier gets v1.0 (the next day or the next week...), they're then typically allowed to say, okay, freeze development while I respecify, because this isn't what I really wanted. The advantage here is that you don't go through a year's development before discovering that the spec was way off. Instead, you wind up revising the implementation until the spec and the implementation are in agreement, and you wind up with a customer happy with the spec.
Another rather important piece of agile/scrum is testing. Everything has to have lots of testing, and test driven development is the preferred model. From the spec comes the test, from the failed test comes the implementation, from the working implementation comes the passing test, from the passing test the spec is satisfied.
It really can work. Where i'm working we're considered about 2 technology years ahead of our competition by our customers. Our customers do something like $100 billion of business on our software per year. Agile can work, and it can work well, and is a great fit for enterprise development.
Structured coding (Score:3, Interesting)
The things that have come in since then have been attempts at addressing minor shortcomings in the way people work; and not always very successfully. Compare C and C++: C is syntactically extremely simple, it gives you exactly what is necessary and nothing else. C++ tries to address the perceived shortcomings of C, mostly in the areas of reuse of code and initialisation of variables; but it comes at the cost of being an excessively complicated language and it requires a huge amount of self-discipline to avoid writing impenetrable, convoluted code.