what about programming?

Yes, those concepts can be applied to game development, as much as any software development project.

However, their use will very from project to project depending on the opinions of the project manager.

P.S. A friendly word of advice and please take it as such. Try to use correct grammar and punctuation in your posts. You'll generally get a much better response from this community. Remember, programming is communication.

Quote:

hei guys at university i'm studing agile programming and extreme methodologies, tdd, etc is thoose concepts applied to game dev?

Agreeing with ChaosEngine, you need to work on your communication skills. This board is frequented by industry professionals. Your future employer may look at your posts. Do you really want to convey that immature attitude? Since you are "at university", would you even dare email your professors with that kind of message?


The studios I've seen have adopted at agile methodologies to varying degrees. It may be as simple as daily standups or it may be a full-on formal method with task cards and frequent formal training.

While I've seen and used it outside of the game industry, I don't think games will pick up TDD for game code. Library code which is reused, yes, but not game code. TDD has a cost of almost 1:1 test to release work. When code is maintained for years and multiple releases and multiple products it makes sense to have the test suite in place.

But game code gets used once, has a single high-cost intensive debugging phase (alpha & beta cycle), and then is largely discarded; TDD does not make sense for it.

After the game code ships, anything pulled back in the libraries can easily have tests written for them if needed, so that isn't an issue.

thanks for answer!

Quote:

Try to use correct grammar and punctuation in your posts.

: ) thanks for advice, i'm learning english! forums is additional helps

Quote:

Remember, programming is communication.

+1

Quote:

But game code gets used once, has a single high-cost intensive debugging phase (alpha & beta cycle), and then is largely discarded; TDD does not make sense for it.

yeah, but i think TDD is only a design practice, functional tests is only a side-effects, and not totally fill test phase in software lifecycle

Quote:

Original post by frobBut game code gets used once, has a single high-cost intensive debugging phase (alpha & beta cycle), and then is largely discarded; TDD does not make sense for it.

Yeah, I don't think you really "get" TDD; particularly the day to day implications of the first 'D'.

Quote:

Original post by return0 Yeah, I don't think you really "get" TDD; particularly the day to day implications of the first 'D'.

What are the day-to-day implications of "driven"?

Quote:

Original post by frob Quote: hei guys at university i'm studing agile programming and extreme methodologies, tdd, etc is thoose concepts applied to game dev? Agreeing with ChaosEngine, you need to work on your communication skills. This board is frequented by industry professionals. Your future employer may look at your posts. Do you really want to convey that immature attitude? Since you are "at university", would you even dare email your professors with that kind of message? The studios I've seen have adopted at agile methodologies to varying degrees. It may be as simple as daily standups or it may be a full-on formal method with task cards and frequent formal training. While I've seen and used it outside of the game industry, I don't think games will pick up TDD for game code. Library code which is reused, yes, but not game code. TDD has a cost of almost 1:1 test to release work. When code is maintained for years and multiple releases and multiple products it makes sense to have the test suite in place. But game code gets used once, has a single high-cost intensive debugging phase (alpha & beta cycle), and then is largely discarded; TDD does not make sense for it. After the game code ships, anything pulled back in the libraries can easily have tests written for them if needed, so that isn't an issue.

But many AAA games do get maintained for years and have multiple releases and multiple products! DLC, Expansions, even new versions (Sequels) which are based almost entirely on the old code base (with further development and refactoring and newer assets.) The code base is just too huge to rewrite the whole thing every year or two (depending on the release cycle). These kinds of teams are building a multi-year product.

I'm not convinced TDD is a good model (I think it's too anal), but I do think games could use more unit testing in general. Lots gets changed in a short amount of time, and even during the lifetime of a single project there are some seriously volatile code paths that could stand to have testing... I do understand your point of TDD specifically not making it in to the gaming industry, but I wanted to weigh in on the dangers of viewing things as temporary when they are not.

Some games are throw-away, but success can turn a previously throw-away game into a multi-year project.

If there is one thing I've learned it is that code doesn't really go away, I get calls occasionally from a place I worked for two years ago (which I charge for) asking for support on systems I wrote back then. A game I made 5 years ago for warcraft 3 still has people e-mailing me occasionally about it. Maintenance might stop, but if you're making money off a project it's best to be diligent.

Quote:

Original post by Antheus Quote: Original post by return0 Yeah, I don't think you really "get" TDD; particularly the day to day implications of the first 'D'. What are the day-to-day implications of "driven"?

That instantaneous usage informs all interface and implementation design, rather than a solution being developed in a silo'd environment removed from its usage. The fact that the artifacts of the design process can act as compilable documentation and for correctness checking is a tangential benefit.

Producing a solution from a set of failing tests encourages loose coupling between types since operations must be testable in all object states, so collaborators must be mockable. Testing drives all implementation and interface design decisions, whether there is inherent value in the tests or not.

I personally prefer BDD, but to say that some code isn't worth testing because it won't be reused is to utterly misunderstand the motivation behind TDD.

Quote:

Original post by return0 That instantaneous usage informs all interface and implementation design, rather than a solution being developed in a silo'd environment removed from its usage. The fact that the artifacts of the design process can act as compilable documentation and for correctness checking is a tangential benefit. Producing a solution from a set of failing tests encourages loose coupling between types since operations must be testable in all object states, so collaborators must be mockable. Testing drives all implementation and interface design decisions, whether there is inherent value in the tests or not. I personally prefer BDD, but to say that some code isn't worth testing because it won't be reused is to utterly misunderstand the motivation behind TDD.

- TDD enforces discipline without invoking the hated management. By selling xDD, they get full conformity to high test coverage and (equivalent to) documentation with full developer buy-in. It doesn't explain why, so results are completely unpredictable.

- Design knowledge evolves from developers rather than architects. This reduces development time but is heavily subject to local minimum problem. TDD projects without strong higher level leadership end up as settling for lowest common denominator of entire team. Put simply - the most complex problem solved by such project is that of the least competent team member. Either that, or silos remain - no non-trivial knowledge can be trivially shared regardless of methodology.

- Due to previous requirement, TDD projects are highly resilient to high turnaround in personnel and varying skill level.

- Failing tests resonate with achievement driven generations, pushing some intrinsic button to get them to work done.

- TDD works if developers can write tests. That means that the domain knowledge such process can tackle is limited by the programmers working on it. BDD does not improve on that much. Even when client is present during test development, the communication programmer-client is the limiting factor.

Ultimately, the domain knowledge becomes the limiting factor. One cannot be up to date in both programming as well as domain niche. At which point the 'driven' breaks down. Programmers pretending to be business experts or business folk doing programming is a recipe for disaster.


The higher level goal is about something else. Any software that ships must be adequately tested. In practice, despite a lot of rhetoric, this always has and still means - if it builds, ship it. Having automated tests somewhere in the build process has been shown to improve quality of products.

Unfortunately, too many follow TDD dogma without understanding why. Hence it's a complete hit-and-miss.

Testing (the more the better, the more automated the better) is for shipping.
Metrics and domain knowledge are for building a better product.

TDD (BDD) is one way to address one aspect of one type of development. There is a very low upper limit on what type of work programmers are effective at driving while still remaining programmers. And I have rarely heard much talk about non-programmers driving TDD.

Quote:

Original post by Antheus - TDD enforces discipline without invoking the hated management. By selling xDD, they get full conformity to high test coverage and (equivalent to) documentation with full developer buy-in. It doesn't explain why, so results are completely unpredictable. - Design knowledge evolves from developers rather than architects. This reduces development time but is heavily subject to local minimum problem. TDD projects without strong higher level leadership end up as settling for lowest common denominator of entire team. Put simply - the most complex problem solved by such project is that of the least competent team member. Either that, or silos remain - no non-trivial knowledge can be trivially shared regardless of methodology. - Due to previous requirement, TDD projects are highly resilient to high turnaround in personnel and varying skill level. - Failing tests resonate with achievement driven generations, pushing some intrinsic button to get them to work done. - TDD works if developers can write tests. That means that the domain knowledge such process can tackle is limited by the programmers working on it. BDD does not improve on that much. Even when client is present during test development, the communication programmer-client is the limiting factor. Ultimately, the domain knowledge becomes the limiting factor. One cannot be up to date in both programming as well as domain niche. At which point the 'driven' breaks down. Programmers pretending to be business experts or business folk doing programming is a recipe for disaster. The higher level goal is about something else. Any software that ships must be adequately tested. In practice, despite a lot of rhetoric, this always has and still means - if it builds, ship it. Having automated tests somewhere in the build process has been shown to improve quality of products. Unfortunately, too many follow TDD dogma without understanding why. Hence it's a complete hit-and-miss. Testing (the more the better, the more automated the better) is for shipping. Metrics and domain knowledge are for building a better product. TDD (BDD) is one way to address one aspect of one type of development. There is a very low upper limit on what type of work programmers are effective at driving while still remaining programmers. And I have rarely heard much talk about non-programmers driving TDD.

I agree with pretty much all of this. I work at a small company where the technical/engineering staff are all into TDD/BDD and it works reasonably well for us. I wouldn't argue that it's for everyone, particularly if developers are going to half-arse it, or if the companies business goals are sufficiently nebulous so as to not concisely inform all engineering work.

Quote:

Original post by return0 I agree with pretty much all of this. I work at a small company where the technical/engineering staff are all into TDD/BDD and it works reasonably well for us. I wouldn't argue that it's for everyone, particularly if developers are going to half-arse it,

If you have responsible and experienced engineers who are reasonable open-minded, most techniques will work. Benefits of having adequately tested code (either automatically or manually) are well known and a necessity. Depending on tools, especially with recent languages, BDD/TDD also have ancillary benefits of smooth workflow and support tools (Hudson and such).

Quote:

or if the companies business goals are sufficiently nebulous so as to not concisely inform all engineering work.

Unfortunately, as companies grow, so do politics, complexity and scope. At some point projects involve 500 people directly and 2500 indirectly and that direct communication is lost.

This is why many complain that Agile as such is poorly integrated into enterprise world. But one simply cannot have programmer talking to user, when both developer as well as user have 5 government-imposed layers of legal and corporate bureaucracy above them.

Obviously, many companies do play various games to milk their employees, but even if they don't, there are obstacles to be aware of.

This remains unsolved problem and engineering is not an issue. Large organizations just bring in a lot of non-technical problems. Until governments and laws become 'agile'... Imagine legal system being developed in TDD manner, and law failing to be accepted because it fails to compile. Tax law failing to go into effect due to causing caymanIslandTop1PercentRichTaxEvasionPreventionTest() to fail...