Try "High-accurary Heliocentric Galactic Time-normalised Tetrahedron GPS" as a better acronym?

XTest? That generates synthetic events, I don't think it lets you read relative mouse input data, or stop the cursor moving around when doing so, which is what that bug needs.

You might be thinking of XTrap, which Xorg dropped in 1.6. See comment 237 through comment 241 of that bug for details.

Not true. Japanese has tonal aspects to the spoken language which are not present in its phonetic writing system, but which differentiate phonetically similar words and ambiguous phrases, and indicate divisions within sentences.

If the agile development roundtable at GDC 2008 was any indication, scrum is already rather popular in games development, and gaining momentum.

Never tried it myself though. I'm quite happy being able to go to my boss and say "What do you think I should be working on next?". I'm not convinced that self-management is the path to self-empowerment.

So no crunch time, except that one bit of crunch time?

I do admit that one is pretty damn close to zero compared to some of the horror stories that float around the games industry the same way that coffee-cup holder incidents float around support desks.

As another poster or two have already noted, I think people's idea of crunch (and the companion term, "death march") varies quite wildly.

My own feeling currently is that if you don't crunch on a project, you get left with a sort of feeling that you could have done more or better. Milestones are soft of like exams in that way.

But I haven't really experienced a crunch-free project to compare it with, nor have I experienced a death march or even been scarred by a particularly heavy crunch.

That last 10% is all the unexpected stuff. The stuff you can't schedule, but can merely attempt to estimate what time it'll take.

I'll pick some random examples.

Requirements disagreements. Not changes, but when requirements are perfectly clear to all parties, but nonetheless not the _same_ clear vision.

Greater-than-budgeted for absenteeism. As I already mentioned, losing the whole team for a week due to illness will be devastating to a milestone.

For that matter, a few low-output days at the wrong time can also make quite a big dent, if you're on the critical path.

Incredibly difficult to replicate and track down bugs. Everybody gets heisenbugs. I'm open to suggestions on estimating time to fix for an issue you haven't got a solid repro on, let alone an idea of the actual bug.

Technology changes. New VCS, new graphics engine, new audio engine, new language, new art tools, new Internet connection. You only change these things before a project starts, obviously, but that doesn't prevent them throwing up new and interesting delays well after you thought they'd settled into the routine quite nicely. And that's when they aren't so bad that you need to switch and retool mid-project.

Oversights in the scheduling. The number of times I've said "Oh, I forgot to allow time for change X, which is needed for features Y and Z which I have to do this milestone"... well actually only a couple of times, so far.

Natural disasters. When a burst water main puts your office and the server room under 30cm of water on a Sunday afternoon, the mere existence of backups doesn't remove the smell from the carpets. That can vary from shutting down the office for a few days, to merely causing everyone to take any opportunity possible to get out of the building.

And the nastiest one, to my mind.

Once the game comes together into something the designer can play with, the designer discovers that it's not actually that fun. One could argue that this is a change in requirements, but at the end of the day, "it has to actually be a game" is a fundamental requirement of producing games. Some places have the luxury of killing projects that hit this point and moving on to something new. Some places have the bloody-mindedness to ship it anyway. Some places will try and fix it during polish time. And some places will tell the publisher what's happened and try and retool the milestones to squeeze some more design time in.

Anyway, moving milestones to account for the above avoids the crunch and is usually the correct decision but doesn't actually change the fact that the project took longer than scheduled.

The issue that started this "split" is about people who _are_ being paid for crunch time, in so far as they have (according to what I've read about Epic, anyway) agreed to work above-and-beyond a 40-hour week on a regular basis for the money being offered. I don't think these people are being unfairly exploited.

It's of course blown out to encompass all those for whom crunch is above and beyond the call of their contract, and who aren't getting compensated for it.

And I certainly agree, no compensation, no crunch. If your studio doesn't look after you, don't labour on thinking you're setting yourself up for better later. You're just marking yourself as willing to be taken advantage of.

But not a heck of a lot more complicated/complex than a collaborative picture, which also involves manufacturing or paying someone else to manufacture the canvas, easel, paints, and having to stop and remeasure for different museums every step of the way. And where half your artists are using acrylics, and half are using watercolours, except for the one person who insists on painting by putting the entire canvas on the floor and flinging chocolate syrup at it.

Which is why so many games use an existing engine. It's like starting your picture with the easel already set, a nice set of premixed colours, and possibly even a set of measurements for common museums.

It's also why so many games studios refuse to hire people who fling chocolate syrup at things.

As opposed to all the other things you don't like in your terms of employment? Frankly, I'm happier with the idea of Epic saying up front "we expect you to work 60 hour weeks" than of ending up somewhere which has a 37.5-hour week on the contract, but then gives you negative performance reviews and references if you fail to be at the office before your boss every Saturday.

Not to say I'd necessarily take a job at Epic. I don't think they're bad for doing it, I just think they're wrong.

Which usually indicates that you've confused "love games and want to be part of the process" with "love playing games and want to be able to play games for a living". They're not mutually inconsistent, but my criteria for enjoying a game has gone up drastically since I started working in the industry.

This is not a bad thing.

And sure, I could be making more money programming in a business environment, or administering systems (and have done exactly that) but then I wouldn't be a video games programmer. I wouldn't be (sometimes a bit indirectly) manufacturing fun, producing someone's creative vision, and generally contributing to that vast pool of noise that entertained me throughout my childhood.

That's 180% of the _estimated_ effort, or in fact the estimated elapsed calender-time. (It's also an exaggeration for humourous effect.) If we never underestimated work, or misidentified dependencies in the work, or lost the whole team for a week or two due to a nasty virus, we'd never have crunches. And in all those cases, crunches can still generally be avoided.

I think the 90-10 rule is different. I learned it as a rule of software optimisation, while the one I started with is a principle of project scheduling.

Of course, being a principle of project scheduling, project schedulers are aware of it. My boss takes any time estimate I give him, and applies some factor I haven't dared ask about.

And it's usually accurate, which is why I haven't dared ask. I'm happier not knowing for now.

As they used to say, "The first 90% takes 90% of the effort, the last 10% takes the other 90% of the effort". Crunch time is just the expression of doing that last 90% effort in the last 10% of the schedule.

Mind you, my current employer states that they'd prefer we to not have to crunch, given the chance. I get a talking to any time I come in and work on the weekend. ^_^

Then again, I quite like crunch, as long as it's not overly extended. It's a bit of a rush, and it can be fun unless you're the one who's hideously behind on the milestone.

There are plenty of crunch horror stories though, and everyone is aware that crunch adds bugs, so usually management will look to shift or redefine milestones where possible to avoid it. Or at least my management does. YMMV.

You need to look a little harder. There's two or three in the 26-50 and another three on the 50-75 pages.

The Kindle's results seem somewhat skewed because there's a lot of (I'd say mostly, but I havent' counted) free books in their top 100 list.

On the other hand, looking at the fictionwise list, the one title not tagged erotica is by an author whose other works I've read have involved plenty of sex and violence. They're not erotica or even overwhelmingly romantic, but my local bookshops no longer distinguish paranormal and paranormal romance, so they sit side-by-side on the shelf.

It might be that Ficitonwise has a particularly strong suit in the paranormal, romance and paranormal-romance categories, ranging up and down the scale erotica-wise. They're generally popular categories, I assume, based on the number of bookshops (particularly web-based bookshops) that specialise in these three categories.

Coming back to the parent post, the Stephenie Meyer books (Twilight etc) I'm told are the teenage girl's paranormal-romance of choice, equivalent to some of the less erotic novels that appear in Fictionwise's top sellers.

Again going by my local bookshop, in the science fiction/fantasy area, there's a shelf which is just Terry Pratchett books. Last time I was there, a shelf in the paranormal section was dedicated to Stephenie Myer, although this was right after the Twilight movie had released, so I don't know if that'll last.

The actual survey, from 2002, is at http://www.abc.net.au/science/k2/lint/