Others covered that there is no magic approach used in planning, but I want to urge you to fail. You're holding yourself back trying to avoid failure, but failure is part of success. My previous job was obtained by failing at the interview, but impressing just one manager so much that he created a position for me. And it was a way better job as a result. It didn't really have a job description, so I just got to do insane and amazing stuff without worrying if it was in my job description. I got to work with the driver guys, the UI guys, QA, the build team, the team in India, and everyone in between. Most projects I've worked on failed to achieve the original goals, but still succeeded in achieving amazing results. Every bug I ever closed involved failing on every single solution attempted except the final one.

So start working with teams even if you don't think you're ready. Apply for every job you think would be a blast whether or not you meet the qualifications. And tell people straight up that you don't have the experience yet, that you're going to make mistakes, that you're going to learn a lot as you go, but that you're going to work your ass off to make up for it, and you're going to love the work and the challenge.

I would not say I never failed. Every feature I wanted to get right in my rpg game was a failure because it never works the first time. It was only after many hours of thinking was I able to improve the code design and got the feature to work.

Great tip! Thanks!

Nothing beats your own experiences in determining how much forethought and planning you need before you start the actual programming process. With that said, I would start with the basic premise of the application: List the features that you would like to have, categorizing them into “needs” and “wants”. Weed out the “wants” until you get something manageable—keeping in mind that some of the “wants” you weeded out can be placed back into the final product. At this point you should make a structure that everyone in the team can understand—this is the key. Now you are ready to code. How much detail involved in the planning phase is up to the team. Don’t let any convention block you from starting you coding.

I see. Thank you!

Despite the planning, are there situations that results in too many "parameter passing" from one class to the class the programmer wants to be in?

As a self taught game programmer who has been writing the codebase for one month and 2 weeks for a role playing game, I also want to know the thought process of how game programmer think or approach a codebase they are about to write.

Do they write psuedo code just to spot as much future problems in implementing a feature that would make their life easier?

Do they talk to every programmer on the team about how to build their side of the codebase or is this abstracted away from the other programmers?

What exactly would they talk about before writing a single line of code?

How do they put the codebase together before writing a single line of code if they never written the code before?

What is the process like? Is it necessarily

1) communicate some. write pseudo code on whiteboard to spot bad code design.

2) everyone build their side of the codebase

3) merge the codebase together

Repeat the above steps

Since I never worked on a team before, understanding how a team of programmer works in terms planning and approaching the codebase design of a game would be super useful to me. It would probably make me a better programmer so my code can actually work well with the other programmer codebase.

On a side note: When does one start joining a team? How many games does one need to write before joining a team to gain team experience? I heard joining a team can be pretty complicated.

I made 5 games so far in a year time(the role playing game being the most complicated thing I have ever done The DialogueSystem being the most complicated I ever build for a game and took many days before it worked the way I wanted it to work despite some improvement that can be made on the code design ).

I feel I have much to learn before joining a team. I fear I need team experience before I can join the game industry as a game programmer intern.

Any feedback about the above would be appreciated.

To answer your question, it is best that you become familiar with the SDLC (Software Design Life Cycle) and the AGILE-Scrum process of this cycle, including what stories, sprints and backlogs are.

There is something called the Technical Design Specification. It is a book, created by the designers and in part, the developers of the SDLC. It encompasses just about every diagram you can think of: Use Case UML, High Level Class Diagram UML, Database Design, ERD, Dataflow Diagram - Flow Charts.

Before a single code is worked on, the Technical Design Specification should be completed. The reason is because of the first page of this book, being the contents regarding its Purpose and Description of the Requirements. In a nut shell, if either the Purpose or the Requirements are breached or not met, then you either have one really passive and generous client or... you can't adequately define your sprints, which results in project failures (and people start losing their jobs and companies start losing a lot of money). All the pages there after the first page, break down what the program should do. And that breakdown, allows a sprint log to be created, which allows management for the overall project.

As a one man programmer, yes, you can get away with not using this. As a two or three man programmer, you might be able to get away with not using this. But as the numbers increase, so does the unlikeliness of succession from not using the Technical Design Specification.

Hope this helps.