This is a strange paper to read because I think I have read most of the source material, something I certainly haven't felt before in a formal research paper! I was hoping that it would be more from the context of the publisher working with Microsoft PC/XBOX developers for new information though. Oh well, maybe next time.
An Analysis of 155 Postmortems from Game Development [pdf]
51–59 of 59 posts
Re: An Analysis of 155 Postmortems from Game Development [pdf]
#52Funny sidenote: the paper mentions a game titled Age of Ornithology under 5.1.g (Scope). Naturally I got excited at the idea of a game where you play some kind of bird collector, or an intrepid late 19th-century magnifying-glass-and-butterfly-net explorer and cataloguer of birds. But unfortunately this title is some kind of cruel joke: http://www.phobe.com/sfi/ornithology.html http://www.gamasutra.com/view/feature/13…
I have a feeling this, and the rest of the games made by "Schadenfreude Interactive" aren't real, as much as I would love to play Grand Theft Ottoman or Accordion Hero, or Nazgul Thunder. Hannibal Crossing looks particularly enjoyable.
Personally I'm an IF fan, and the "Swiss text adventure games, Zurich (1980), Beyond Zurich (1987), and Return to Zurich (1993)" look like an interesting saga.
Re: An Analysis of 155 Postmortems from Game Development [pdf]
#53Earlier quoted context omitted.
Why do you say "and yet" - since such generic "advice" is useless so is the conclusion " and yet they get it wrong!" (I told you something useless - why doesn't it help?)
Because if you follow this advice, you're more likely to yield a successful product. Playtesting isn't useless. It's how fun games are made. Perhaps people are disagreeing with this because they haven't tried to make a game. A curious phenomenon.
But that's not advice. It's the same as telling a video game player that to win you need to "get a higher score than the enemy" and "play really well". And when someone loses, "I gave them such great advice, and yet they messed it up!"
"Listen to your users" is not advice, it's the end goal. What's the most effective way to listen to your users? Professional playtesting? Open alpha/beta? Forums, IRC channel, a subreddit? Frequently scheduled AMA with the devs? Infrequently scheduled AMA with the devs?
Re: An Analysis of 155 Postmortems from Game Development [pdf]
#54"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…
The Agile problem goes deeper than that.
In a perfect world, it works as other comments point out: you get better at it, and everything is wonderful.
In real life, that estimate you gave last week becomes your duty. Unless you pinpointed it, you're out of schedule. If you're late, you look bad. If you're early, you get more work next time.
And there is no good way out, you can do it poorly but in time (which will only compound time as your poor solutions will introduce more work). You can do it late but good (but, well, late). You can give stupidly high estimates and then make your own secret schedule (and get found out eventually).
Agile is Fordism.
My advice: do not estimate timings. Have a list of things TODO, and have someone monitor expectations.
Re: An Analysis of 155 Postmortems from Game Development [pdf]
#55Earlier quoted context omitted.
Because if you follow this advice, you're more likely to yield a successful product. Playtesting isn't useless. It's how fun games are made. Perhaps people are disagreeing with this because they haven't tried to make a game. A curious phenomenon.
You simultaneously complain the advice is generic and claim it's useful. You always bet on both colors in roulette? No, generic advice is not useful. It's... too generic.
[deleted]
Re: An Analysis of 155 Postmortems from Game Development [pdf]
#56Earlier quoted context omitted.
Because if you follow this advice, you're more likely to yield a successful product. Playtesting isn't useless. It's how fun games are made. Perhaps people are disagreeing with this because they haven't tried to make a game. A curious phenomenon.
But that's not advice. It's the same as telling a video game player that to win you need to "get a higher score than the enemy" and "play really well". And when someone loses, "I gave them such great advice, and yet they messed it up!" "Listen to your users" is not advice, it's the end goal. What's the most effective way to listen to your users? Professional playtesting? Open alpha/beta? Forums, IRC channel, a subred…
Play the game. When you notice something isn't fun, remove that thing. Repeat. That's playtesting.
If you want to watch someone doing this, pull up some videos of Notch making games. That's the process he follows constantly, from start to finish. He also has good taste, which is why his games turn out well.
If you don't have a nose for what's fun and what isn't, you have to take feedback from your users. If it's a multiplayer game, you should take feedback from the most competitive users, ideally from the people who are trying to form pro tournaments around your game. Casual players don't care what you do to the game, because it doesn't affect them much. But competitive players are your lifeblood, even if you don't know it yet. A competitive scene is what carries a game after its shelf-life has expired.
Re: An Analysis of 155 Postmortems from Game Development [pdf]
#57Funny sidenote: the paper mentions a game titled Age of Ornithology under 5.1.g (Scope). Naturally I got excited at the idea of a game where you play some kind of bird collector, or an intrepid late 19th-century magnifying-glass-and-butterfly-net explorer and cataloguer of birds. But unfortunately this title is some kind of cruel joke: http://www.phobe.com/sfi/ornithology.html http://www.gamasutra.com/view/feature/13…
I have a feeling this, and the rest of the games made by "Schadenfreude Interactive" aren't real, as much as I would love to play Grand Theft Ottoman or Accordion Hero, or Nazgul Thunder. Hannibal Crossing looks particularly enjoyable.
I saw the word 'Schadenfreude' and was reminded of a satire talkshow on a radio station in the PC game Grand Theft Auto IV
Found it: Pacemaker - putting the heart back into the healthcare industry. https://youtu.be/jG9BgjnpGGY?t=940
Re: An Analysis of 155 Postmortems from Game Development [pdf]
#58"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…
The Agile problem goes deeper than that. In a perfect world, it works as other comments point out: you get better at it, and everything is wonderful. In real life, that estimate you gave last week becomes your duty. Unless you pinpointed it, you're out of schedule. If you're late, you look bad. If you're early, you get more work next time. And there is no good way out, you can do it poorly but in time (which will onl…
Here's the problem I keep coming back to with task estimation for implementing software. This is the absolute minimum description of what a software engineer's responsibilities are: Giving the correct set of instructions to a computer about how to accomplish a task.
Given that, a precise understanding of the time involved to accomplish a task requires knowledge of the time it takes to come up with the correct instructions + the time it takes to give the correct instructions to the computer. The time cost to give instructions to a computer is effectively linear in the size of those instructions (its whatever my typing speed is times that size), but the time cost to understand what those instructions need to be is effectively unknowable unless I've already got those instructions. It's sort of like the halting problem for people... if I knew how long it would take to come up with a reasonably precise version of them, you'd have a version of those instructions that could execute in some language (say some imaginary pseudocode language), or I'd have determined that the task is impossible.
I can keep a heuristic understanding of how long a task will take based on previous tasks I've completed (i.e. this task sounds similar to this previous one, which took me this long. I'll use that for my estimate), but there will always be some set of tasks for which I'm wildly wrong unless I precisely examine what's involved.
If it's better to estimate in a fashion such that I deliver everything I promise (and that we can have a planning session that doesn't last the entire sprint), I can pad my estimate by a large factor. In general, its easier to meet the criteria for this situation, but there will still be tasks for which my estimate can be wildly off. This can also lead to unhappy product owners who assume I'm trying to rig planning to excuse less work.
How do you come out of this exercise unscathed and with valuable information?
Re: An Analysis of 155 Postmortems from Game Development [pdf]
#59Earlier quoted context omitted.
But that's not advice. It's the same as telling a video game player that to win you need to "get a higher score than the enemy" and "play really well". And when someone loses, "I gave them such great advice, and yet they messed it up!" "Listen to your users" is not advice, it's the end goal. What's the most effective way to listen to your users? Professional playtesting? Open alpha/beta? Forums, IRC channel, a subred…
Play the game. When you notice something isn't fun, remove that thing. Repeat. That's playtesting. If you want to watch someone doing this, pull up some videos of Notch making games. That's the process he follows constantly, from start to finish. He also has good taste, which is why his games turn out well. If you don't have a nose for what's fun and what isn't, you have to take feedback from your users. If it's a mu…
"Noticing something is not fun" is the archetype of non specific advice. There are tons of games i dont find fun yet many are very popular and other folks seem to enjoy them. And even then even if you do playtesting you need to ensure your sample is representative and things like that.
Playtesting is key but its far from being a simple step in itself and it never tells you exactly what is the right solution to fix things. Thats why making games is hard.