Random Tidbits from GDC 2008 for Students

To add to my notes from last year, here are some random bits of conversations I had this year that students may find interesting:

• Game projects that actually solve a social problem rather than merely being fun will get you more press, because most student game projects don't have any practical value to the player. If you provide some, you will stand out. Note that in the case of a game that raises awareness of an issue, the call to action can be the reward for beating the game!


• Evaluate lots of game authoring tools, from Game Maker to DarkBasic to Torque. Reviews listing the strengths and limitations of each would make for an excellent post on your blog if you have one, and could be of great help to professors who might be considering some or all of them but who have no time to evaluate them. This will also give you great practice at getting up to speed with a new tool, something you will probably have to do from time to time in the industry.


• If you go to GDC, don't drink. I know there are tons of great parties with open bars, but just don't do it. Think: how much did you pay to go to GDC? Probably $1000 or more. How many free drinks would you need in order to make the cost worthwhile? Too many. So, use your time at parties productively: network, meet people, find out who's hiring. Once you have a full-time job, you can buy your own drinks.


• Tip from Brenda: a great way to get promoted at a game company is to find a stressed-out lead and ask what you can do to help. This is also a great way to get noticed as a student if you find a stressed-out professor who used to work in industry.

I also found some interesting advice specific to student game projects, courtesy of the games that won this year's IGF Student Showcase:

• For student projects, keeping the scope small and focused should be your number one priority. Nearly all of the student IGF winners this year only showcase a single game mechanic; then they build the entire game to support it. If your proposed game is large enough that it requires the inclusion of mini-games, it is too big for you to finish. If your proposed student project is a mini-game, you're probably on the right track.


• You can make a better student project if you learn and use good tools. This year's IGF students used a wide variety of tools: Anim8or, Photoshop, Cubase LE, XNA, Adventure Game Studio, Aftereffects, Source, Visual Studio, 3DSMax, SVN, MS Project, Excel, Panda 3D, Python... you name it. These can save huge amounts of time. Learn at least a few of them early on in your college career, so you'll have the time to use them on projects during your final year.


• Rapid prototyping with iteration is your best friend. If you can't have your student game project up and running in some form in a week or two, it's too big. Use a steady stream of testers who have never played your game before, and keep modifying to make the new-player experience as solid as possible.


• If at all possible, work on team projects rather than working alone. The game industry really cares about whether you can fit in to a team, and if you can only create projects on your own it will be much more difficult for you to get hired... no matter how brilliant your projects are.


• Enter your project in lots of competitions. Many students reported that the pressure of competition forced them to keep their scope small and their quality high while still making regular progress.


• When coming up with a name for your game, make it something pronouncable. It just annoys people when they have to say "Narbacular" or "Poesysteme" or "Synaestheste"...


• Make your game extensible. If your game ends up being really great, you may want to continue working on it after graduation to make it into a full, commercial game.


• If working on a project for a class, do as much preproduction work as possible before the semester begins. If your team enters the class already knowing what the concept is, you'll have that much more time for iteration.


• Some game concepts are not particularly challenging for programmers or artists. If you are working on one of those teams, you may be tempted to make things more complicated just so you can show off your skills. Don't do this. Do what's best for the game, not what's best for the developers.


• The best Producer for a student project is someone who's really good at details. When the game has a thousand small tasks (and reasons why half of them need to be there), it's great to have someone on your team who can keep track of all this stuff, and it's even better if that person is the producer.


• The best game designers for student projects aren't the ones with the best game design skills, but the best people skills. Game designers are going to be telling everyone else on the team what to do, and being able to order your peers around in a way that encourages buy-in and good feedback and communication is absolutely critical if you want stuff to get done. If your "best designer" is a programmer, he or she can still contribute to the design (and will happily do so).


• If you finish your student project and it's something you're happy with, consider incorporating as an LLC. It's cheap, it's easy, and it means you all now have a shipped title at a professional game studio.