Lessons from Building Virtual Worlds

Building Virtual Worlds (BVW) is a class at the Entertainment Technology Center (ETC). If you haven't heard of either, you might have heard of Randy Pausch, one of the founders of ETC and the BVW class.

The BVW class focuses on rapid prototyping and teamwork. In 4 months, I worked and completed 6 team projects. During the process, we worked with technologies such as the Kinect, PS Move, Eyegaze (an eye-tracking device), and Phidgets. We also worked on custom ETC platforms such as the Jam-O-Drum and the Bridge.

However, the most valuable part of BVW is not the technical skills you learn. The important things are the lessons you learn from working with other people.

So, here are the most important lessons I've learned from BVW:



1. Keep an open mind about "Game Ideas"

It's hard to explain your cool idea to someone, and it's also hard to understand why someone else thinks an idea is cool. Sometimes things just click and you "get it." A lot of times this doesn't happen.

I can't tell you the number of times that I thought an idea was a bad idea, only to realize a few days later that it was "the best idea ever."

So, two pieces of advice: don't try to stonewall other people's idea - but do ask for clarification. And if you are explaining your idea to someone else, really try to explain why an idea is cool to you. Don't expect people to be excited about an idea if you just describe what the game is about.



2. If you know you need more time, lower your scope

When you realize you have less time than you need, you usually try to adapt by working harder. "It's okay. I can pull a few all-nighters."

This works for a few cases, but "working harder" can only take you so far. You might be able to cut it just barely before the deadline - but that's not good enough.

That's because the final stages of development - including polishing and testing - have a huge impact on the end product. Something you finish right before the deadline will have quite a few rough edges, and maybe a few cracks as well. Usually, it's much better to have a polished product with less content.

It usually doesn't take a lot to put the finishing touches on a game - but it's very obvious when you don't.



3. The things you care about are different from what the audience cares about

You know that little problem in your game that really bugs you? That graphical glitch or color scheme that you spent ages tweaking but just couldn't get completely right?

The player isn't going to notice that at all.

Instead, he going to have strong opinions on other things that you got used to already - such as the floatly controls or the lack of clear instructions.

As a developer, there are certain things you will obsess about. But spending a lot of time on them isn't the most efficient you can do to give players the best experience they can have.



4. Keep a Priority List

    A priority list is basically a list of tasks you need to do to complete your project with a rating of how essential each task is. It works best if the list is shared with everyone (for example, by using Google Docs).
 
 It helps you...
       Keep track of all the things you need to do - so you won't accidentally overscope
       Makes sure you work on the important things first
       Allow members to have a simple way to distribute tasks
       Keeps everyone notified of progress
       Makes you feel accomplished when you cross something off the list