Starting a project
From DmWiki
Ideas are brilliant things. They give us motivation, they lead us to accomplish great things and when conveyed they can change the world. And, it is ideas that bring many people to our forums looking to start a project.
| Table of contents |
What you will require to start a project
To begin a project, you need yourself and some skills. All the learning material and tools you need are free, and can be found on the internet - other articles here will help you in that aspect. You also need time and dedication - a lot of it.
To begin a project, just do something. Begin creating a demo. Do not worry that your art wont be perfect or that your object methods are not the best designed because it really does not matter. You can always change things later on and learn from your mistakes to make the next project better (however do not fall into the re-writeing trap of perpetually re-starting). It is important that you have the skills to create a large part of the game in order to manage any sort of team project. Without them, your decisions will be naive and your team will not have faith in you.
Small is perfect
Be realistic about how much you can actually do. It is all too easy to think 'Add a ROAM implementation - oh, about 3 days'. But, in reality the debugging and integration will take a very long time.
A small project is not a bad project. Much the opposite. If a project is small, then the developers have a well defined focus and more polish can be applied to the overall product. It's better to have a small, finished, kickass project than a loathsome mess that'll never be finished.
Often there is the tendency to overcomplicate even a small project and in each step of developing it a principle like KISS (http://en.wikipedia.org/wiki/KISS_principle) should be followed by designers and developers.
From the ground up
Most people want to begin from zero and build every part of their game - programmers are especially guilty of this. But resist the temptation, as it will only lead to slipped schedules and low enthusiasm. There are many other ways to make a game, and the internet is filled with stable, tested open source libraries and engines (3D Engine Database (http://www.devmaster.net/engines/)) that will do a lot of work for you. Use every resource out there because your game will be finished quicker and of higher quality. The only time you should not re-use existing code is when you are taking time to learn about the particular feature.
Team players
A classic misconception is that you need a team to start a project. You do not. It may require a team of 20 people to produce a commercial quality game, but that is not the aim of a personal project. The aim is to build something that you are proud of and to gain experience.
This is not to say that having a team is out of the question, but forming a band of merry men is done after the initial functioning demo is created. For anyone with an ounce of knowledge in this field to join you, there must be a good website showing your project with code, ideas, screenshots, a blog and anything else to show it is active and healthy. For bonus points it should look nice too. Do not expect large numbers of people to join. If one dedicated user/artist/developer decides to help you, that is very good indeed. As an example, many of Gnome (http://www.gnome.org)'s desktop components have a single person maintaining them. This is because building, debugging and maintaing software is hard work.
Some tips on recruiting:
Remember who you are
Be tactful. You are asking people to give up a lot of time for you, so be as nice as you possibly can be.
A pot of gold at the end of the rainbow
If you do not have a large bank balance that you are ready to part with, do not even pretend people will be paid. Because they wont. Your project, no matter how wonderful is unlikely to reach a stage where it can be sold. Do not tell people 'you will be paid at the end when we make it big' because people know the uncertainties of business, and will not listen to anything you say after that sentence.
Grand Designs
Do not post your fifteen page design document to a forum. Link to it, but even at that consider what value it has. If it is fourteen pages of damage points for arrows, just forget about it. For great industry advice on creating a real design doc, see these gamasutra articles (require free registration):
- The Anatomy of a Design Document, Part 1 (http://www.gamasutra.com/features/19991019/ryan_pfv.htm)
- The Anatomy of a Design Document, Part 2 (http://www.gamasutra.com/features/19991217/ryan_pfv.htm)
You should also read about the litmus test
A design doc is a long, intensly detailed bible for the production crew of a game. The document itself requires a great deal of skill to put together, but the benefits from it are too vast for me to fully summarise here;
- It provides coherancy between all staff
- It provides a common vision
- It leaves no room for ambiguity or deviation from the game idea
- It forces those in charge to think about every detail.
With that said, remember a design document is not a replacement for a evangelistic designer. People can interpret text in ways the author never imagined, so it is essential that the programmers and artists have a person watching the work and guiding it. And although these documents can't guard against poor designs, there are now programs available to assist designers with creating and using these documents during the development process, like The Corpament's Video Game Design Pro 2006 (http://www.thecorpament.com).
Creative Risks
When starting a project, now is the time to take risks and do something completely bizare. This may be the only time in your life when you're not confined to market projections and budgets. So try out weird and wacky game designs and you just might stumble upon the next winning formula.
Conclusion
To make a project work you need time and perseverance. With those, the rest will look after themelves (nearly).
