An Analysis of 155 Postmortems from Game Development [pdf] • Hacker News Board

Re: An Analysis of 155 Postmortems from Game Development [pdf]

#31

Post by michaelt » Mon, Jun 06, 2016, 8:27 AM UTC

shmerl wrote: post #6

> When looking at games developed for one platform versus games developed for multiple platforms, we found a few advantages and disadvantages to choosing one over the other. First, 46% of developers that used multiple platforms listed art as something that went right, while only 33% of developers that used a single platform listed this. Additionally, 15% of the developers that used a single platform listed this as so…

Some games have targeted consoles, created a bunch of console-resolution textures and other art, then ported to PC and been slated for the low-resolution textures and art.

Or at least, that was the case last time I read the gaming press about 10 years ago. I don't know if it's still an issue these days.

Re: An Analysis of 155 Postmortems from Game Development [pdf]

#32

Post by greggman » Mon, Jun 06, 2016, 8:54 AM UTC

Animats wrote: post #23

Reading this, it's clear that game development is now a mature technology. I was working on physics engines in the late 1990s, when nobody really knew how to do that very well. There were Gamasutra postmortems where the game physics went badly wrong and things flew apart. In the early years of the PS3, game projects were failing because the Cell architecture (a small PowerPC CPU plus six auxiliary Cell processors wit…

apparently they aren't though. People porting from PC to other platforms are still finding huge perf issues and have to refactor tons of code. I thought this gen (PS4/XboxOne) were going to be easy ports but from every team I've talked to they aren't

Re: An Analysis of 155 Postmortems from Game Development [pdf]

#33

Post by greggman » Mon, Jun 06, 2016, 9:01 AM UTC

> Example of poor project management: Leonard Paul of Moderngroove stated that Modern Groove – The Ministry of Sound Edition suffered from poor project management because they had no dedicated project manager. Most of those responsibilities were given to the lead programmer, which resulted in an over burdened team. Paul said “I believe hiring a good manager early in the project and having clearer deadlines would have definitely helped the project.”

> Takeaway: In order to avoid conflicts during the development process, teams need to have proper management.

This seems like the exact opposite of Naughty Dog's advice

http://www.latimes.com/business/technology/la-fi-tn-naughty-...

Re: An Analysis of 155 Postmortems from Game Development [pdf]

#34

Post by mjevans » Mon, Jun 06, 2016, 9:15 AM UTC

greggman wrote: post #32

Animats wrote: post #23

Reading this, it's clear that game development is now a mature technology. I was working on physics engines in the late 1990s, when nobody really knew how to do that very well. There were Gamasutra postmortems where the game physics went badly wrong and things flew apart. In the early years of the PS3, game projects were failing because the Cell architecture (a small PowerPC CPU plus six auxiliary Cell processors wit…

apparently they aren't though. People porting from PC to other platforms are still finding huge perf issues and have to refactor tons of code. I thought this gen (PS4/XboxOne) were going to be easy ports but from every team I've talked to they aren't

A lot of the criticisms I've seen for failed ports describe the exact type of behavior you would expect from an emulated system.

The ports you reference behave like game systems that used to occupy 100% or almost 100% of the resource capacity of a dedicated system failing to execute correctly when they're running in a non-dedicated environment.

They also had the advantage of targeting an exact set of hardware specifications in other ways and didn't have to scale down, up, or sideways (other ways of dividing labor) to the way that other platforms work.

In short, they weren't a game designed to scale to a theoretical platform that then ran on the platforms, they were fit precisely to a single platform and then weren't designed to be portable at all.

Re: An Analysis of 155 Postmortems from Game Development [pdf]

#35

Post by norswap » Mon, Jun 06, 2016, 9:37 AM UTC

The conclusion:

> Finally, based on our analysis of the data we collected, we make a few recommendations to game developers. First, be sure to practice good risk management techniques. This will help avoid some of the adverse e ects of obstacles that you may encounter during development. Second, prescribe to an iterative development process, and utilize prototypes as a method of proving features and concepts before commit- ting them to your design. Third, don't be overly ambitious in your design. Be reasonable, and take into account your schedule and budget before adding something to your de- sign. Building o of that, don't be overly optimistic with your scheduling. If you make an estimate that initially feels optimistic to you, don't give that estimate to your stake- holders. Revisit and reassess your design to form a better estimation.

It's amazing how common-sensical this all his. But then again, we could all use a little more common sense sometimes.

As Charlie Munger would put it: "It is remarkable how much long-term advantage people like [Warren Buffett and myself] have gotten by trying to be consistently not stupid, instead of trying to be very intelligent."

Re: An Analysis of 155 Postmortems from Game Development [pdf]

#36

Post by optforfon » Mon, Jun 06, 2016, 10:49 AM UTC

13hours wrote: post #26

"To avoid schedule slippage, game developers need to spend more time to plan out all the work that needs to be done so that no tasks are overlooked when giving estimates. By planning out tasks, you can also estimate each task individually, and give a more accurate prediction, instead of an optimistic one." When things don't work out according to the schedule, there are generally two reactions : 1. We didn't estimate…

I think you're talking about "first year of work" levels of experience. Estimation is hard - but a major goal of Agile development is to make it possible.

I thought the same thing as you, but a month ago someone explained it to me in a way that makes a lot of sense https://news.ycombinator.com/item?id=11641316

Actually a lot of the comments about this PDF can be summed up with "practice Agile development"

Re: An Analysis of 155 Postmortems from Game Development [pdf]

#37

Post by LionessLover » Mon, Jun 06, 2016, 11:47 AM UTC

optforfon wrote: post #36

13hours wrote: post #26

"To avoid schedule slippage, game developers need to spend more time to plan out all the work that needs to be done so that no tasks are overlooked when giving estimates. By planning out tasks, you can also estimate each task individually, and give a more accurate prediction, instead of an optimistic one." When things don't work out according to the schedule, there are generally two reactions : 1. We didn't estimate…

I think you're talking about "first year of work" levels of experience. Estimation is hard - but a major goal of Agile development is to make it possible. I thought the same thing as you, but a month ago someone explained it to me in a way that makes a lot of sense https://news.ycombinator.com/item?id=11641316 Actually a lot of the comments about this PDF can be summed up with "practice Agile development"

How does that possibly solve the problem being discussed here? Are you the god who can define ALL tasks (in the agile meaning, a sprint consisting of a number of tasks) that a large project consists of up front, all the way to the end of the project 3 years later (for example)? Agile delivers because it doesn't attempt the impossible.

Re: An Analysis of 155 Postmortems from Game Development [pdf]

#38

Post by elcapitan » Mon, Jun 06, 2016, 12:01 PM UTC

LionessLover wrote: post #37

optforfon wrote: post #36

Earlier quoted context omitted.

I think you're talking about "first year of work" levels of experience. Estimation is hard - but a major goal of Agile development is to make it possible. I thought the same thing as you, but a month ago someone explained it to me in a way that makes a lot of sense https://news.ycombinator.com/item?id=11641316 Actually a lot of the comments about this PDF can be summed up with "practice Agile development"

How does that possibly solve the problem being discussed here? Are you the god who can define ALL tasks (in the agile meaning, a sprint consisting of a number of tasks) that a large project consists of up front, all the way to the end of the project 3 years later (for example)? Agile delivers because it doesn't attempt the impossible.

The problem seems to be that although companies want to pretend that they are all agile, the business and planning side really is not, because resources are not unlimited. So if you can't (even if admitting that it's faulty) put a number on time and effort, someone else higher up the ladder will do, and then it will hurt you.

I think that toolchains should have better support for estimated vs used time and then learning from that. You could classify tasks by field (DB, frontend, etc) and then calculate correction values based on past failures. Learning from wrong estimates seems to be even harder than estimating, because it hurts to admit that you were wrong, so some automated, blame-less version of it (per sprint or so) might be a good start.

Re: An Analysis of 155 Postmortems from Game Development [pdf]

#39

Post by LionessLover » Mon, Jun 06, 2016, 12:01 PM UTC

norswap wrote: post #35

The conclusion: > Finally, based on our analysis of the data we collected, we make a few recommendations to game developers. First, be sure to practice good risk management techniques. This will help avoid some of the adverse e ects of obstacles that you may encounter during development. Second, prescribe to an iterative development process, and utilize prototypes as a method of proving features and concepts before c…

When the results look bad it doesn't mean people don't follow common sense. For example, when the project would never get approval and a budget with realism but will get both when risks are left out when asking for money it's common sense to ignore risks. The team has a budget for another year, and what happens then is a different problem. The main objective of employees is not to get projects done, it is to get paid.

Unfortunately our system has created perverse incentives: What manager or entrepreneur can afford to take a step back and say "what I'm proposing may not work, let's stop the project"? We have chosen to work under a pressure as if our lives are at stake (and they are - not our bodies, but our livelihood). The guy selling worthless shit, getting people to buy stuff they don't need, that may even be bad for them (or for those producing them) does not have problems. The same guy voluntarily giving up his job where he would have to do things he thinks are actually bad and/or useless is seen as a "parasite" on society - he's not working and we still have to feed him???

You bet all my estimates show the project is worthwhile if I don't have an (equally good) alternative.

Re: An Analysis of 155 Postmortems from Game Development [pdf]

#40

Post by LionessLover » Mon, Jun 06, 2016, 12:04 PM UTC

elcapitan wrote: post #38

LionessLover wrote: post #37

Earlier quoted context omitted.

How does that possibly solve the problem being discussed here? Are you the god who can define ALL tasks (in the agile meaning, a sprint consisting of a number of tasks) that a large project consists of up front, all the way to the end of the project 3 years later (for example)? Agile delivers because it doesn't attempt the impossible.

The problem seems to be that although companies want to pretend that they are all agile, the business and planning side really is not, because resources are not unlimited. So if you can't (even if admitting that it's faulty) put a number on time and effort, someone else higher up the ladder will do, and then it will hurt you. I think that toolchains should have better support for estimated vs used time and then learn…

My response was to optforfon's comment... I don't see how your response fits in in that context. optforfon's claim seems to be that Agile fixes the planning problem - which it doesn't, it simply limits planning to that which is plannable and (much more) easily foreseeable - small tasks right in front of us.