>>857What I've noticed about GD students of both degree programs is, there's basically two kinds of people:
- People who have an idea for a game or a mechanic. They think it sounds cool in their head, and they have a pretty good idea of how it's going to work, implementation-wise. They implement it, and if it's good, they make it better. If it's not good, they admit they were wrong and think of something else.
- People who have cool ideas for video games without realistically thinking about how they're actually going to work in a game, then put them in the game, do the barebones implementation, and say "well my work here is done, what more did you guys want?"
There's a ton more BAGDs in the latter camp than in the former, but there's a fair amount of BSGDs in there too.
DigiPen's design program doesn't do a good job of encouraging game designers to think about their designs before implementing them. The way you learn how to make games in GAT 210/211 is basically "think of cool thing, write rules for cool thing, take cool thing to playtest and see if cool thing really is cool" instead of what I believe is a crucial step, which is "actually think a little bit about how the different parts of this cool thing are going to work together a tiny little bit before just shitting out your ideas onto the page." Yes, there's tons of info you can't know until you playtest, but you need to think about the cohesiveness of your design before you just plop it into some rules and call it "version one".