Live data from Hacker News

“What Went Right and What Went Wrong”: Analysis of 155 Postmortems from Gamedev

research.microsoft.com

31–40 of 52 posts

Re: “What Went Right and What Went Wrong”: Analysis of 155 Postmortems from Gamedev

#31
post #25
post #18

Earlier quoted context omitted.

If your friend was not very senior (10+ years experience), I would not believe what he says, since he probably did not have enough experience to judge the situation. I think the idea that the game industry is "behind" other fields is kind of comical, given that games are some of the most complex software in the world, and big game teams have only a few hundred people on them, and meanwhile something relatively trivia…

TDD might not apply well to games because they are used by big corporations for 15 or 20 years. It makes more sense when you're working with old legacy code and you want to add features to it. Unit tests are definitely not a all-around solution but they have their use cases.

It makes more sense when you're working with old legacy code and you want to add features to it.

No!!

Testing is not merely about future proofing (although it's a really nice benefit), it's about proving that your code actually works now. By writing tests and verifying that they pass you can be sure that the code actually does what you think it does. Furthermore you can ensure that when other parts of the code changes your code still does what you think it does, which might be an issue tomorrow, next week, or in ten years.

\* note: Testing does not prove that your code is correct, only that it satisfies the conditions of the test. As with all engineering testing is only effective as the person implementing it.

Re: “What Went Right and What Went Wrong”: Analysis of 155 Postmortems from Gamedev

#32
post #10

Earlier quoted context omitted.

I think this is a symptom of a fear of "I don't know." If I could change one thing in dev cultures, I would instill a healthy respect for the sentence: "I don't know, but here's $how_I'll_find_out and here's $when_I'll_have_an_answer."

Exactly right. Too often I've seen people commit to a schedule where the milestones were of unknown difficulty. When cutting through a new jungle, you have no idea what is between you and your goal, so really all you can say is that the best you can hope for is X if this jungle happens to be like previous ones. This is especially true in startup situations where you are learning technologies that may themselves not b…

It's not agile to list out 32 milestones on the way to completing a project and estimate them up front. It's agile to list 32 steps and estimate the first step, which you will still get wrong.

Re: “What Went Right and What Went Wrong”: Analysis of 155 Postmortems from Gamedev

#33
post #22

The old post-mortems in Game Developer magazine were written almost in template form. Went right: 1) Great team/culture 2) Everyone put forth the effort (scheduled crunch) 3) Some amazing techwork or artwork or designwork etc... Went wrong: 1) Didn't anticipate x/y/z 2) Burnout (remember that crunch)? 3) Bad/lazy scheduling and/or capacity planning Kudos to the people who did this at MS but you're looking at tainted…

What are the real reasons for successes and failures? You left me hanging...

People making mistakes, of one type or another. In these post mortems though, they rarely attribute mistakes to any individual, or even team.

Re: “What Went Right and What Went Wrong”: Analysis of 155 Postmortems from Gamedev

#34
post #14

Earlier quoted context omitted.

One of my friends who just left being full time in the game industry pointed out to me that the game industry is 10 years behind in software development best practices. Churn and burn (like many startups) is a daily reality.

I got into professional game development in the last few years and found that the state of good, modern software engineering practices in the game world is years behind, say, web engineering. Games are still all closed source. Game engineers prefer to sell their components for a pittance (for example, on the Unity Asset Store) instead of collaborating on GitHub. They really, really hate writing tests. There's a deep…

I still remember suggesting code reviews to my dev manager in 2003-ish. He didn't know what they were, and scheduled a meeting where he could review my performance, instead. Awkward.

Re: “What Went Right and What Went Wrong”: Analysis of 155 Postmortems from Gamedev

#35
post #31
post #25

Earlier quoted context omitted.

TDD might not apply well to games because they are used by big corporations for 15 or 20 years. It makes more sense when you're working with old legacy code and you want to add features to it. Unit tests are definitely not a all-around solution but they have their use cases.

It makes more sense when you're working with old legacy code and you want to add features to it. No!! Testing is not merely about future proofing (although it's a really nice benefit), it's about proving that your code actually works now . By writing tests and verifying that they pass you can be sure that the code actually does what you think it does. Furthermore you can ensure that when other parts of the code chang…

Unit testing makes a lot of sense for game engine code, but less so for game-logic code, which tends to be highly volatile and specified only qualitatively.

Re: “What Went Right and What Went Wrong”: Analysis of 155 Postmortems from Gamedev

#36
post #18
post #14

Earlier quoted context omitted.

One of my friends who just left being full time in the game industry pointed out to me that the game industry is 10 years behind in software development best practices. Churn and burn (like many startups) is a daily reality.

If your friend was not very senior (10+ years experience), I would not believe what he says, since he probably did not have enough experience to judge the situation. I think the idea that the game industry is "behind" other fields is kind of comical, given that games are some of the most complex software in the world, and big game teams have only a few hundred people on them, and meanwhile something relatively trivia…

Maybe you would say that most webapps, no matter the complexity of business logic are "not hard", but I've seen TDD work quite well and practiced by senior (10+ years) programmers to great success.

Re: “What Went Right and What Went Wrong”: Analysis of 155 Postmortems from Gamedev

#37

I found the Games Outcome Project to be much more rigorous(and anonymous) on the what practices help and hurt gamedev: http://gamasutra.com/blogs/PaulTozour/20141216/232023/The_Ga...

If you compare the conclusions, this topic's research, while obvious, is closer to reality that the one, which concluded that crunch literally "makes games worse" despite the fact that every single game, which made a significant critical/financial impact had a period of crunch.

> despite the fact that every single game, which made a significant critical/financial impact had a period of crunch

this argument doesn't necessarily disprove the notion. it's plausible to suggest that whatever impact they had was mitigated to some degree.

Re: “What Went Right and What Went Wrong”: Analysis of 155 Postmortems from Gamedev

#38
post #18
post #14

Earlier quoted context omitted.

One of my friends who just left being full time in the game industry pointed out to me that the game industry is 10 years behind in software development best practices. Churn and burn (like many startups) is a daily reality.

If your friend was not very senior (10+ years experience), I would not believe what he says, since he probably did not have enough experience to judge the situation. I think the idea that the game industry is "behind" other fields is kind of comical, given that games are some of the most complex software in the world, and big game teams have only a few hundred people on them, and meanwhile something relatively trivia…

> something relatively trivial like Twitter has 4000 people

there is more to twitter than the web app you type dozen words into.

i don't much about them (including whether 4000 is accurate), but presumably there's a lot to work on regarding international near-realtime messaging infrastructure, high availability, machine learning, sentiment analysis, smart advertising systems, yadda yadda. 4k does seem like a lot, but i doubt their suits are interested in needlessly hiring people to sit around picking their nose.

Re: “What Went Right and What Went Wrong”: Analysis of 155 Postmortems from Gamedev

#39
post #3

> 9. CONCLUSIONS > > We find that we were able to identify both best practices and pitfalls in game development using the information present in the postmortems. Such information on the development of all kinds of software would be highly useful too. Therefore we urge the research community to provide a forum where postmortems on general software development can be presented, and practitioners to report their retrosp…

Turns out software estimates are hard. Who knew?

Re: “What Went Right and What Went Wrong”: Analysis of 155 Postmortems from Gamedev

#40
post #37

Earlier quoted context omitted.

If you compare the conclusions, this topic's research, while obvious, is closer to reality that the one, which concluded that crunch literally "makes games worse" despite the fact that every single game, which made a significant critical/financial impact had a period of crunch.

> despite the fact that every single game, which made a significant critical/financial impact had a period of crunch this argument doesn't necessarily disprove the notion. it's plausible to suggest that whatever impact they had was mitigated to some degree.

It sure does not. My concern is that in this research they correlate the amount of crunch with quality of a game and show that "better" games have statistically less crunch. Since I know the games, considered successful in the industry, all have a lot of crunch, it sounds like they use their own criteria for quality, which has nothing to do with the common meaning.
Post reply on HN