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."
And so started a cycle of hatred towards methodologies about how to be productive in application development.
To me, the wild wild web is still here. I still get my kicks from coding without set in stone documentation and I still hate schedules.
I've always had the view that every project was a wild animal. Worse yet, it's a wild animal in sheep's clothing. And you approach the sheep with a shepherd's hook. When the veil is lifted and you see man eating marsupial with alligator teeth and a scorpion's tail, you have no choice but to throw the shepherd's hook at them and give it all you've got.
And this is how I approach managing a development project. You remember prior projects and throw together a bag of tools that have worked before and then you set to taming the beast. If you tell yourself "Waterfall works every time" then you're just going to find yourself with a shepherd's hook facing a lion or a bear.
Instead, you learn to adapt to every situation and that's the important thing. The rules are few and loose. The customer has the power to destroy everything and you have to deal with it. The best development is done on the fly with just enough documentation to convey the big idea of what's going on and keep everyone on that page. Given real life schedules and timed deadlines, there is such a thing as too much documentation.
Agile development is better in that it allows you more play and doesn't inhibit spur of the moment innovation. I think some of my most demoralizing moments have been when I realized some great new possibility for a project only to have my manager tell me that so much documentation would have to change that "maybe we'll put that in next year's scope." I find this to be ridiculous.
What was happening was people were starting to assume that waterfall was the silver bullet for project management. "What kind of project is it?" "I don't care, we're using the waterfall." And the big problem is that the waterfall is only considered 'adaptable' if you're ok with reworking everything from step one. Is this really necessary for every project though?
Another new thing we have these days is a "framework" that fits a specific type of problem well. You can throw these together on the fly and have very little documentation because the framework provides a well known implementation strategy (see Spring's MVC).
It is my opinion that using an incremental deliverable approach with frequent customer meetings and executive power at any point in the project is the most successful strategy. The "rules" you have to adhere to are up to you and should be purely a case by case basis.
Why do we constantly look for the "next big thing" when the "big thing" is simply experience?
My work here is dung.
because of the iterative process of Scrum and the short work cycles of Sprints, redirecting a project rarely results in large volumes of wasted work.
... cause that last pair of words ... wasted work ... seems to hit my teams especially hard quite often right now. We'll finish LARGE tasks, perhaps bundle multiple items together into one large release (cause this is how management wants it) ... and by the time it gets to UAT testing many development hours have been spent ... and then the UAT tester will turn around and say ... nope ... don't need/want that ... and thus all those development hours are wasted. I'd love to get a workflow like SCRUM implemented in my workplace.
I like this
I doubt it. Smart dev teams have been using iterative development cycles and keeping their code tidy since a long time before anyone coined the buzzphrase "agile" (or using SillyCapitalLetters and calling things "extreme", or any of the other hype we've put up with lately).
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
My current project is using Agile methodology for development. It's great when you don't have full requirements at the beginning of the project. It would be interesting to apply this to games, and really makes sense. It seems like this would be much more organic approach and I could see it really useful in large games such as WoW where you can develop different areas while in production. A successful choice of methodology really depends on your project and what would be best for the team. Your choice of a methodology isn't a silver bullet to a successful project.
"creating prioritized vertical slices that iterate on the most critical elements and features"
Can someone tell me what this means?
Computers are useless. They can only give you answers.
-- Pablo Picasso
Any time you see someone interviewed about game development on the web or in a magazine chances are pretty good that the reason that person has the time to waste is they aren't valuable enough to be busy doing actual work on game development.
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.
Agile development with C++? Sure, it can be done. But one of the nice features of that language is its ability to model the application domain using Classes, Objects, Inheritance. If you don't take the time to model the problem correctly, you can painfully pay for it later on. Sometimes you get faster development times if you actually take a day or a week and model your problem so that it captures the essense of what you are trying to solve using objects, etc.
An iterative approach where you use a greedy method of implementing each new feature as quickly as possible with little insight into the overall system may or may not produce optimal results. It can lead to lots of spaghetti code. Or maybe not. Certainly in my career that approach sometimes *has* led to cleverer solutions as I was forced to think up the best, simplest way to imlement them. But often it can lead to massive amounts of spaghetti code that doesn't make much sense or capture any insights into the problem.
But can I synergize with my results-driven knowledge base while partnering with self-managed teams, increasing single-source responsibility while undergoing a complete paradigm shift?
I didn't think so.
Working at a major game company, here's what happened when someone here raised XP:
The guy who suggested it, "It's an itterative development model. We identify core features, develop those features, refine those features with the customer, then add the next layer, repeating as we go. We gain much better code as every component meets the customer's need as it is developed, challenging the customer to think about it in context, and allowing us to add additional itterations if needed."
Management, "So, we can identify additional features throughout development?"
"Absolutely. You just have to assign additional resources (time/people) to account for those extra features. But, by identifying them as they come up, you end up with a much better system that really does everything right."
Over the next few months, features kept getting added, developers dutifully updated schedules. All was happy. Followed by...
Management, "This was supposed to ship before thanksgiving. It's now slated to ship in the new year. We'll entirely miss the holiday season."
Rapidly realizing his mistake for suggesting it guy, "Yes. But you kept coming up with new features. And they are great new features. Think how much better the product is for it."
"If we miss the holiday season market, we lose money. This has to ship 'on time'."
"But on time is a function of how much you add. We're developing everything to schedule. You've just increased the features so increased the schedule."
"The schedule can't move."
"So you'll have to lose some of the remaining itteration milestones. You'll have to drop features."
"But we like all the features we've come up with."
"But adding features adds time. You've known that since the beginning."
"We've known this has to ship for the holiday season and you promised us we could have extra features. You're just going to have to work more overtime. Fortunately you're overtime exempt so that won't cost us anything to get this project back on schedule."
"It is on schedule. You just changed the schedule by adding features that were identified along the way."
"You told us your wonderful "XP" model would let us do that. We gave you the chance to try this new method under the understanding we got these benefits."
"And you do."
"Good. Then make your schedule."
"We are mak-"
"No arguments. This discussion is over. You promised you could deliver the extra features. You're now behind schedule for the holiday season. You're just going to have to crunch. End of discussion."
Yeah, thanks XP.
Never, ever, raise exciting new methodologies to management. They will hear all of the advantages and expect every last one of them as though it was the perfect implementation of the method whilst completely failing to hear (and certainly refusing to act on or implement if they do hear) any of the trade-offs that have to be made to enable those gains.
Sounds like more touchy feely mumbo jumbo to me. Coffee, red eyes, bad breath, late nights, divorce... that's how software gets done dammit..
This article only compares two methodologies, but does not include my favorite. Cleanroom methodologies require documentation and some planning up front, which I firmly believe in the need for. In addition, it is also about getting something working in an iterative process.
n gineering
http://en.wikipedia.org/wiki/Cleanroom_Software_E
We're using them where I work. They cause a huge mess in communication and a lot of grief for the developers. It also allows the designers to change their minds on a whim - which means that the project keeps stalling.
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.
Isn't this the general methodology employed by id Software? I'm sure Carmack and his team spent much time behind the scenes prototyping ideas, but the actual game release was preceeded by a very lengthy test release process to solicit feedback early in the cycle.
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.
Tragically, I couldn't RTFA because of th excessive market speak.
In order to energize the evolution of computer games we need to synergize on the vertical slies... WTF?
I guess people forgot to mention that writing computer games rates up there with writing operating systems in complexity...
Yes Francis, the world has gone crazy.
I thought the main thing about Agile software development was automated testing.
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
"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..."
;)
Yes, for those of you playing buzzword bingo, I just got a BLACKOUT!
30 days is fast? I wish I had 30 whole days to do my projects!
I love iterative development, but scrum didn't impress me much when I was involved with it. Perhaps that was just due to the management that implemented it. We went from logging bugs and tasks in bugzilla to writing them on index cards (do I really need to point out to computer people how stupid that is?), and trying to plan projects on these obscure, poorly implemented planning tools.
Iterative development is great, but scrum strikes me as nothing more than another useless management fad.
This is just an issue with management, though. A good manager will trust his engineers (or fire them and replace them with trustworthy alternatives). The manager's job is to set the direction of the project, get the engineers what they need to steer in that direction, and then get out of the way as much as possible and as quickly as possible.
It's staggering how many managers don't realise this, and hamstring their dev teams with their personal, half-baked, technically-incompetent ideas and/or with excessive procedures and beaucratic reporting because the manager "has to know what's going on". Of course he does, up to a point, but what exactly is he going to do if a developer does tell him that a bug fix was delayed by a day because {$TECHNOBABBLE}? If he's not going to act on some information, he doesn't need to know it, and requiring developers to take time out of their day to "keep the manager in the loop" more than necessary just disrupts development.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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!
What do you think I'm lying? :)
Believe me, if I started murdering people, there would be none of you left.
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
I have been developing products for a long time (decades if you must know). For what it's worth, it is my experience that the people on the team have by far the biggest impact on product quality, timeliness, and all those other goodness measures. I believe that the methodology is almost immaterial. Good engineers will instinctively use the appropriate process for the problem at hand. Now, this doesn't necessarily scale to very large projects, which is why I am a firm believer in loose coupling. As soon as practical, decompose the big project in to a collection of loosely coupled smaller projects and then put in place the teams (unfettered by process dogma) to develop the pieces. Ahh, you ask, but what process do you use to decompose the system? See my earlier comment - choose a small team of very good engineers and have them do it. Don't tell them how -- they already know that. Trust people, not process. Ironically there is one process that I believe is critical to every organization's success, and it probably the least-studied, least-optimized, least-formalized process every company has ... and that process is the interview process. Clearly if I am going to trust my people to do the right things and make the right choices, I had better hire the right people. Anyhow, that's about $0.93 more than my $0.02 so I'll step down off my soapbox now.
The more you regulate a company, the worse its products become.
No wonder you can't, nobody can do all of those three positions from the "Kama Sutra of Software Development" at once - "Synergizing with a results-driven knowledge base" by itself already requires an unusual ammount of body flexibility
"as everyone else pointed out, it's mostly just a name for what people have been doing for a while when upper management leaves them alone." - by bunions (970377) on Wednesday June 28, @01:04PM (#15622175)
Agreed 110% - most of said "mgt." AND "business/system analysts" out there haven't written a single line of code themselves either (this & the tools involved are just another set of "B.S." & buzzwords they need to justify them even HAVING a job in this field).
This comes from 15 years total time in this field as a coder (programmer/analyst - software engineer)...
Too many "chiefs" exist in this field, that plain just should not. Not without having done the job themselves, hands-on professionally, in this field.
(This is not always true, but largely, I have seen this over my career in this field, & it is just plain WRONG).
Am I the only one who doesn't at all understand what the summary says?
Ok so we've already established that iterative programming isn't the next big thing, it is simply what most programmers do. Iterative programming is simply a name for how most developers build projects. You write code, test the code, move on to the next code. Not being a game developer, I can't say from personal experience, but I'll bet thats how most games were made anyway.
Someone even touched on unit testing and continuous integration as game development methods. Saying unit testing can't cover 100% of a game's code may be accurate, may be not, I'm not a game developer. But the big complicated problems that can't be caught with unit testing can at least be narrowed down by unit testing. Ok, so you can't test everything that will happen in a big game, but you can test all the little things. Knowing that all the little things work helps make debugging the big things easier. If you can't test how an AI will move through a map in certain circumstances, you can at least test how the AI recognizes the map, recognizes objects in the map, and the ability of it to move and navigate. So on specific map A, the AI can't get around this crate. Well, can the AI recognize the map around the crate? Can the AI recognize crates? Can the AI navigate? All questions unit tests are meant to answer. Though I must say, I've been through crazy complicated business "ill-logic" , and I have yet to run into something that can't be unit test besides users.
But ok, what about the other aspects of agile development? Most of what has been left out is more on the human side of development. Aside from iterative development and TDD, what about pair programming? What about daily stand ups? What about 'no code ownership'? Without these, it isn't agile, it just iterative development or TDD. Agile development by name pertains as much to the people and how they are organized and managed as it does to the code itself.
So the game is to figure out what bullshit like this means?
The problem using any software development methodology which requires user feedback for new product development is that you don't actually have any users - best you can get is a marketoid and those change their minds every 5 minutes.
./ for the last couple of years, the main process problem with game development seems to be that a lot of the control over the final product lies with Marketing, and worse, Marketing is in a different company altogether (the producer) than game development - so even with good managers on the software development side (already unlikelly) it's difficult to control the the flow of wacky ideas "that just have to be included in the game" coming from the marketoids - thus requirements creep is rife, which almost guarantees that long hours and death marches are standard.
You see, the closest you have for a user of a new game is a gamer and those can't really help you refine your requirements 'cause all they want from a game is to be entertained and they don't really know beforehand how a new, entertaining, game will look like - "having fun" is hardly an easy to define business process.
Maybe some sort of mixed approach where you have a game designer with an overall view of the game concept and a generic pool of gamers to check out the "fun factor" during game development. Might work well for games with an "exploration" component (for example RPGs) for which you can design the early levels, "test" them with some gamers and then use the result to fine tune those levels and later ones. Still, i doubt it can be usefull in game genres such as RTS and Sims.
More in general, and judging from the posts i've been seing in
http://www.diamondcrush.net/
It's a Super Puzzle Fighter rip-off, totally written in Java. The project was born in the developers forum of the italian hardware website http://www.hwupgrade.it/
Now I can finally use that +20 agility enchant!
Proud member of the American Non Sequitur Society. We might not make much sense, but boy do we love pizza!
Any time you see someone interviewed about game development on the web or in a magazine chances are pretty good that ...he has much-needed information about the very process of game development to share and is rightfully not wasting time with personally tooth-brushing bits on the next DNF?
This has been the method utilized by many Indie game develops for years, if not decades. I'd hardly call it "the next big thing," since it's been around for quite a while. Perhaps big developers haven't been using this method, but it's been around for longer than this article thinks.
Dear diary: Today I stuffed some dolls full of dead rats I put in the blender.
opps another sprint started. Ship date Dec 06.
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.
They should start over with Duke Nukem Forever. This could be the answer they've been looking for to get it completed. :-)
A manager's job is not just to get the project done on time, under budget, as best quality as possible -- it's also to liason between their team and the high[er|est] levels. For those at the highest level of a large company, you're looking at possibly dozens or hundreds of projects. How does a company distill the important information that policies and decisions need to be based upon? If you're going to analyze data from dozens of projects, you'll need common metrics -- which means bureacratic "red tape" in order to get values for those metrics.
I will add, however, that micromanagers, and managers without competency, or at least familiarity, of the skillsets needed for the project, can often harm production. But, you need to keep in mind the full responsibilities of a manager -- that {$TECHNOBABBLE}-caused delay will need to be explained to his boss -- unexplained delays are by default inexcusable.
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
The problem right now is that too many companies are developing new technologies, implenting them and then sitting on their propriotary coding so that no one can steal it.
This is adding a huge amount of redo-work in the industry. Right now, many video games are requiring budgets bigger than blockbuster movies because of this mentality.
There is not real standardized programs and artwork. Almost all graphics are recreated for every single game out there.
This is like movie makers getting rid of all background sets and actors for every movie.
The software industry is caught in a vicious loop of overly expensive proprietary technologies. There is little real standardization between games except for some of the tools. And even then, only some of the tools.
This is why when technology for improved video graphics comes out, no one uses it as they have to almost totally redo all of their artwork again and again.
There needs to be more technology licensing at a lower breakpoint, otherwise the gaming industry is going to pop like the Internet bubble did. We are already seeing signs of "struggling" publishers and design companies, because the industry is just starting to be supersaturated with games that cost too much to design.
No! It's a *SIG*. Keep the Special Interest Groups away! (Con joke!)
Does anyone else have a problem with the reply header being blue text on a blue banner? I thought the CSS was *supposed* to be better!
Which can never be done reliably for non-trivial projects with the tools and techniques we have available today, regardless of what anyone trying to sell you their book says. No-one has yet shown how to beat picking two of cheap, fast and good.
Which is a much higher level than the sort of day-to-day project stuff we're talking about here.
It doesn't, in this context. Again, no executive of a large company should routinely be involved in the day-to-day progress of minor projects by a particular dev team. That's not their job, and it's the worst kind of micromanagement.
It also means you need metrics worth something, which random estimates for project timescales based on the inadequate information that was available six months earlier most certainly are not.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Seems like the whole idea the article suggests is a pipedream. So their great and new idea is to complete the most important features immediately, then refine them. Well that is all great, but what about the fact that a game usually isn't remotely playable until it is 90% done, no matter which pieces you work on or do in what order.
This reminds me of something I just read about how episodic content will never work, as making episode 1 requires 95% of the work of the entire game.
Show me raw, tangible statistics pitting Agile methodologies against other more traditional approaches, like "waterfall". I'd like to see a whole range of games (or other applications), developed using various methodologies and scored based on parameters like: shipped on time, end product quality, popularity, critical review scores, and, of course, amount of profit. This would be the only way to see how much "better" Agile is compared to other methodologies. Otherwise this is all just theory, speculation, and unadulterated opinion.
Despite what EULAs say, most software is sold, not licensed.
Sorry, can't read TFA, uuungggh...can't get past the title no matter how much of a running start I get. Why do people keep saying "methodology" when they mean method? Though I've never found a use for the word myself, I suppose that methodology would be the study of methods. What's "agile" got to do with programming? Weasels are agile...so this is methodological advice given by weasels? Oh nooo...can't uncross my eyes--somebody take me to the emergency room!
Great men are almost always bad men--Lord Acton's Corollary
It's staggering how many managers don't realise this, and hamstring their dev teams with their personal, half-baked, technically-incompetent ideas and/or with excessive procedures and beaucratic reporting because the manager "has to know what's going on". Of course he does, up to a point, but what exactly is he going to do if a developer does tell him that a bug fix was delayed by a day because {$TECHNOBABBLE}?
The most important thing is never having knowledge, but knowing when your knowledge ends. This is the case in every situation I've encountered. When I was working tech support the absolute worst callers were ones who thought they were computer savvy and weren't (the best callers usually being ones who didn't know a damn thing about computers and were quite happy to make this clear). The most annoying management decisions are the ones made about things managment has never touched and without asking for/paying attention to advice coming from the people who are actually doing it. The most annoying software I use comes from developers who think they know better than the users what the feature set should be. Heck, I know people who have gotten themselves into serious financial trouble by jumping into the stock market on a tip without taking the time to learn how the market works or taking any time to research the tip. (I just saved a none too tech-savvy friend a whole lot of money by working hard to convince him to stay the hell away from the Vonage IPO.)
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.
Since when has people STARTING to adopt methodologies been worthy of slashdot? Game development takes years if this honestly works that's fine, but we need to know of games that were fully created with Agile methodologies.
There's a few flaws. Can someone tell me why a working prototype would be better when you're working in a company of a couple hundred people? I work at a semi major game developer and let me tell you, working on a early game type, you need those design documents just because you have no idea the vision, then coming on to the game later, you'll need those documents again because no one is going to flawlessly comment code so a new programmer is screwed.
Game development companies need to make tools, because otherwise you have people doing worthless repeditive work. In game editors are worth more than the guy who solves minor bugs, because that in game editor will be used by almost all the users, a minor bug could probably be solved by everyone. The guy at my company who designed a system for adding gameplay easily is easily worth more than the person who fixed the rendering bug, because the first guy's work takes hours off of everyone's time table when they have to create their own event, the second guy has better end result but that could have been done at any time.
Their ideas are interesting but sadly it sounds like it's more focused on small scale products with 15-20 employees, rather then large scale products.
Besides which any time you have large scale products you're already working on the scrum type of cycle. At least if your in a semi intellegent company, that wants to have good communication with out killing the team with it.
The only flaw in using Scrum is you can't use it for the first monthes of development. Your focus needs to be on developing the world there, but you need those paper guidelines. And worst as the game grows and you're prototypes look finished in a protype world, and they get tossed into a real world almost every single one will end up breaking, whether through a problem with the animation being updated, the world getting a new nav system, the controls completely changing, and so on. And so for another 2-3 weeks you're wasting time on prototype fixes again updating them.
In the end it is helpful, and with a good company it works well, and it does beat the waterfall system, however it isn't the savior. It sounds more like the writer believes the waterfall system has 0 communication where the programmer and the designer never talks. That's not how the system should work, that's how a poor company implements a mediocre system.
The bigger problem though is his comment that there's going to be less crunches because of it? Since when. Any time a major system gets changed in the final monthes all subsystems will have problems, ones that were finished earlier are inevitably going to have more errors. Crunches happen, you arn't going to make them disappear, if you don't want to crunch, go talk to Duke Nukem Forever, or Daikatana about that, that's about the only way.
This is nothing new in game development, even at large companies. 'agile' (with a little A) has been used for at least a decade. You just can't possibly build a good game with the waterfall model and we've known that forever. I think it's a bit like every generation thinking they invented sex.
We use nightly builds (a single day without a working build is a huge hit). Getting the framework working so your designers and texturers (and gameplay folks) can start trying stuff in-engine, then fleshing out features. Midding sized time periods (2-4 weeks) between major builds. Unit testing. Though we have to bring in humans to really break it when it's all put together.
Now if you mean Agile with a capital A, then it's not the next big thing, it's just the same bullcrap it was when it was called eXXXtreme Programming. We like to write things down and design a lot of things up front, which clashes with Agile (and don't tell me it doesn't, even with the lip service) - you need at the very least a production bible for large project games to keep everyone together. Parts of the design will sometimes not survive actual implementation and will be tossed, but in general they keep things on track and usually only need some tweaking (everything gets tweaked during playtest time).
If you don't do this sort of thing you end up with http://en.wikipedia.org/wiki/Dungeon_Lords, which is what you get with a Agilely (with a capital A) developed game. It shipped only half complete with no internal cohesion at all and still isn't finished. But the great thing is that you can use your Methodology to justify it all.
As a programmer, I like RUP.
As a project lead, I like RUP.
It has aspects of Agile to it.
The important parts are:
Get the risky stuff addressed early. If DX9 doesn't support bi-pixar multi-shading like it says it does, then it is best to find out early rather than at the end.
Do the work in measurable chunks. That way you know in as little as a month if you are falling behind schedule.
Frequently interact with the users to make sure you are on course. This is the biggest problem with waterfall projects- working 6 months on something and it turns out you made a wrong turn on week 2. And I've seen other programmers do this again and again even with user interaction- they get an idea of what the program should be like in their head and turn off input from reality.
All the documents and crap bother me to and feel like useless makework. At least video game programmers do not have to deal with SOX compliance issues.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
Scrum isn't a software engineering method. It is purely a project managment methodogy. That is one if the _key_ differences between Scum and other Agile methods.
Hardware is cheapest.
... the more expensive operation will be.
Developer time is cheap.
Operational time is expensive.
Why? Because dev time occurs at inception. Operational costs (including post-release patching) are recurring.
The less documentation you have post-release, the less organised your software, the less well understood your architecture, the more convoluted your tools
If you just live in the mad world of shove-it-out-the-door and making it somebody else's problem, then congratulations. You don't care about operational expense. You don't have to care. Any manager who doesn't care, and who doesn't make you care, is either similarly constrained, or horribly negligent and short-sighted.
So-called agile development is the bane of operations.
But it's good for the next quarterly bottom line, so who the hell cares if next year you're screwed?
historically games were often developed in environments of intense pressure
if a game development effort is not at gold master by say september 15 then it would not make christmas and if it failed to make christmas then it would lose 70% percent of its revenue
many smaller development houses were created or broken by a single game that simply shipped or failed to ship on time. discovery wrote arkanoid and built their subsequent business around the revenue from that one title.
the way i recall developers working therefore was many small short sprints with multiple people often huddling around one screen, visually auditing the code as one person typed it and acting as feedback and expertise. managers and executive watching everything intensely closely and demanding frequent milestones. these were extremely high stakes development efforts and everybody knew it.
unit testing and regression testing and the like was not done, but there were monkeys in the back that tested the builds all day long and provided a constant stream of test report data; and of course the app developer was often a subscriber to the experience as well and often there would be late night play sessions against the latest build - simply for fun.
- a
God knows managers have to find something to talk about to justify their salaries.
Malike Bamiyi wanted my assistance.
Or maybe the process actually works and he has free time to have a life outside of work and share his insights with other companies.
I work with Rory (the author) and he's an invaluable member of the team. So something has to be working right.
I think you're missing my point re: metrics. It's not the individual metrics that count -- it's the aggregate metrics that matter in the long term, especially to the highest levels. Without collecting those metrics at the lowest levels, it's impossible to have accurate analysis.
What if the question is, "Which manager is more effective at making sure their team meets deadline?" or "Which team is hobbled most by inadequate managers, and is therefore a priority for assigning a talented manager?" As multiple projects are completed, this is the way to measure success|failure in a way that can be demonstrated to those who need to know.
As to inadequate forecasting of timescales -- measuring that is just as important for determining how to better forecast them as it is to determine whether a certain manager or team habitually misses deadline.
Again, I think the problem is that you're only looking from the perspective of an engineer on a team, or a team manager, not someone responsible for long-term success of many teams and many projects.
Finally, another word on metrics -- despite how inaccurate they may be, or how poorly they represent what's happening in the trenches, they are invaluable when you need justification for terminations, selective promotions, and raises. Employment law has created a situation where these things MUST be documented or else you're exposing yourself to a boatload of risk.
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
I'll stick to loading up agility on my Thief for that trick attack multiplier.
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.
Of course not. For that you would need a best of bread enterprise solution with lots of buy in from those who will take ownership to solution flexibly
Methodologies are important, just as long as following the methodologies doesn't become more important then producing quality products.
Klingon Software is not released, it escapes, inflicting terrible damage onto the enemy as it does
software development isnt as much a project as it is a evolution.
you set some goals about what the software should be able to do, and then you try to evolve the best ways of doing it. along the ways the goals may well change, and therefor the direction things evolve will do to.
i guess thats why open source wins in the long run, you can do it darwin style.
at some point the source will split, and the more successfull banch will survive, potentialy absorbing whats good about the other branch on the way.
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
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.
Check out the agile game development blog and in particular High Moon Studios who has provided seminars at the last two GDC's 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
but 75% of the cost of the game is in the art work, so creating all that is not going to change significantly regardless of any development methodology.
...what matters is what you like, not what you are like...
That's funny (in an amusing, obersvational way) because I work in a large company and the clients in the company actually like to see early versions, provide feedback & testing and then sent back for another quick iteration. They absolutely hate not seeing something for 6 months and discovering it doesn't do what they hoped for. Every company's different. It's important to adapt your methodology to the reality your project lives in.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
While I agree with you to an extent (but there are plenty of people who will screw up when left alone), it did remind me of this:
Four stages of acceptance of a theory:
-- J.B.S. Haldane, Journal of Genetics
Reengineering our paradigm towards monetizing our customer base will indubitably ramp-up our global synergies and dovetail smoothly with our virtual workspace vertical portal initiatives, monetize bleeding-edge networks cultivate end-to-end infrastructures utilize interactive applications brand frictionless web-readiness scale value-added networks harness impactful mindshare revolutionize one-to-one architectures drive killer e-services aggregate bricks-and-clicks applications, and stuff.
But you have to use the process.
Games I played are full of bugs (I've been QAIng those for free)
"Because managers don't trust engineers."
Oh, I can't imagine why.
A great engineering manager is one who would likely be an excellent all-purpose journalist: someone who is extremely smart, dedicated, and people-savvy, and is not obstinate, arrogant, or aloof. If they are extremely smart that more than makes up for not having current technical skills, since they can learn what they need to know by carefully interviewing the members of their team, watching how they do, and sizing them up.
In practice, there are two types of people that seem to become development managers: those who determine in their late 20's that they aren't going to be great engineers, and those who decide in their mid 30's that they want to make more money than devs are making. Those in the former camp aren't extremely smart. Those in the latter camp are usually smart, but too often they are not dedicated enough, not people-savvy enough, or too obstinate, arrogant, or aloof. Great development managers are few and far between.
Anytime you see a post on Slashdot by someone in the game development chances are pretty good that the reason that person has the time to waste is they aren't valuable enough to be busy doing actual work on game development.
Seriously though, I'd say writing about game development is contributing to actual work on game development in a very meaningful way. Just because it's not contributing to one of the milestones on a project doesn't mean critically thinking about the process is meaningless.
I've been waiting for a squad-based combat game (not just red team vs. blue team, but groups of players on the same team working together, instead of a mass melee) that actually encouraged cooperation. I've been promised it before (Battlefront II, Republic Commando), but never quite got it. Perhaps now we'll see that. And some more open-ended maps.
Map design, while it's good for some games, is really lacking. A map is more than just a plane with objects on it. You need to be able to interact with those objects. You need to be able to go INTO buildings, throw boxes, push dumpsters, stack rubble. You know, something resembling more of how you could do things in the real world. Let us up on the roof for God's sake! I shouldn't have to discover an exploit to have a good sniping spot.
Rawr
You forgot an important word: enterprise. If it is not enterprisy, then it is not good.
Structured coding has so far been the only really big thing in programming; anything else since then has just been fads. Structured programming made it possible to write code that was reasonably easy to follow logically - compare a badly structured COBOL or FORTRAN program to well structured C program to see what I mean.
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.
Not by a long stretch does game development relate to operating system development.. Games are not hard to develop. They cost boatloads of money on artists and middleware and marketing. There is a huge uncertainty about being successful and simple commercial interests in other directions can get a game cancelled. A game does not have any real complex elements. The rendering is a stand alone component, the AI, the sound.. all relatively easy modularized parts.
Something that compares more to an operating system in terms of complexity is something like a top notch dbms. Or any of the ms office and open office products. A C++ compiler... But a game is not comparable.
Aside from all the utter bullshit marketing/corporate language, this so-called agile development methodology seems to be pretty similar to how people develop outside of any particular methodology constraints (such as the dreaded waterfall, oh how I hate you). In particular, it seems to be particularly close to how the open-source community write software. In this land of eternal betas (not you, Google), this is how it happens; first the bare, most basic, but core features will be written, and then slowly the project will sort of fill out with other important features and polish. In fact, I thought that was part of the Unix philosophy -- didn't Doug McIlroy say `Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.'
At the end of the day, I thoroughly dislike any enforced development methodology, but this `agile' system seems to be relatively close to how programmers naturally work, so I'd imagine it's a lot more intuitive to work with.
The Shoes of the Fisherman's Wife Are Some Jive Ass Slippers
Which leads to the point that you either need a manager who has some understanding of the business process of software methodology or has a SENIOR developer (read 'architect') who he can rely on. A good manager in the software world needs to understand documentation. They really need quasi-technical skills. Sure, a CIO can leave the details to an architect, but somewhere a quasi-technical needs to be in the decision making loop to provide push-back so the company's "business needs" don't always overrun engineering sensibilities. (Yeah, I feel like a Dilbert comic strip today...)
What do you mean my sig is repetitive? What do you mean my sig is repetitive? What do you mean....
But my post is actually due to the person who linked in the article. It seems to me like the article is discussing the RESULT of Agile strategy, which is Scrum. So I feel like I looked into the article with the wrong idea because the focus was actually on a spinoff that has been doing well.
Not sure why I posted, just figured I'd mention it. Offtopic me if you must *shrug*
Hahaha! Metrics! My company has a top level executive that's nuts about metrics. He gives all these nice looking Power Point presentations explaining how this or that has improved. What he doesn't realize is that now that people realize that they actually get rated (even though possibly at a group level) on what they say they spend their time doing, they tend to skew the numbers they turn in to look better. Add to that the fact that if I turned in accurate metric numbers, I'd be spending *all* my time keeping track of the numbers and no time actually doing work. So its garbage in, garbage out!
The problem there is twofold -- the exec has poorly designed metrics (if they are so easy to falsify and so difficult to report accurately), and the reporting structure is not sound. They don't have to be complex to be useful.
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
The term was introduced in 1970 by W. W. Royce; ironically, Royce himself advocated an iterative approach to software development. Royce originally proposed what is now known as the waterfall model as an example of a system that he argued "is risky and invites failure"
http://en.wikipedia.org/wiki/Waterfall_model
Thankfully, I'm a hardware engineer and never had to learn about such nonsense.
If you must moderate, please moderate as irrelevent, not something bad, because I'm sure someone will find this interest
-1 not on bandwagon.
Your quote reminded me of this quote:
First they ignore you
then they laugh at you(this is worthless nonsense)
then they fight you(this is an interesting, but perverse, point of view; this is true, but quite unimportant)
then you win(I always said so)
-Gandhi
Please, for the good of Humanity, vote Obama.
I use agile methods to play games! First iteration: stay alive for 2 seconds ... dang failed. Second iteration: run a different direction ... dang dead again. Third iteration: jump, then run, anywhere ... dang dead. Fourth iteration: press buttons and randomly move stick ... not again! The game developer's management loves me, I can't get off level-one.
Sig erased via substitution of an identical one.
Actually, Dungeon Lords was NOT developed using Agile/agile methodologies, nor was it developed using a waterfall method. And methodology has nothing to do with the justification for the game's state of completeness - in the end that rests entirely with end-users who didn't return the game after seeing the state it was in and therefore contributed to publisher profits. If people are willing to pay money for unfinished products then they shouldn't be surprised when that's what they receive.
I agree. When have you seen a project manager with a textbook in his hand following institutional guidelines anyway? There are good project managers and there are bad ones. My guess is that the good ones rely on original ideas and a solid structure/organization rather than cookiecutter concepts.