[casual_games] How many hours does a programmer need...
Kenton White
k.white at i2learning.com
Mon Mar 27 12:55:53 EST 2006
Joe's crash course is wonderful!
To that I will add a couple of practical strategies that worked well for me
and my team.
1) You do have a design document? If not, get that written! Without
a design document no one knows what the project that is going to be built is
and it is impossible to determine how long that will take. The expression,
I think, is "how long is a piece of string?"
2) Distill the design document into a requirements document. The
requirements document clearly and unambiguously articulates the product's
purpose, features, functionality and behavior. This reduces the design
document into the practical what to make without defining how to make it. I
mention this step because many "how to make games" books don't mention a
requirements document, probably because they are targeted at programmer /
designer hybrids.
3) Break the project down into bit sized chunks, otherwise known as a
project plan. I try to break it down into chunks that I think are about a
week long task. From my recent project, sample bite sized chunks were:
script syntax & data structure design; script parser; text only prototype;
art engine prototype, etc. Of course for your project these will be
different (mine was a conversation based game and so a text only prototype
was feasible).
4) Then, with your candidate programmer, sit down and ask how long
each of these tasks will take. The nice thing about this conversation is
you can find out much about how suited the candidate is to the project. As
another rule of thumb, push back on what the programmer says and add about
50% extra time to what they say. So if the programmer says "It will only
take me about a week to get the syntax and data structures designed" then
you say "Great, let's agree that it will take a week and a half." Not only
does this give a more realistic strategy, but when the task starts running
over schedule, you can half jokingly remind your programmer that she thought
it would only take a week - a nice way to light the fire under someone to
get it done!
5) If you are using multiple programmers try to parallelize the work
flow. That is, try to have each programmer responsible for a single section
of the game, like art and animation, artificial intelligence, character
controls, etc. Go through the same process with each.
This bottoms up approach I find yields more realistic schedules than the top
down approach of "it takes 100 man hours to make a game so if one programmer
can give me 10 hours a week it should take 10 weeks."
And good luck with your project!
Kenton
_____
From: casual_games-bounces at igda.org [mailto:casual_games-bounces at igda.org]
On Behalf Of Ryan Sumo
Sent: Monday, March 27, 2006 11:31 AM
To: IGDA Casual Games SIG Mailing List
Subject: Re: [casual_games] How many hours does a programmer need...
Thanks for the solid advice everyone, I'm sure it'll come in handy. At this
point I'm trying to keep the team size as low as possible in order to keep
costs down, and also because I did notice that the more programmers you have
working on a project, the harder it is to keep things in synch. I'll
probably go for 3 at most, and then only of necessary. Thanks again!
Joe Pantuso <jpantuso at traygames.com> wrote:
Crash course in programmer wrangling;
- Accuracy of time estimates is proportional to developer experience. Even
(especially?) highly skilled programmers with only a few years of
development work under their belts will see every problem as simpler than it
really is and wildly underestimate the time required.
- Productive time at programming (time spent adding useful code) comes in
bursts while in a state sometimes referred to as 'flow'. From the point of
a cold start or starting again after being interrupted for a conversation or
something of only a couple minutes, time to flow is 15-45 minutes depending
upon the complexity of the problem. This means that length of blocks of
time available and environmental distractions or lack there of can have a
dramatic effect on actual productivity without actually affecting the hours
spent.
- As the number of programmers on a project goes up the amount of time spent
keeping in synch climbs logarithmically. This introduces a hard limit on
the number of programmers that can work effectively as a unit of 6-10. I
will assume though that you won't be able to muster more than about 3, at
that count they shouldn't be getting in each others way enough that they'd
be less efficient than 2, but even at that low number it will depend on how
well (frequency and quality) they can communicate and how experienced they
are working in a team.
- Many lesser programmers are very proprietary about their code, and when
other developers make changes or additions to it they get territorial. This
is a clear sign of a 'B' or 'C' class player but you won't know about it til
possibly too late.
- Your best path to efficiency and knowing how much trouble you are in as
early as possible is to use the Sprint/Scrum method of scheduling and
working. I highly recommend you google on those expressions and read up on
it. In a nutshell the programmers agree on a set of functional code that
can be produced in 1 calendar month, they talk very briefly each day about
their progress the last 24 hours, what they expect to accomplish the next 24
hours, and any obstacles that are in their way. They also estimate how much
of their month goal they have completed and have remaining. It becomes
obvious quickly if people are estimating poorly, and cutting the project
into 1-month chunks allows you to change direction rapidly if conditions
warrant. This is a baseline 'agile' coding methodology everyone should be
aware of.
- The level of ability of programmers varies dramatically. This phenomenon
is sometimes described at the high end as 10x programmers, i.e. the most
effective programmers are 10 times as effective as everyone else.
Unfortunately this is not only generally true, but the 10x programmers are
at least 10x as rare as everyone else.
For your particular project the prior experience of these programmers will
have a dramatic effect on their ability to be productive on this project.
You don't say what these guys do for their day jobs. If they have no game
programming experience, you are in for a rough learning curve.
Good luck.
-J
On 3/27/06, Ryan Sumo <endlessthirteen at yahoo.com> wrote:
How many hours does a programmer need per week to finish a game with a
dev time of 6-8 months?
I've been talking to some programmers about a game I want to make and
been asking them the hours they could spare if they did it on the side.
I've been getting answers ranging from 4-5 up to 7-10 hours a week.
I was just curious how past developers who worked with people who did
it on the side fared. Can I compensate by having more than one
programmer? Because as far as I can te ll from working with them the more
programmers on a piece of code, the more muddled up it gets.
Just to give you guys an idea, the game would be about as complex as
diner dash, or a little more than that.
_____
New Yahoo! Messenger with Voice. Call regular phones from your PC
<http://us.rd.yahoo.com/mail_us/taglines/postman5/*http:/us.rd.yahoo.com/evt
=39666/*http:/beta.messenger.yahoo.com+> and save big.
_______________________________________________
Casual_Games mailing list
Casual_Games at igda.org <mailto:Casual_Games at igda.org>
http://seven.pairlist.net/mailman/listinfo/casual_games
_______________________________________________
Casual_Games mailing list
Casual_Games at igda.org
http://seven.pairlist.net/mailman/listinfo/casual_games
_____
New Yahoo!
<http://us.rd.yahoo.com/mail_us/taglines/postman4/*http:/us.rd.yahoo.com/evt
=39666/*http:/beta.messenger.yahoo.com%20> Messenger with Voice. Call
regular phones from your PC for low, low rates.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://seven.pairlist.net/pipermail/casual_games/attachments/20060327/a0c669f3/attachment.htm
More information about the Casual_Games
mailing list