Live data from Hacker News

An Analysis of 155 Postmortems from Game Development [pdf]

research.microsoft.com

21–30 of 59 posts

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

#21
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…

I don't think this as anything to do with the quality of art. Dealing with assets is a pain, dealing with assets on multiple platforms is worse. I'm guessing those dealing with multiple platforms paid more attention to the process. Where those working with a single platform probably didn't think about the issues with at a much. Getting the art right, it's probably more important on multi platform.

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

#22
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…

I don't think this as anything to do with the quality of art. Dealing with assets is a pain, dealing with assets on multiple platforms is worse. I'm guessing those dealing with multiple platforms paid more attention to the process. Where those working with a single platform probably didn't think about the issues with at a much. Getting the art right, it's probably more important on multi platform.

Do you mean stuff like making shaders for multiple incompatible platforms or all art in general?

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

#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 with tiny memory) required completely new game engine architectures. That was finally figured out, but development on the PS3 seemed to run about two years late, which set Sony back.

Now there are mature game engines, mature physics engines, the graphics pipeline is in good shape, and the hardware is powerful enough. Problems in game development now are more about the game than the underlying technology.

(Pre-1990s, game development was a cram job, trying to get stuff done on limited hardware.)

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

#24

This is excellent for the history and for the examples of what worked and what didn't. But the interpretations are a little dubious: Takeaway: Game developers should create a well-defined concept before beginning development as opposed to an ad hoc method of game design. This would exclude Dota, for example. Gamedev is a world of exceptions. In general, it's best to playtest every idea you come up with and cut whatev…

Having "a well-defined concept before beginning development" would seem to include Dota and other successful mods, because Valve is starting with a successful game concept (compared to the vast majority of mods that never find an audience). For Counter-Strike/TF2/Portal/Dota, Valve took a strong existing concept and developed it. It's exactly what's recommended in the takeaway.

You are probably thinking of Dota 2. Both Dota, CS and TF where most likely developed ad-hoc as they were mods that grew organically.

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

#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 well enough, we need to estimate better next time.

2. Maybe this estimation thing is impossible to get right, let's not put too much trust in being able to estimate accurately, but rather find ways of working that don't require estimating all work up front.

I've seen that 1 gradually becomes 2 with experience (the experience of getting the estimates wrong every time).

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

#27

Earlier quoted context omitted.

I think there is a misunderstanding: Dota doesn't apply to the quote "Game developers should create a well-defined concept ..." since it was neither conceptualized nor made by the Warcraft programmers. Additionally, the originally Dota started as a mod, was then published as a game, and Dota 2 would then not count as a mod. Its not hard to come up with a definitive answer to that. A game is a mod if it doesn't stand…

The Warcraft 3 engine was flexible enough to implement Dota, just like the Unity engine was flexible enough to implement Rust. By your criteria, Rust is a mod, even though it's clearly not. It's better to say that mods are games and to treat them the same than to try to differentiate them. The same design process that yields a successful mod will yield a successful game.

Rust is not a mod, but is a clone of a mod of Arma2 called DayZ.

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

#28

Earlier quoted context omitted.

Having "a well-defined concept before beginning development" would seem to include Dota and other successful mods, because Valve is starting with a successful game concept (compared to the vast majority of mods that never find an audience). For Counter-Strike/TF2/Portal/Dota, Valve took a strong existing concept and developed it. It's exactly what's recommended in the takeaway.

You are probably thinking of Dota 2. Both Dota, CS and TF where most likely developed ad-hoc as they were mods that grew organically.

Their were Age of Empire mods that were essentially MOBA scenarios. I don't doubt many such ideas are ad hoc genius, but a lot of game dev is re-hashing with a twist.

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

#30
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…

so true. the estimation game can work well on time scales of up to a few months (like 2 or 3)... maybe

anything beyond that scale becomes the educated guessing game. no amount of analysis can flesh out every blocker that will be encountered. the deeper you go analyzing each task, the more the work just becomes doing that task.

Post reply on HN