gbadev.org forum archive

The right five person team should be able to complete a demo in three months. Clearly there are a lot of factors, but how good would that team have to be to complete the entire game in three months? (Assume a platformer if you need a genre to answer.)

Also, how much does a BGM typically cost?

-Brendan

A complete beginner could complete a game in 3 months. It depends on the complexity of the game - a very basic platformer with 5 short levels could easily be done in 3 months, but how complex do you want the game to be?

I agree with Ultima, it depends on the game obviously. Also, it depends on the persons' freetime and how much of those 3 months actually go into programming / gamedesign.

I meant to say "commercial level", but didn't. Commercial level beta at least.

As far as time goes, 5 people * 3 months * 4.2 weeks / month * 5 days / week * 8 hours /day = 2520 people hours (at the very least).

Of note is that 5 people includes programmers, artists and anyone else who might happen to be on the team. 1000 ~ 1500 programmer hours. I could see 3p/2a, 2p/3a or 2p/2a/1o splits.

-Brendan

You would need really top-of-the-line tools and a kickass and complete engine core to even consider it. Seriously, a single day that the programmers aren't working on only game-specific modules or the artists/scripters don't already have everything they need to do their job well (and are experienced enough with the tools to work efficiently with them), and it's all over.

That said, I don't think they could get more than a couple level's worth done in that time, even if the team is twice the size. There are too many pipeline issues between design, art, scripting and programming. All the manhours in the world won't equate to the time you need.

Dan.

Dan's right -- forget about man-hours. Even if you have a mature engine and toolset, and a team of developers who have shipped products using those tools, you're looking at a game with a very narrow scope -- perhaps a puzzle game, or a demo for a sidescroller, or otherwise something of less-than-commercial quality.

After I posted this, I sat down and did some calculations. I basically came to the same conclusion but did want a second opinion.

Thanks!
-Brendan

Don't forget the wasted time with communication if they aren't all sitting in the same room.
_________________
NDS Homebrew Roms & Reviews

Lynx wrote:

Don't forget the wasted time with communication if they aren't all sitting in the same room.

That can be handled with appropriate communication and management protocols that are suited for this type of work. In one of my jobs we do not all work at the office every day but are contracted to do a certain amount of hours over the year. We have regular meetings centered around the Team Action Management System, where an action is raised, dated, and resolved by the next meeting. It seems like common sense, but having regular reports and meetings on tasks completed and concerns being raised to be considered (like predicting a problem in the design) can raise the action of assessing the design by a given date.

It all falls down (in my opinion) to management and having reliable people who will tell as soon as they know they cannot complete something or are having difficulty. There is probably a successful lifecycle and management system built for this. Maybe if you treat your programmers as contracted workers who are simply given tasks with estimated times[like bounty programmers]; where they notify the group when they begin work, give an ETA then it might work. If one coder finishes his tasks and notes that another has not started and he knows he could get started on it and finish it by the deadline, then he can take it upon him/herself to complete it. Maybe a protocol to handle this where there is a period that someone can take over your tasks if not completed in time, or something of that nature.

If all of the workers are local in the same city then you can have regular weekly meetings to keep them in order and in the same mindset.

A high quality complete game isn't really possible in three months. How crazy would your team of five have to be to pull off a high quality demo in three months?

keldon wrote:

Lynx wrote:

Don't forget the wasted time with communication if they aren't all sitting in the same room.

If all of the workers are local in the same city then you can have regular weekly meetings to keep them in order and in the same mindset.

I've done both net and office projects. Net projects are horrible. "When will Fearless Leader be online? Oh, so this has to be finalized with Fearless Programmer instead? He lives on the other side of the planet and probably won't be on for another six hours." Flying everyone to the same place is a must if you want to work efficiently.

keldon wrote:

It seems like common sense, but having regular reports and meetings on tasks completed and concerns being raised to be considered (like predicting a problem in the design) can raise the action of assessing the design by a given date.

Feedback is good. I think that is an understatement. =)

keldon wrote:

It all falls down (in my opinion) to management and having reliable people who will tell as soon as they know they cannot complete something or are having difficulty.

Which should be something every responsible person does. Unfortunately some companies pressure people into making impossible (or just difficult) commitments and then come down on them when they can't deliver. This is, of course, silly; but life *is* silly sometimes.

keldon wrote:

There is probably a successful lifecycle and management system built for this.

I'd love to hear it or help figure it out.

keldon wrote:

Maybe if you treat your programmers as contracted workers who are simply given tasks with estimated times[like bounty programmers];

My current plan is that everyone is going to be treated as an independent contractor. Once the contract ends, the programmer is paid and further commitments cease to exist (NDAs aside). If you complete a module and it passes inspection, you get paid. Then, you can go to Bermuda instead of accepting another contract if you really feel like it.

Getting paid assumes that you complete something usable. Causing other people to be unproductive is not useful. Not communicating that risk is destructively irresponsible.

In theory if people leave all the time this system would really suck. In practice I don't think making it easy for people to leave (and return for that matter) would cause more people to leave. (Assuming some people will leave is probably a good thing.) When people quit, they quit for other reasons. ("Mr. Manager makes me peel his oranges. I can't take it anymore." =)

keldon wrote:

where they notify the group when they begin work, give an ETA then it might work.

Regular meetings and a prioritized assignment system sound cool.

keldon wrote:

If one coder finishes his tasks and notes that another has not started and he knows he could get started on it and finish it by the deadline, then he can take it upon him/herself to complete it.

It might be kind of cool to put a tentative price on every module. Whoever completes the module collects that module's bounty. The price is finalized in a meeting to make sure that nobody feels burned. (If the module was unexpectedly easy, other people might get fussy. If it was unexpectedly hard, you might get fussy. =)

keldon wrote:

Maybe a protocol to handle this where there is a period that someone can take over your tasks if not completed in time, or something of that nature.

Split the module bounty? =)

If I were to do a module bounty system, I'd probably set it up like this:

-Brendan

The bounty notion seems fundamentally flawed to me. I'm sure you realize that game programming isn't just making modules, it's working with the modules you and others have made to create a complete game. A bounty style will only encourage people to do the fastest job they can that works, and it's going to bite you heavily in the ass when you actually need to use those modules for stuff.

The competetive slant to it would only encourage people to wastefully repeat effort by doing each other's work, and trying to get it done before the other guy does. Recipe for disaster.

The majority of code-side problems that have ever manifested in my studio were the result of people coding "under the gun", and always thinking they just have to get it working in time for a milestone, and worry about quality later on. And it becomes a self-fulfilling prophecy, because you wind up not ever having time during alpha/beta/final because you're always crunching to fix code that was incorrectly written. One of the first things I told my devs after I became a lead programmer was that they should never take this approach, and that there is always time to do things the right way the first time through.

For all of my successes and failures as a lead, I'm pretty certain it's one of the smarter things I've done, and I think if you foster that under-the-gun mentality then you'll wind up getting exactly what you've paid for.

Dan.

OSS works without people being localized. I'm not sure how their projects are managed but there are plenty of successful projects.

Can't you just phone the nearest good university that has computer science courses and ask for their 5/10 best graduates from the summer? Email them, and then you will have a local team.

But I'm sure there must be a way to make a team work without being localised.

keldon wrote:

But I'm sure there must be a way to make a team work without being localised.

I'd worked with distributed teams that succeeded and ones that failed.

It comes more down to a few key things, which I think are more important than whether or not your team is localized.

1. Is your team competant? It's a problem if not. Even more a problem if they are non-local, and you can't be there to realize they are incompentant.

2. Is this project a priority for everyone? This might make the biggest difference to distributed teams.

3. Is there a standard method and time of communication? We said the majority of the team needed to be on instant messenger from 9 to 5. The people on a different continent from us had a certain time that we arranged to touch base daily.

4. Can work be divided relatively cleanly? Sure, there's overlap and touching modules in any project. But if you can't do anything without stepping on each others' toes, forget it.

keldon, most open source projects are not on a strict schedule.

It all comes down to management. If you have someone capable of managin the team, meaning they know if a team member is just blowing smoke, or if the deadline is really not obtainable then it may work.. Problem is, you might be required to micro manage the team. This can be a major job, which means you have one more person to pay for that isn't really doing anything but making sure everyone is doing their job. If you go with localized, you get more interaction and are more likely to have team members working things out as apposed to pointing fingers when the project is coming due and it's not done yet.
_________________
NDS Homebrew Roms & Reviews

poslundc wrote:

I'm sure you realize that game programming isn't just making modules, it's working with the modules you and others have made to create a complete game.

You are right. "Modules" should be replaced with "tasks". A task based bounty system could be implemented in just about any field.

poslundc wrote:

A bounty style will only encourage people to do the fastest job they can that works, and it's going to bite you heavily in the ass when you actually need to use those modules for stuff.

If you accept tasks as complete without reviewing them because they appear to be complete, I agree. If you are clear about what a task needs to do for the project now and later, and then make a reasonable effort to verify that those requirements are met before it is marked as complete, I'm not conviced that this is true.

There is an optimum speed/quality/effort level that will vary with your goals. The sooner something will be thrown away, the less polished it needs to be. Generally speaking, if you can ship a product that isn't defective, you've done a good enough job.

I'm operating under the assumption that a fair amount of resources are going to be put into code review and inspection. It's cheaper to have programmers fix their own bugs than it is to have debug staff find them for you.

If Author Al writes some code, who is responsible for that code? At some point, responiblity for that code should probably pass from Author Al to the entire programming team. Assuming a bounty system, the bounty payment seems like a good time to shift responiblity for that code.

Assuming the task has been completed to standard, the appropriate acceptance test strikes me as something along the lines of: "If Author Al was hit by a car and I had to maintain this, would I be comfortable doing so?" If everyone in a position to maintain the module can answer yes to that question, the task has probably been completed well.

I'm convinced that if a studio were to fire enough debug staff to hire an extra guy to do code QA, the net result would be positive.

poslundc wrote:

The competetive slant to it would only encourage people to wastefully repeat effort by doing each other's work, and trying to get it done before the other guy does. Recipe for disaster.

If communication and a check in system are lacking, I agree.

If people are willing to compete for something and there are resources to properly review every attempt, it doesn't matter if everybody redoes the same work. Applying for jobs follows this system. Every supplies the same application materials, everyone is reviewed and three people get hired. These people are working against eachother- they are not part of a team.

A team assumes that people work with eachother to get something done. If I need a lemonade stand, the boards need to painted, nailed together, and moved to the side of the road. These tasks can be completed by one person or many. In certain cases, it may make sense for people to work together to complete one task, but ending up with two stands when all is said and done would be silly. I think that software development is the same, albeit more complex on many levels.

The goal of the bounty system isn't to inspire competition, but to motivate people to get things done. If the system fails to do this, it is essentially worthless.

poslundc wrote:

The majority of code-side problems that have ever manifested in my studio were the result of people coding "under the gun", and always thinking they just have to get it working in time for a milestone, and worry about quality later on.

Clearly a check is needed to make sure that things get completed properly. Conventional systems probably want similar checks. There are times when people need to be reminded that "this works, but it isn't finished". If the project is going to ship, maybe the job can be fixed on the next project. If an unfinished job is going spawn bugs, the job needs to be finished.

How much effort does your studio put into code QA?

poslundc wrote:

... and I think if you foster that under-the-gun mentality then you'll wind up getting exactly what you've paid for.

The way I see it, the goals of a development strategy are:
A) Motivate people to get things done.
B) Survive the loss of individual members.
C) Stay on budget. (Where budget can be converted into time.)

If a development strategy fails on any count, I don't thing it's a very good strategy. Bounties try to cater to A and C. Reviews and passing control from the author to the team try to cater to B.

I'm really not sure if a bounty system would be better than a normal salary system. (Hourly payment isn't appropriate unless you really do need a body for a set number of hours.) I can also think of base salary + bounty and/or delaying bounty until the product ships.

With a delayed bounty system, you'd adjust bounties based on imcomlete tasks that cause extra work for other people. That would function as both a quality and budget check, although it might affect motivation. As any system goes, appropriateness depends on the participants.

keldon wrote:

Can't you just phone the nearest good university that has computer science courses and ask for their 5/10 best graduates from the summer? Email them, and then you will have a local team.

That assumes that all of them are available and interested. It also assumes that the schools will work with you. Admittedly, if you call enough schools, this might work. I'm not convinced you'd get all the best graduates.

keldon wrote:

But I'm sure there must be a way to make a team work without being localised.

NDAs may require people to work on site. Assuming that an NDA is more enforceable if people work on site is naive. For that matter, so is assuming that people are working because they are at work. The advantages of working on site mostly have to do with communication- everyone is available from 9 to 5; eye contact; tone of voice; calling an emergency meeting and using the white board.

There are advantages to distributed teams:
A) You don't have to rent a large building.
B) You don't have to buy equipment people already own. (computers/software)
C) People don't need to commute. (may not matter)
D) People don't need to leave when security walks in at 1:00 AM. =)

It's not that distributed teams can't work, but in my experience they don't work as well.

gauauu wrote:

1. Is your team competant?

This could kill any team, although incompetent people certainly do work on commercial projects that manage to ship.

gauauu wrote:

Even more a problem if they are non-local, and you can't be there to realize they are incompentant.

One could certainly argue that visibility is only an illusion in centralized projects. I do think it is easier to gain visibility if everyone is in the same building. In practice, I think most distributed projects suffer from less visibility.

On the otherhand, certain distributed projects probably have excellent visibility simply because they try.

gauauu wrote:

Is this project a priority for everyone? This might make the biggest difference to distributed teams.

In practice, I think that this has a real negative effect on ditributed projects. Even if everyone has lost interest in a centralized project, people are probably going to continue going through the motions instead of disappearing or whatnot.

Lynx wrote:

It all comes down to management. If you have someone capable of managin the team, meaning they know if a team member is just blowing smoke, or if the deadline is really not obtainable then it may work..

This is one of the things project directors are supposed to be doing.

Lynx wrote:

Problem is, you might be required to micro manage the team. This can be a major job, which means you have one more person to pay for that isn't really doing anything but making sure everyone is doing their job.

The director is supposed to direct a project. This involves making sure that the team is working efficiently. It also involves keeping the publisher happy. (These require different skill sets.) I think having a director is a good idea for most projects. If your team is small, this person may wear multiple hats.

Lynx wrote:

If you go with localized, you get more interaction and are more likely to have team members working things out as apposed to pointing fingers when the project is coming due and it's not done yet.

I bellieve that teams who can eat lunch together tend to gel faster.

-Brendan

sgeos wrote:

Assuming the task has been completed to standard, the appropriate acceptance test strikes me as something along the lines of: "If Author Al was hit by a car and I had to maintain this, would I be comfortable doing so?" If everyone in a position to maintain the module can answer yes to that question, the task has probably been completed well.

Mozilla code review practices involve two reviews for each patch checked into CVS: one code review (r=) by the owner of a component, who has deep knowledge of that part of the code, and one integration review (sr=) by anyone else. Crunch time checkins require a third risk/benefit review (a=).

Quote:

I bellieve that teams who can eat lunch together tend to gel faster.

Faster enough to justify airfare for people who happen to have been born in the wrong place?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

Faster enough to justify airfare for people who happen to have been born in the wrong place?

I don't understand this question. He's talking about putting together a good team, not talking about providing a team for everyone despite where they were born.

I think the response to that comment is to build a local team. Of course you are not going to spend money for someone to travel around the world to meet other people on a 3 month project. If you did have that kind of money to waste, throw it toward hiring better local developers. I could be way off base, but I believe you can find pretty decent software developers in all parts of the world. There is no reason you need to hire someone from another part of the world to work on a project unless you "NEED" their name in the credits for whatever reason.
_________________
NDS Homebrew Roms & Reviews

Programmers routinely relocate for job opportunities.

Not a 3 month long project.
_________________
NDS Homebrew Roms & Reviews

tepples wrote:

Quote:

I bellieve that teams who can eat lunch together tend to gel faster.

Faster enough to justify airfare for people who happen to have been born in the wrong place?

It depends on how much you pay people and how much it costs to relocate them. People often move, at their own expense, to take jobs in different cities, but they move to take jobs that are important to them. Nobody moves to become a cashier.

Companies also move people. Again, important people, not cashiers- it depends on how valuable (and rare) your skills are. If you need to be relocated, and all the locals are unquilified, you'll probably be relocated. If a company transfers someone to a different city, they'll usually pay for relocation.

Would a company pay to relocate a game programmer? Sure, if they need to. For three months? Probably not. You'd have to be a very expensive game programmer.

Lynx wrote:

There is no reason you need to hire someone from another part of the world to work on a project unless you "NEED" their name in the credits for whatever reason.

There might not be any qualified people in your area. Qualified people from another country might be cheaper even after paying for relocation.

Lynx wrote:

I could be way off base, but I believe you can find pretty decent software developers in all parts of the world.

Sure, if you are happy with "pretty decent". I think we'll all be in trouble when companies realize that they should really be hiring Indian programmers instead of locals. =) I'm not really joking. India has some of the best training in the world. They have practical training. Indians also have excellent work ethic. (They also speak English.)

-Brendan

sgeos wrote:

Sure, if you are happy with "pretty decent". I think we'll all be in trouble when companies realize that they should really be hiring Indian programmers instead of locals. =) I'm not really joking. India has some of the best training in the world. They have practical training. Indians also have excellent work ethic. (They also speak English.)

Are you serious? Where did you get this information from? How much experiance do you have with them, and what I think I really mean is, "How many indian friends do you have?".. As I have a lot.. and will not agree with any part of that statement. Well.. Maybe the English part.. but it depends on what you define english as.. And please don't get me wrong.. I like my friends.. I just know them well enough to know that information above is not true, just a perception that has been made.

My favorite.. Spell minimum..

yim-I-yin-I-yim-U-yim
_________________
NDS Homebrew Roms & Reviews

Lynx wrote:

sgeos wrote:

Sure, if you are happy with "pretty decent". I think we'll all be in trouble when companies realize that they should really be hiring Indian programmers instead of locals. =) I'm not really joking. India has some of the best training in the world. They have practical training. Indians also have excellent work ethic. (They also speak English.)

Are you serious? Where did you get this information from? How much experiance do you have with them, and what I think I really mean is, "How many indian friends do you have?".. As I have a lot.. and will not agree with any part of that statement. Well.. Maybe the English part.. but it depends on what you define english as.. And please don't get me wrong.. I like my friends.. I just know them well enough to know that information above is not true, just a perception that has been made.

My favorite.. Spell minimum..

yim-I-yin-I-yim-U-yim

I agree with brenden. India is outsourced to by a lot of firms, not only because they are cheap, but because they are well trained. Their courses are far more intense than any of the top Universities in England.

Lynx wrote:

sgeos wrote:

I think we'll all be in trouble when companies realize that they should really be hiring Indian programmers instead of locals. =) I'm not really joking. India has some of the best training in the world. They have practical training. Indians also have excellent work ethic. (They also speak English.)

Are you serious?

As I said, I'm not really joking.

Lynx wrote:

Where did you get this information from?

Have you heard of the Indian Institutes of Technology? If not, you ought to know about them- they are some of the best tech schools in the world. Anyone who graduates from one of them can basically find a job anywhere. Applicants who pass the test, but decline to enter (*) can get into an ivy league school more or less anywhere. (Not that I have a high opinion of ivy league schools in the US/UK, but that I'll leave that for later. =)

The Indian Institutes of Technology are not the only good schools in the country. Indian tech schools are just better, on average, than tech schools in the rest of the world.

This article struck me as interesting.

Lynx wrote:

"How many indian friends do you have?"

Keep in mind that by Indian, I mean person of India, and not native American, or aboriginal or whoever else was been confusingly marked as Indian.

Lynx wrote:

.. As I have a lot.. and will not agree with any part of that statement.

I'm assuming that they were all schooled in India?

I've had a bunch of friends of Indian descent. (As in 100% Indian "genetically") But, they were raised in the US/Canada... which means that they don't count for equation. Being "Indian" doesn't magically make someone better at tech jobs. India just does good job training people for tech jobs.

Lynx wrote:

Well.. Maybe the English part.. but it depends on what you define english as..

Indian English is English. It's just Indian English. Japanese Engrish isn't English. (That's not to say that individuals can't pull English off.)

Lynx wrote:

And please don't get me wrong.. I like my friends.. I just know them well enough to know that information above is not true, just a perception that has been made.

Either India does a better job training tech people, or they are good at fooling people into believing that they do. The former seems much more likely to me. (The latter strikes me as something close to a conspiracy theory.)

Lynx wrote:

My favorite.. Spell minimum..

yim-I-yin-I-yim-U-yim

I can't figure out what you are eluding to.

-Brendan

(*) You might decline to enter if you did not get a high enough score to enter the program you wanted to enter.

sgeos wrote:

Sure, if you are happy with "pretty decent". I think we'll all be in trouble when companies realize that they should really be hiring Indian programmers instead of locals. =) I'm not really joking. India has some of the best training in the world. They have practical training. Indians also have excellent work ethic. (They also speak English.)

-Brendan

I think one of the biggest problems when designing something is outsourcing a programming task to some other part of the world, where the actual problem is not fully understood. Case in point, my super smart car radio always changes the station whenever I drive into a tunnel or even around a corner. It might be nifty feature in the middle of nowhere, but in a big city it just makes you want to kick whoever came up with that concept.

Mostly, I am firmly against this whole "we need to design smart systems" approach they ingrain into computer science people these days. In general it's a laudable effort to assist the user, but more often than not I find this idea to help me with thinking and deciding what I really want to be quite patronising, preposterous and aggravating.

First, I understand we are discussing indians from India (dots, not feathers). All of my friends were born in India and came here (USA) to finish their education (Masters Degree). I know some from both north and south India and have one married into the family. I have worked with many in the software industry. And some of them are great at what they do. But, based off my personal experience both in northern New Jersey and Chicago, they are not any better trained or better prepaired then someone from a good US tech school.

As with any stereotype, there usually is reason for it, but it can't be applied to the whole. Are there great programmers from India? Sure. Are there great programmers from the USA? Sure. You can probably say that for any country. But, are there "more" great programmers from India? Personally, I doubt it.

Anyway, this is all based off of personal experience, not articles that may have been written or reports. I've had them long enough to learn the tricks.. Know exactly what it is like in India, and why most want to come here, "get rich" and go back.. Though none that I know of so far have ever went back..

Quote:

I can't figure out what you are eluding to.

Heh.. Actually, it's not Indian English, it's British. They learn words like dickie for trunk and pernounce schedule like "shedule". If you say out loud what I typed in, or if you knew an indian from India (learned to speak English in India), you could ask them to spell minimum and you would understand. Keep in mind that I learned all of this stuff from indians.. I worked for a software company for 1.5 years that was all indians except for the receptionist and one programmer.

I understand what you think.. I thought the same way 10 years ago. It wasn't till I had 10 years of exposure, have best friends be indians, that I learned it's just a stereotype, not fact.
_________________
NDS Homebrew Roms & Reviews

Have you seen the standard set of workload they have at uni? One guy on our course who came from pakistan showed me one year of work in his university - the volume of work produced could challenge our entire 3 years of working.

And sure there are great programmers from all around the world; but places like India and Sweden spawn out large numbers of them. I'm just trying to figure out where I heard/read about the reasons for outsourcing to india apart from their cost. I'm sure it was both from college and university lecturers.

First, MCSE bootcamps come to mind..

As for outsourcing.. there is only one reason and that is money. Either a savings or even a perceived savings and companies will outsource. The company I was working for has decided to let go 250 IT staff to outsource their IT with HP. They "think" they will save money, but what they don't realize is that contractors aren't as flexible as employees. Our field support team handled everything from servers, workstation, switches, pbxs, voice-mail systems, cabling, you name it. I think they will be supprised when a cable tech has to be called in for a problem after the server tech has left and the issue is still there.. It's all about cost. My brother tipped a couple of kids $.50 for carrying his bags at the motel.. He was told that he shouldn't have done that, as it is more then they normally make in a week. Unless you have personally experienced it, I don't think you can understand. Even with USA universities, just because you received a degree from that institute, doesn't mean you "earned" it.. if you know what I mean..
_________________
NDS Homebrew Roms & Reviews

Money is always going to be an issue, but you still need to be confident that you work will be carried out to the required standard otherwise having it done for free is no bonus.

gbadev.org forum archive

Game Design > Three month demo... three month game...

#108803 - sgeos - Sun Nov 12, 2006 4:10 am

#108856 - Ultima2876 - Sun Nov 12, 2006 12:32 pm

#108862 - Optihut - Sun Nov 12, 2006 1:20 pm

#108869 - sgeos - Sun Nov 12, 2006 2:41 pm

#108896 - poslundc - Sun Nov 12, 2006 8:14 pm

#108900 - sajiimori - Sun Nov 12, 2006 9:51 pm

#108922 - sgeos - Mon Nov 13, 2006 4:00 am

#108926 - Lynx - Mon Nov 13, 2006 5:59 am

#108940 - keldon - Mon Nov 13, 2006 10:31 am

#108952 - sgeos - Mon Nov 13, 2006 1:57 pm

#108970 - poslundc - Mon Nov 13, 2006 6:14 pm

#108990 - keldon - Mon Nov 13, 2006 10:00 pm

#109004 - gauauu - Mon Nov 13, 2006 11:18 pm

#109007 - sajiimori - Tue Nov 14, 2006 12:08 am

#109026 - Lynx - Tue Nov 14, 2006 5:53 am

#109044 - sgeos - Tue Nov 14, 2006 11:07 am

#109145 - tepples - Wed Nov 15, 2006 4:03 pm

#109171 - gauauu - Wed Nov 15, 2006 8:17 pm

#109180 - Lynx - Wed Nov 15, 2006 9:35 pm

#109185 - sajiimori - Wed Nov 15, 2006 10:57 pm

#109215 - Lynx - Thu Nov 16, 2006 3:23 am

#109216 - sgeos - Thu Nov 16, 2006 3:42 am

#109233 - Lynx - Thu Nov 16, 2006 7:46 am

#109242 - keldon - Thu Nov 16, 2006 8:40 am

#109254 - sgeos - Thu Nov 16, 2006 1:03 pm

#109267 - Optihut - Thu Nov 16, 2006 5:52 pm

#109299 - Lynx - Fri Nov 17, 2006 1:17 am

#109305 - keldon - Fri Nov 17, 2006 2:21 am

#109306 - Lynx - Fri Nov 17, 2006 2:44 am

#109307 - keldon - Fri Nov 17, 2006 2:54 am