Critique Design Doc
- Don't make assumptions about development. Can provide possibilities, but don't present them as explanations or justifications. Don't use possible development issues as defense of bad design. Once it's a final product, problems are problems, even if they're understandable. Don't be so sympathetic.
- Don't make assumptions about others' experiences, use specific personal anecdotes.
- Give evidence for EVERYTHING.
- Don't be nice to a game just because people like it. You won't be nice to Uncharted, so why were you to Crash?
- What makes an element trivial or difficult? Don't dismiss stuff - go in-depth on everything or don't bring it up at all.
- In Crash 1, *the physics were bad*.
- They were not *necessarily* hard to program - I know nothing about the programming process of Crash's physics - but they were *definitely* poor. Don't be so sympathetic.
- ALWAYS try to give constructive ideas as to how a bad aspect of a game could have been done better. This requires the most *arguing with yourself*.
RAW Paste Data