Nice to hear it is going well.

Thought I'd add that I'm on a half day today. I'm not trying to make everyone feel jealous ...I'd just like to point out that I'm forcing myself to be more productive this morning to get about 70-75% done of what I'd get done in a full day. Saves me having work pile up.

But that should tell people that they need set times and a clocking-off time to be productive. If people know that they're going to be doing 12 hours of work no matter what or have all the time in the world to cover their inefficiency ...they won't push themselves any harder, schedules will break and any chance of a life will go out the window.

Hopefully, people will have been honest in these answers. There are practices going on in this industry that need stamping out.

@1: If you can do 75% of a days work in half a day, then you didn't allocate a full 100% or your production time to your schedule.

Most people have got a day to do a day and a half's work, be thankful you have such a lenient schedule. You cannot force a litre of milk into a pint bottle, regardless of how productive you consider your attempt to be. If you can, then that "litre" isn't as much as you told people it was. I.e. you used the "yeah, it will take a day" line, when you knew it was half a days work. That only works once, because next time, you only get the half day, for something that could turn into a full days work.

I'd be interested to know what development role you actually have, i.e. coder, designer, artist etc... to get such a schedlue.

What is required in the industry is to avoid crunch by minimizing mistakes during early development.

It is true that the old days of working 3 days straight through with no sleep are over. However there is still bebnfit to be gained from flexible working hours in game development. The main reason for this is that sometimes it is very counterproductive to go home until your latest piece of work is properly finished... this may mean going home at 9pm and should be backed up by allowing that individual to come in to work at mid-day the next day instead of at 9am.

This process of finishing all work thoroughly from the start drastically reduces bugs, improves the quality of the product all the way through the development cycle, leading to a better tuned more polished game and reduces the length of the hell at the end.

Unfortunataely as teams have got bigger and the industry has become more "professional" it has become difficult to financially incentivize development staff with royalties on products (meaning they actually have something to potentially gain for working all this free overtime)

In my experience time and time again quality of development is routed in the contractual structure of all key development staff. The 5 main areas to address in regard to staff satisfaction are a. Monthly Pay, b. Hours,
c. Royalties/Bonuses (chance to make more money after work is completed), d. feeling satisfaction and self expression from work, e. feeling valued within the development team hierarchy.
To get staff satisfaction is a balancing act between all these factors, and it should also be remembered that to make good products is MORE important than short term staff satisfaction. Because in the long run most staff will be happy just because they are making good products and are part of a successful team.

I believe that a more successful structure of development departments throughout the industry can be achieved by creating a structure that pick and mixes the best aspects of contratcual structure and development procedure from both current systems and the older systems that were used by some of the more advanced old school teams.

"...this may mean going home at 9pm...This process of finishing all work thoroughly from the start drastically reduces bugs, improves the quality of the product all the way through the development cycle, leading to a better tuned more polished game and reduces the length of the hell at the end. "

What a ridiculous statement. If you are a programmer then you've obviously never spent the time to analyze what 12hr working days produce i.e. crap buggy code, low moral in the office (because if one does it everyone has to), lack of communication (everyone turns up at random times) and a damaged home life. Do a bit of research on employee productivity and behaviour, there is a lot of it out there and its been around since Ford started.

@2 I'd like to think I work 100% every day. I may have got my percentages wrong as 88% of percentages are just made up on the spot. I probably shouldn't have used them.

I meant just a little extra push to power through some work. You know how it is...you just focus and get stuff done.

Churn through the more boring tasks that need doing. Avoid tasks that need a input from others. Avoid getting caught up in discussions about the game. Avoid having a quick peek at websites like this while waiting for the thing to build. Not have a cup of tea for waiting for the kettle to boil. Perhaps hold it in for a bit longer when you need to go. All them tiny things add up.

Sorry, but during a full day of work (never mind a week) I need to stop staring at the monitor for a couple of minutes every so often. It actually helps me think clearly (the toilet is great place for a eureka moment). I'd argue that we all should.

You can't go full throttle all the time. It's a marathon, not a sprint. Having set hours and set days allows you to pace yourself correctly.

The argument isn't trying to put a litre into a pint jug, it's that they shouldn't have give us a litre because we only have a pint jug and we're going to get it all over the floor. What a mess.

...and btw, my tasks are scheduled well and I don't have input to 'cheat'. But if I did have input, I'd say a day was 8 hours and not 'cheat' by doing it in 12 hours.

I work as a programmer, and like all programmers I'm no stranger to unpaid overtime. My personal view on this topic (and is by no means in any way shape or form 'definitive') is that overtime is caused by poor management and bad development practices.

An experienced producer must know when to please a publisher by accepting their changing requirements, and when to negotiate an alternative, and how to mitigate risk by successful resourcing. Often it seems like producers do not successfully recognise the magnitude of certain tasks, and just pile up the work on their developers desks, and this causes overtime because if the resources aren't there then the resources that are must be squeezed. Combine this with poor project management and resource squeezing turns into a disaster, which results in crunch.

Another problem in my opinion is ancient development practices. Every studio I've worked at only produces a technical design to reassure the publisher and then it gets thrown out of the window as soon as the first changes to the requirements start to roll in with a milestone to deliver, then we're back to the cowboy coding model. Agile seems to be the prefered development method, but then most developers I've worked with say they're agile and then don't really practise it.

I'm not saying I know it all, but my opinions are based on observations I've made, and I wont pretend I know all the answers, but I do know that games developers aren't the only ones who face these kind of problems, yet application developers work normal hours and get paid overtime. At the end of the day just because our discipline is routed in entertainment does not mean that it should be considered any less a discipline, and nowhere near as far away from application development as we seem to think. Instead of tossing our hands in the air and claiming it was impossible to mitigate the overtime, it's time to start carefully considering how it can be mitigated not just from a managerial point of view, but threaded throughout every stage of the development process.

Sometimes things change, and sometimes that can be a good thing.

I'd just like to point out that Develop doesn't condone some of BC's advice - specifically 'avoid having a quick peek at sites like this while waiting for the thing to build' ;)

And Jon - many of the replies we've had haven't necessarily begrudged crunch - because that polish phase *is* important, and like you say, at times it can be more benefitial to stay late - but that it's uncompensated overtime. Which is completely and totally wrong, whether it's an established process or not. Which I'm sure you'd agree with!

Similar to what Mike Capps was flamed for saying, really. There's not necessarily a problem with crunch if they're upfront about it and compensate generously, as Epic allegedly do.

I think it's important to stop using the word crunch, and start calling it what it is: Unpaid Overtime.

Here in British Columbia, EA even bought "modernization" of the Employment Standards Act, to completely exempt all "knowledge workers" from the acts protections.

Here's a good one in that act that we don't get (paraphrased): An employee must be given at least 8 hours off between shifts.

I even had the HR chick at my last game job tell me that the game industry couldn't survive without that sort of bull****. Ya, just like the game industry in California can't survive without unpaid overtime, huh? Or the film industry? Ridiculous.

I lean much more towards the "outright sociopathy" side of the debate, that combined with managerial incompetence.

I remember doing "crunch time" a few years ago. I came in to work, and the receptionist told me, "Your flight leaves in 50 minutes, you have 5 minutes to gather whatever you need, and the person in the company with the most speeding tickets is waiting to take you to the airport". (The airport was about 45 minutes away, without traffic)

So, I ended up doing a 72-hour long weekend at the client site, got the hardware back up and running, the software patched, and the data recovered. What was my reward? Well, I didn't get my pay docked for leaving the office early that day.

Oh yeah, I got to put 10 minutes of long distance on the company calling card, so I could call home and wish my family a happy Christmas day. And I also got three minutes of company cell phone time to let them know that I wasn't going to be coming home on Christmas eve either.

That kind of company loyalty was rewarded a few months later, after a week's vacation, with a notice that I was to be downsized the next week, and it would be appreciated if I could port the company's main product to a different operating system, and complete it before I left.

That's why they have people as programmers -- they haven't yet found a way to get blood from a machine.

I'm terribly sorry to break up this magnificent celebration of development's woes, but do you guys honestly think this type of situation doesn't exist in every other industry, albeit under different monikers? It's not that I don't wish it was different, but honestly - with the exception of non-creative assembly line work, this is a ubiquitous problem, not a games one.