How do I get that first project off the ground?

[monkeykoder 103]

Programming is simple enough or at least there are plenty of resources available on here and other places to get you started there. The bigger problem in my mind is "How do I actually get a project started?". Let's just assume I have all the relevant coding background* and I am ready to hit my first game. I still have hundreds of questions on how to actually get started.

1) The ever present "What do I actually want to code" question.
A) It has to be simple enough to get something fun to play with in a month or two being a first project to keep the motivation going for the
next one.
B) It has to be somewhat entertaining or you don't get any sense of accomplishment.
C) You generally only have a couple of friends working on the project so your design somehow has to make up for the lacking skill sets.
D) If it turns out well it should be a good transition into project 2.

2) How to choose a framework.
A) It has to be useful in your game making future.
B) It needs to be relatively easy to work in or you will lose motivation to continue.

3) How do you control feature bloat.
A) You have to figure out which features you want that are in conflict with the requirements of 1.
B) You have to keep bugs to a minimum due to the low number of developers.

For those of you with successful projects how did you answer these questions?

I am beginning to see why there are so many game engines projects out there

[Telastyn 3778]

That's why your first project is almost always a clone of an existing game. What you want to do and the featureset are fixed. All you have to worry about is implementation. Once you get comfortable with that you can expand into the dicier problems.

[meeshoo 512]

Your questions all lead to one answer: Planning. You have to make a plan in which you decide what game are you making, what are the features, etc. Once the plan is done, that will determine which framework to chose, which tools and so on. Then you just implement it and see how it works. Now if it is not fun, you can try to change stuff and evolve mechanics, but careful not to get into feature creep. Generally in order to avoid feature creep, you really have to go through a process for every feature and ask yourself what does it bring to the game, is the effort worthy or not.

[stormwarestudios 211]

Programming is simple enough or at least there are plenty of resources available on here and other places to get you started there. The bigger problem in my mind is "How do I actually get a project started?". Let's just assume I have all the relevant coding background* and I am ready to hit my first game. I still have hundreds of questions on how to actually get started.

1) The ever present "What do I actually want to code" question.
A) It has to be simple enough to get something fun to play with in a month or two being a first project to keep the motivation going for the
next one.
B) It has to be somewhat entertaining or you don't get any sense of accomplishment.
C) You generally only have a couple of friends working on the project so your design somehow has to make up for the lacking skill sets.
D) If it turns out well it should be a good transition into project 2.

2) How to choose a framework.
A) It has to be useful in your game making future.
B) It needs to be relatively easy to work in or you will lose motivation to continue.

3) How do you control feature bloat.
A) You have to figure out which features you want that are in conflict with the requirements of 1.
B) You have to keep bugs to a minimum due to the low number of developers.

For those of you with successful projects how did you answer these questions?

I am beginning to see why there are so many game engines projects out there

You need to be able to manage the project. Developing a game is not about writing code, it is about managing a project from end-to-end and meeting your users' desires and needs (that is, to be entertained).

Answers to 1 and 3 are simple enough: learn Scrum, and apply it to the Agile development methodology. I leave this as an exercise for the reader to learn more. ;) Learn and use the appropriate tools to manage your project.

Answer 2 is also simple enough; choose tools that let you get stuff done. You need a "studio"-esque IDE to manage large numbers of source files and library dependencies. You need a debugger. You need a source revision control repository. But most importantly, you need to learn how to use all these tools effectively.

Doing anything less is setting yourself up for failure.