After 6 months of hardwork making simple games, I learned so much from doing the "backend work" like coding the game logic and just challenging myself with every game I create. A few questions comes to mind after working on these projects.
In the game industry:
1) Who decides the scope of the project? I am not sure if this is the same thing as saying who controls the scope of the project?
2) How is the work evenly distributed and how much work is given to the programmers behind the game? Depends on the complexity of the game? How long are deadlines for the game programmers on average for a task?
3) I heard certain features can be scrapped from the game which is something the game programmers will have to live by, is that true?
4) Is there someone on the team that can accurately estimate how long a project is going to take?
5) If a programmer only knows gameplay programming, is it difficult for him to break in to the industry?
1) Everybody helps with the scope. Designers have a say because they are trying to create the best game possible, and good designers are able to work within constraints of time and budget. Team leaders, development directors, producers, and executives all are involved in ensuring the scope fits the constraints. Before the project is even approved there is considerable debate and discussion about size and scope, and that discussion continues through the entire product until it is out the door.
2) Exactly how work is divided depends on what the work is. Some tasks are big and need to be broken down, "write an engine" is many thousand smaller tasks, "hook up this UI screen" might be a single task that takes a few hours.
3) Yes. Good designers can create designs that are wonderful and would improve the game, but that get cut for many reasons. Sometimes the idea just cannot be implemented because it requires many changes. Other times a feature that misbehaves may need to be scrapped due to complexity or performance reasons. Sometimes a feature that a few people like needs to be cut because it makes the overall game experience better. There are many reasons features get cut, and it happens multiple times in large projects.
4) Some people are better at estimating than others. It requires actual practice and careful review, which most people don't like. For the past three years I have been on a team with one programmer, one modeler, one animator, etc. All of us have become very accurate in our estimates because we do them very frequently, we constantly review how we are doing against our past estimates to improve them, and if we estimate badly it means overtime. Having overtime as a direct consequence of a bad estimate is a great motivator to improve them.
5) Gameplay programming is the most common thing in games. Most entry level workers are GPEs. They fill out most of the content in the game, and do the bulk of the heavy lifting. When an engine is already mature then the programming team can be almost exclusively gameplay programming, with no engine or tool programming required.
Breaking into the industry:
1) Last project I worked on was an arcade shooter game which was a project I worked on in my spare time for 6 months. The project I am working now on is a small scale Zelda game. I still have yet to make Tetris and a 2d side scroller platformer. My question: How does the game company know how much knowledge the applicant has before hiring them be it for an intern position or a full-time position? The reason I ask is because I am trying to see where I am at skill-wise before I start applying for internships or jobs so I do not waste anyone's time.
Have you read the Breaking In forum FAQs yet? There is one that covers 'wannabe tricks'. One is over-preparedness. I suggest reading all the FAQ entries, you may find them enlightening.