I like to think of myself as having some understanding of how to balance anything-is-possible-ambition with where-is-the-feasible-profit-realism. After all, I've released three music albums I care to mention and several hours of music production tutorials. In order to release anything really, you have to understand when you need to spend more time to make something perfect, and when it's good enough and needs to be shipped. You also need to know how to set goals that are ambitious but achievable, especially when working independently in an art like game development. How to balance these ideas while planning the development of a game is the topic of today's article
The first thing is to know what ambition really is. Ambition is not choosing a goal you know you cannot reach. Ambition is choosing a goal that contains unknowns and perhaps the unconventional. It will thus will be a challenge, but is theoretically attainable if you are willing to put the work into it and adapt to whatever unknown difficulties arise. Don't be foolish and tell yourself "My idea for a clone of triple-a game X created by a multi-million dollar company with my own spin on it can be implemented in a year. I'm not sure what took them so long." Creating a game takes resources. Finish several simpler projects of growing length and challenge to get a feel for what resources are required to do what things before you set out to create your magnum opus. Even once you have your educated estimate, leave an error margin because there are always complications.
Another very important thing is understanding the scope of your design. You will be tempted to add features that might seem cool but do not serve the core experience. And while there is nothing wrong with that per se, it can easily stick you with a product that has an experience worthy of little more than ridicule because you spent all your time adding cool little things to your project instead of building the core experience. I recommend that in your design you label all of your features with one of three priorities: 1) the game needs this feature to be considered complete and worthy of shipping, 2) this is an important feature which really improves the game's experience but could theoretically be done without or replaced with something simpler, and 3) this feature is not necessary but I as the designer have my reasons for wanting it in the game. Here are some examples: competitive multiplayer in a horror game: 3, ability to shrink the full size map and use it as minimap/radar in an exploration game that does not rely on radar: 2, shotguns in a DOOM clone: 1. Try to get all of the priority 1 features done as soon as possible so that you have a minimal ship-able product.
And lastly, have the willpower to pronounce a project deceased once it is dead. Sometimes you get to a point where your project just isn't going to get much better without being completely redesigned and rebuilt. Don't give up every time you hit a wall or have a dry spell, but do be willing to admit when your project is either fundamentally flawed or needs shelved because you simply cannot notably improve it under the circumstances.
It may seem that this article leans further on the side of being harsh, businesslike, and realistic, and maybe it does. The problem is that when new artists aren't being suffocated creatively by their bosses and industry, they seem to seldom understand their own limits. Don't confine yourself to things that aren't innovative, or that are easy, but be willing to start simple and get a feel for what you can accomplish before you take on bigger projects.