Quote:Original post by crazycode
If you just want to program to understand that part.. Just get python or an easy language... But game programming is a lot more complex

Quote:Original post by Atrix256
I hear you on your plight :P

Im leading a project and as a programmer I understand programming, scripting, production and design pretty well, but my lack of art knowledge really makes things difficult.

For instance, not knowing how long art tasks should take makes it hard to plan schedules or know when people are working hard or when they are slacking off :P

What i've tried to do is find an artist to be the lead artist and talk to her to get that kind of information.

You might try something similar by finding someone to be a lead programmer who you can trust and talk to to get you the information needed to keep the project movin forward.

Basically if you try to learn some programming to understand it better, all you are going to learn in even a few months time would be "wow this stuff is hard..."

:P

Quote:Original post by dclyde
To be honest, even most programmers cannot schedule themselves well.

Oddly, knowledge of actual programming is only a small slice of the pie when it comes to the scheduling as there are several major factors.

Complexity of the problem - This can vary from technical challenges to the current infrastructure of your engine.
Related experience of the programmer - Have they worked on related systems before, or can they work on things they have no knowledge of well.
Motivation of the programmer - Different people are motivated by different things. If you have one graphics programmer and he is visually motivated he will do complex lighting systems much quicker than he will redo the underlying mess engine code to be more efficient.
Existing infrastructure - Does anything exist already in the engine to help this task out?

In general a good lead will pick up on the strengths or weaknesses of his team and even then will probably still only use that for matching the right task to the right person and will then ask them to estimate the time. If he knows them well enough he knows what multiplier to apply to their estimates.

When I estimate my tasks I have multiple numbers in mind. Potential minimum time necessary to write the system. Potential maximum time it will take assuming I run into technical challenges. Actual number of days it will take given the number of interruptions I tend to have per day and other responsibilities. Each place does things differently. For instance in my current job I am asked to round all tasks up to whole days and account for distractions myself. At my last job I gave the actual range of programming hours it would take and they knew that I only got the chance to do actual programming during 50% of my day so they knew I would only get through 20-25 hours of programming a week.

Overall I have never met anyone who accurate estimates their programming tasks. There are almost always too many unknowns. Most programmers I have met know how optimistic their estimates tend to be and have their own internal multiplier they use when estimating tasks.

The part that helps the most from an outsider point of view for scheduling is being able to break down the task. But to be honest almost no one person at any company can break down every task for every discipline. Especially like I said when there is existing infrastructure reasons that something may need to take longer. (vague ex: We currently skin on the GPU, if we want way more complex shaders for a ps1.1 target we would need to move skinning to the CPU) which someone not ultimately familiar with the system would have no idea about. Working with the people being scheduled or their lead is usually the most efficient way to do it. Being curious during these scheduling meetings will introduce you to the topics that you would probably care to research.