When to start actually programming

Started by
9 comments, last by waylonflinn 11 years, 4 months ago

The sooner you can get something working the better. Start with the simplest idea it's possible to implement and implement that. Pick something you have a chance of getting completely prototyped in 2 weeks. This will help you:

  • figure out if what you want to do is technically feasible
  • figure out if you actually like it

The next step is building enough so that you're comfortable showing it to someone else. Try to reach this step as soon as possible. After all, it's other people who are going to be playing your game the most. Ideally this will happen within a month. This will help you:

  • figure out if other people actually like your game
  • help prioritize which of the things you already know need to be done, should be done first

I recommend showing it to people who will be both honest and supportive. You need both. Show it to more than one person. This will be scary. Do it anyway.

Just because one person doesn't like it, doesn't mean it's not good. Try to listen to the people who don't like it, because you'll learn a lot, but take what they say with a grain of salt. If you think your idea is good, chances are there are at least 100 other people in the world who do, too. Your job is to find them.

Find at least one fan, someone who thinks what you're doing is awesome. Show it to them regularly and listen to their feedback. They will keep you motivated and on track. If you can't find anyone in your life like this, use the internet.

The process described above has most of the core features of Agile Development without all the extra crap designed for managers in a bogus corporate hierarchy.

Some notes about this process:

It is iterative. You will modify the structure of existing code over and over again, especially the new code, without much affecting it's functionality. This is not a bad thing. It's called Refactoring. Learning to embrace it will make you more productive and help you to discover new things about design, as you code. It is at the moments when you begin a refactor that you should consider the forest and the placement and shape of the tree you are about to plant.

When you show your game to people, their suggestions and criticisms will sometimes surprise you. This is good. Some of the surprises will be useful, some won't. Take care to decide which is which. A hint in this area: the useful surprises usually turn out to be very useful. The others usually don't make much difference either way, they're just a time sink distracting you from the useful stuff. Knowing who your audience is will also help with this.

Find Games, With Science

Crunch Magic

This topic is closed to new replies.

Advertisement