   How much planning do game programmer before writing a single line of code and how do they plan it out
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 codebase3) 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. 
Have you read a bit of systems engineering? System analysis? Requirement engineering? UML? Software lifecycles? There are a lot of moving parts on project planning. And for software development, there have been a lot of things made to start planning and experimenting without writing a single line of code. For example, this "parameter passing" is something you would define in an UML class diagram (having beforehand established each class responsibility and collaborators), you'd define what fields such class would have and what methods it would need to fullfil its responsibility. But what if you don't clearly foresee all the methods you might need? Well, there are sequence diagrams that can demonstrate all the "messages" the different objects would need to know to make a certain interaction with the system work. All of this is often interweaves with other methodologies (not so much about planning but development, like the trendy "agile" methodologies). Most often not all of the programmers are involved in this process, programmer do the coding, the grunt work, software design is a different thing altogether, in these design processes is where software architects are involved, not all programmers. In short, "planning" is a very broad subject, you can do lots of it before starting to code, and there are been lots of people studying exactly what you're asking, how to do software planning.;  This is one of those questions that should never be asked.The main reason being, “If you have to ask, you will never know.”The second reason being that there is not a lot anyone else can do to help you here. It is extremely subjective.A coworker recently expressed exasperation on a similar subject and after asking for some help he found out that I get a whole mental image of how all the interconnected parts work before I code anything. As he began to praise me for being able to hold that all in my head without drawings etc., I told him to sit down and shut up. I translate things into a format that works for me, and it won’t work for anyone else. And the downside to the format that works for me is that I can’t understand UML diagrams at all. There are a lot of things that others grasp easily that I simply don’t.A very simple example:In a UML diagram, arrows point the wrong way.A base class points up to the class that inherits from it.Whose idea was this? How does this make sense in any universe? “I inherit from you, thus I take properties from you, thus the arrow should point from me down to you.” This makes so much sense to me I can’t see it any other way, but whatever idiot who designed UML decided, “You inherit from me, thus I give you properties, thus the arrow points from me to you.”The only way to answer your question is to not answer it.While my world view may not be compatible with UML, I have figured out how to get by; so has everyone else whose views are different from mine.Even if we did answer, what are you going to do? “Okay I’ve thought about it for 10 minutes now. Oh shit I was only supposed to think for 9 minutes.”Get real.L. Spiro   ;  I think L Spiro got to the heart of the matter.  >> are there situations that results in too many "parameter passing" from one class to the class the programmer wants to be in?Sure. A quick refactor fixes that. Don't think about it. >> I also want to know the thought process of how game programmer think or approach a codebase they are about to write.Read the designs, talk to the designer. Use your own brain and make up your own plan, iterate with the designer, and do whatever you want. It doesn't matter what other people do.>> Do they write psuedo code just to spot as much future problems in implementing a feature that would make their life easier?Some people do. If it works for you then do it. If not, do whatever helps you. >> 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?Approximately never. There might be team meetings about broad design concerns, but they are rare and typically only during the first phases of development. After that there are discussions between individuals working on common code, or between the leads and the implementers.>> What exactly would they talk about before writing a single line of code?Whatever they think is useful.>> How do they put the codebase together before writing a single line of code if they never written the code before? That's why you have experienced people on teams, and why they ramp up from a small group of highly experienced experts to larger groups of general programmers. >> What is the process like? Is it necessarily ...Not usually. Designers make designs. Producers and team leads discuss the design, iterate over them, discuss the costs of the ideas, and eventually resolve on a design that mostly works okay. Then designers take the designs to the people who will implement them repeat the process, and make adjustments. Then the implementers just do whatever works to implement the design they agreed on. >> 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.The day you are hired in the workforce you are part of a team. Somebody is assigned to help mentor you, get you set up, and hold your hand until you get comfortable. The more experience you have the less hand-holding is expected. Entry level workers may get 3-6 months, senior-level workers get 3-5 weeks before hand-holding ends. >> 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 ).Good. Put it down on your resume under "personal projects", if you weren't paid for it then it doesn't count as work experience. >> 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. You have a stronger background than many others who have joined the industry. Your fear is listed in Tom Sloper's site in the list of stupid wannabe mistakes: stupid overpreparedness.   ;  At my work we always try to structure things out before we begin coding...of course you can not catch everything! We also are mostly working with php and mysql when working together and planning. It looks like you have some of theright ideas and im wonderimg if you are gettimgto the point where you should be working with a small team on a small project to continue your learning. I also am not sure if you are familiar with using git but it might be worth your time taking a look at learning it for a version control system while working in a team. I say this cause eventually you will run into version control and will need a way to merge with your other team members code.I guess I didnt answer anything reslly specific but I hope you find my post useful.   ;This is one of those questions that should never be asked.If a leader never ask for input, Then they never have any opinion or idea other than their own!  I think all of his questions are relative, Maybe not to me but definitely to the asker. Thus, no answer given should be taken as final, just food for thought.  When working on any project, after the project is defined, I like to make notes on a large index card for different parts.  As with most games, you will find a core set of functions and data parameters.  What comes to mind in a roleplaying to me first are the PCs & NPCs.  Figuring out what they can and cannot do will help define some of your programming requirements ( 1 small step ). By putting these definitions onto 1 or 2 index cards you begin to develop some flow.  < At least this works for me!  You will have to find what works best for your team, this may be a "Trial & Error" type system.  Older programming teams used to develop a "Top Down" program Flow Chart.  I find now, for me, a core design with many outflows and returns type "Road Map" presents a better representation of a program, Like the Circle of traffic flow around the "Arch de Triumph" roadway in Paris.In a UML diagram, arrows point the wrong way.A base class points up to the class that inherits from it.Whose idea was this? How does this make sense in any universe? “I inherit from you, thus I take properties from you, thus the arrow should point from me down to you.” Maybe I am reading this wrong, but is this not the same thing, with the flow pattern inverted.  If I inherit from you, should not the arrow point from you to me ?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 codebaseEveryone will have strengths and weaknesses and their own ideas.  When working with a team, and leading a team, I think it would function much better as a team if everyone feels they were able to contribute to the team.  Get input and ideas from everyone.  Discuss everything.  Keep an open mind!!  Come to a consensus, Not everyone will get want they want, but if they feel that they were at least listen to, they will more likely give a better effort.  Remember, the team leader has they final say on what direction to go.  The Team leader should also be ready to take "Full Responsibility" for anything that goes wrong, and "Share Credit" for when it goes right.;In general, I believe confidence is the quality that you're trying to identify (not to be confused with arrogance). Confidence that what you're about to write will do what you want it to and that it will be as extensible as you need it to be. Also instilling that confidence, most likely by communications in writing (design docs, diagrams, whatever), in your co-workers and clients. It may be that confidence comes from discussing things with co-workers or clients or it might come from research, experimentation, or past experience. That is not to say that confidence will necessarily generate a result that follows best practices. Of course this is also a desirable quality but I don't think it could come without the experience of writing code.;Doing something for the first time is always the hardest.Hence no amount of planning can trully prepare the developer for a solution to the problem.  Planing/Design is a very subjective thing.Sometimes just writing prototype code to see if a design works, can lead to understanding the problem better. Rather than having talks with people of what could be and what not. Sometimes there will be a lead designer/programmer who will decide how things will work.....Some people are very visual, some are less.. so some tools for planning will not be equally effective to get the point accross the whole team. Its really dependents on the team of individuals and how their work well together.  Once one member wrote a design in psuedo code and I just expanded itwhile he was expaining to me what he wanted the code to do. Sometimes a whole task is given to an individual with pre-defined list of tasks the code needs to do. eg write the whole MySQL code to get the data from a database. I guess what I am trying to say is, as soon as possible try to get some experiance working with other people and you will understand .;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 never write proper UML. I do though often write boxes with arrow between them to map out classes and dependencies. It borrows from UML, but I basically just use 3 kinds of arrows. inheritance, component (class directly owned by another class) and general more loose "depenceny" (dashed arrow).  For all of them though I read them as "A depends on B", and then all the arrows go the right direction in my mind... I find it easier and more persistant to have it on file, and it helps to spot when where and how to refactor. It's very much a living document in the beginning of a project, until the general infrastructure of it all solidifies. Every bug I ever closed involved failing on every single solution attempted except the final one. How could it be any other way? :)