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.

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.

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 it

while 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? :)