If you're a student creating a game, you should be thinking about making it worthy to submit in the IGF when you finish it. If you're a professor running a project-based class where students make a game, you should be thinking about encouraging your students to make it worthy to submit to the IGF. Any student team that becomes a Student Showcase winner gets some media exposure, and will therefore have a much easier time finding jobs in the industry.
My notes from the session, on how to make your student game project as competitive as possible:
- IGF student games should not be full productions. You only get about 5 seconds to hook a judge, and even then they’ll only have time to play your game for about 10 minutes.
- Consider your game as a “Demo”: Get to the “meat” (fun) of the game instantly… within 5 seconds; easy install/config helps a lot; about three good, well-defined levels will give about 10 minutes of gameplay.
- This year there were 108 submissions, 10 Student Showcase winners, and one grand-prize winner. “Don’t enter to be the William Hung of the IGF.” Only enter a game that you think can really compete. All of your first-semester individual student projects should not be entered by rote (although some of them may be good enough to enter). Generally, your game should be a good game.
- Include an automatic Install, and Uninstall. Judges don’t appreciate random stuff that’s stuck on their personal computers. There are plenty of free install apps; use any of them.
- For long-term student projects, you can still submit a project even if some of the original team has graduated. In fact, graduates can still work on the game, as long as they don’t get paid for their effort.
- Judges repeatedly used the word “polish” to describe what they’re looking for in a game, but were clear that this isn’t just about expensive production values. Game should be a complete experience. It shouldn’t feel like there are unfinished features. (Missing levels, sure, but not missing functionality.) Game design should clearly have undergone iteration. It should be fun. Game interface should also be iterated on. Does the game give good feedback? Is the UI “juicy”? Does the game train you to play it?
- Students would do well to check out the non-finalist games of the previous year to see what didn’t win. Decide for yourself why they didn’t win, and make sure your game doesn’t fall into the same trap.
- Focus test your game. A lot. When doing this, don’t tell people how to play it; just sit them down and see if they can figure it out. You learn a lot from watching people struggle, in particular with what player expectations are. One memorable quote from a student team: “We thought everyone was playing our game wrong; then we realized they were playing it right, and we made the game wrong!” It occurs to me that this is good advice for any development team, not just students.
- Make your game single-player (or, if it must be multiplayer, include a one-player version). It’s hard for judges to coordinate to play a multiplayer-only game. Memorable quote: “A multiplayer game is just another person doing the AI for you.”
Common mistakes for student games that keep them out of the top ten:
- Bugs/crashes, art issues, or other obvious flaws (of course).
- Accessibility: what’s happening when you start the game? Does the player have any idea what they’re doing, what the controls are or how the game works?
- Language issues: use clear English in your instructions (this is mostly a problem with foreign teams).
- No gameplay, just walking around in an empty level. No matter how brilliant your game engine is, you need to create at least some content to show it off.
- If the game is clearly in a genre, make it immediately obvious what makes your game different. The judge should not say “great… not another undifferentiated FPS/side-scroller/whatever”.
- Too difficult. Some games are supposed to be difficult and that’s fine, but don’t kill off the judge before they get to the fun part.
No comments:
Post a Comment