Archive for the 'Industry Rants' Category

A typical crunch story

Posted in Industry Rants on October 31st, 2013 by MrCranky

Following on from my previous two posts about why crunch happens, the last of my crunch posts (for a while at least) focuses on the developer, and why crunch happens even when projects are started with the best of intentions.

For most developers, the underlying business reality is that the deadlines are fixed, the budget has little room to grow, and the scope is broadly fixed when the title is green-lit. The only axis with any real wiggle room is quality, but dropping your title’s quality will hurt sales, and even if it doesn’t cost you this time, your next contract will suffer because you let the quality bar slip. But it’s that inability to shift any of the parameters which is the reason why crunch is so common in our industry. Starting off with an unrealistic schedule is what causes crunch. Failing to respond to external or internal factors that have increased the project cost, either by shifting the deadline, cutting scope or increasing the budget causes crunch. If a team is closing in on a deadline they can’t make, and the developers can’t shift the deadline or cut scope, then of course they’re going to try crunch, ineffectual as it is. They’re stuck. Why? Because the entire thing was unrealistic in the first place.

Most big games seem to involve crunch in some way (whether they turn out good or bad). But we all know, management included, that crunch is something to be avoided. At some point, the management and/or the team, voluntarily or not, decide that crunch is the least bad of all their available options. Given how bad crunch can be, and how many bad experiences we’ve all had, I don’t believe that smart, capable people would make that decision for no good reason. So I want to explore that reasoning, and perhaps bring it out into the open.

I’d like to posit an example that I’ve seen a few times, obviously it’s not the only case. The developer is mid-way through their project. Two weeks from a big milestone, the time for what needs to go in doesn’t fit into two weeks. Publisher won’t budge on dates or features, and there’s no more people to put on it. But maybe it’s only three weeks worth of work. So the team does 60 hour weeks, but they still don’t quite get it all done. But they were close enough that the publisher accepts it, and the work still left to do (lets say a couple of days) gets rolled over, because you’ve claimed to deliver it, right? You can’t get it cut later, the work still needs done. But hey, only two weeks of crunch is productive, right? And it felt productive – you got 2 and 3/4 weeks done in the space of two. And the crunch is ‘done’. Only now you’ve just cut two days out of your budget for the next milestone. And even if you hadn’t the next milestone was actually a week over budget as well.

Chain a few of those milestones together, and not only have you been alternating between fortnights of crunch and 40 hour weeks, but your actual feature set / quality is lagging behind the milestone list, and the publisher and their QA team know it. For milestone one the decision seemed obvious – it was only an extra week of work, and you pretty much nailed that. For milestone two, well, you knew there had to be a bit of knock-on when you slipped the first milestone a little. Third and fourth? Now the publisher is on your back, and things are getting awkward. Now it’s not “we need to somehow get an extra week’s work done to make this the game we want it to be,” it’s “we need to get an extra fortnight’s work done just to avoid the publisher canning us for breach of contract.” They’re running just to stay upright.

At that point, the management are sitting there with a pretty rubbish choice. If they do crunch, well then perhaps those work-time studies were right, and the team will actually get less than 40 hours done in a 60 hour week. But if they don’t crunch, then they know they’re going to fail. The milestone won’t be hit, the bills won’t be paid, and it all goes south really fast. The only hope they have is that the studies were wrong, that their team is at the top end of that bell curve, and that they can still be more productive than normal even though they’re pushing harder. But the fact is, they don’t really know. There’s no control group to compare themselves against, there’s no equivalent game being made without crunch. So they crunch and hope, while they try to dig their way out by other means (pleading with the publisher for more leeway, slashing the quality bar below where they’re happy with it, stealing resources from other projects / teams).

Thing is, the alternative: no crunch, and hope that by not crunching you actually do more already assumes that you’re so far down the road of crunch that even with >100% effort you’re doing <100% actual work. And most teams aren’t prepared to admit that. Not the managers, the teams. They know that the shit is hitting the fan, and they want to bail the team out, they don’t want to be the ones saying “actually guys, I was zoned out for a whole bunch of last week and maybe did 30 hours of actual work in my 60.” They see their bosses sitting in the meeting rooms with the publisher with all serious looks on their faces, and a lot of them (usually the younger ones who haven’t been through the wringer quite as often) feel guilty that they couldn’t be more effective, that they’re struggling after a few long hard weeks.

Worse, if the managers did say “no crunch, and we’ll do better work,” they’d have to admit to the publishers that they’ve been barely able to hit the milestones they agreed on, making them look like a poor developer. Because even if the publishers aren’t aware of the crunch before, you’ve got to explain why crunching now isn’t even an option. Now if there’s been shifting milestones or external factors that can be argued around a bit, but fundamentally the developer is having to admit to the publisher that they’re not good enough at development to deliver on what they’ve promised, for whatever reason. That’s a bitter pill, and not one that most developers want to swallow.

Again I think it’s stemming from the harsh financial conditions and unfounded optimism: the budget is fixed low due to market expectations, but the feature set / quality bar doesn’t shift; the developers agree to the optimistic assessment because it’s sign this gig or go hungry. Then everybody loses. The team gets burnt out, the developer loses money and their team, the publisher gets a shit game if they get a game at all, and the customer gets delays on their game and a poorer experience. It just isn’t as simple as those who’ve been burnt by crunch saying “it simply never works.” Long term we know that’s true. Even short term it’s not great. That doesn’t mean it won’t happen, or that sometimes it doesn’t need to happen.

But just because I understand the reasoning, doesn’t mean I agree with it. Management shouldn’t be burying their heads in the sand. They should be honest about their teams situation and performance, and they need to know that the very real costs of crunch on the staff aren’t something they can just ignore. If workers aren’t shouting against crunch, management are all too likely to forget that it’s not just the productivity on the game that matters, but the well-being of their staff and team, up to that deadline and beyond it. We absolutely should not be accepting the word of management teams that are conflating crunch with ‘passion’, and suggesting that crunch is a natural, positive part of game development. It’s not. Mandated crunch indicates a severe, uncorrected failure from somewhere along the line. Maybe it was the planning, maybe it was the publisher, maybe it was the team, maybe a combination of all three. But it’s always a failure.

The real cost of making games

Posted in Industry Rants on October 24th, 2013 by MrCranky

The last time I talked about inaccurate estimating, and the dangerous road publishers and developers are heading down by lying to themselves and each other about the real cost involved in making their games. To me, the arguments about crunch and contingency are looking in the wrong place. They’re a symptom, not the root problem in themselves. Crunch happens, because there aren’t any tenable options left to the developer that is mid way through a title, and has a fixed deadline to hit. To appreciate why it’s the only option left, you have to step back a bit.

Most developers are pitching for business from publishers. A few get their finance from a non-publisher entity, but the relationship is effectively the same. Publisher-owned studios are in much the same situation, it’s just that the pitch and negotiation stage isn’t between two distinct businesses, but between units in the same business; so the negotiation is less antagonistic, but the basic relationship is the same. One side provides the finance, and gets the revenue/profits from selling the game; the other provides the game for some cost. The financier is buying a title that it can sell on for a profit. The console market has moved to a place where to make a profit, you have to hit a certain level of quality and have a game of a certain level of scope. So there is a minimum viable product for the financier, and an effective market size that means it’s not cost-effective to make a title unless it costs little enough that it can make its costs back. Most titles cost is proportional to the number of man-months involved, so shifting a deadline out doesn’t really save any money, quite the opposite – the developer staff need paid more for that extra time. So generally, the deadline is fixed.

It’s with that price in mind the only variable left gets decided: scope. How big a game will it be? How complicated? Will it break new ground, or go with a safe mechanic or style that the developer is confident of delivering for the budget? Here’s where the problem comes: how big does it need to be to make its money back? I think we’ve got to face the very real possibility that the effective cost of making the games the console market expects outstrips the likely revenue you’ll get from those titles. If it does, the difference has to come from somewhere.

From the developer’s point of view, it is hard to get a publisher to sign on to what you think is a reasonable price for making the game they’d like. Of course they want more for less; their margins have been squeezed to the bone as it is. But if you have a team of staff waiting to make a game, the cost of refusing to make a game because the publisher is only prepared to pay 80 or 90% of what you think it will actually take to make their game may be that you fold altogether. At least if you take the 80% deal you can argue the scope down later, or find some other way of making it work.

That’s where the trouble kicks in. If your company is bidding low to get financing, then making up the difference through crunch (which is effectively asking the employees to subsidise the project cost through ‘free’ labour), then it’s screwed. But the alternatives aren’t much better for the company, although they’re clearly better for the staff:

  1. Don’t make the game at all. Company has no business, shuts. Financiers get no games, can’t make a profit.
  2. Make a smaller game. Market rejects it due to unrealistic expectations, financiers lose out, next title doesn’t get funded, company shuts.
  3. Bid low and try to make the game for less than it costs, through crunch. Company and financiers do okay on this title. Staff get burnt out, next title costs even more to deliver (through reduced efficiency/quality), repeat this choice scenario again but with worse numbers to start with.
  4. Bid low and manage to raise the price later. Company does okay, but financier loses out when revenue doesn’t match cost. Next title doesn’t get funded, company shuts.
  5. Bid realistically, financier knows the numbers don’t work. Company loses out, shuts. Financier either gets no games, or finds some company willing to choose scenario 3.

You can probably see why companies choose option 3, even when they know what the consequences are. Because it’s the least-bad option available to them. And they can persuade themselves that this time will be different, this time they’ll work smarter, and they’ll hit those lower costs without crunching, because they’re good at what they do. When that works out, everyone’s happy. When it doesn’t, there are lots of factors they can blame. NB: “Bid realistically” here means hiring great planners, and adopting a sensible, reactive planning approach like I described last time. A company can be bidding low without even realising it, but that doesn’t make their situation any better.

When the fundamentals of it are that it costs that particular developer more to make that particular game than they thought, that’s a business doomed to extinction. Crunch is a side issue, one of many symptoms, of which the root cause is denial about how much it actually costs to make the games we are building. The only way out is to make different games, maybe in different markets, which actually cost less to make than they take in revenue. Maybe I’m wrong, maybe the console games business is eminently viable. But the reality of difficult financial conditions and the developer’s strategy for dealing with that is the core problem underlying crunch. Railing against crunch is going to do little to help us, if we don’t address the underlying business conditions that cause the unrealistic expectations in the first place.

Crunch vs. Contingency

Posted in Industry Rants on October 17th, 2013 by MrCranky

So the PlayStation 4 and XBox One are soon to be released, launching us into another console generation. This time around, it’s not just me that is cynical about the prospects for the ‘traditional’ games industry. The ecosystem of games has been changed irrevocably by the advent of smartphones, tablets, and a resurgence from PC gaming. It’s no longer a given that there is a niche for console gaming large enough to support the costs of developing those games. But I’ve certainly been wrong before, and I don’t want to call console gaming dead before its time.

Recently, in response to this article on crunch, I found myself  coming at this tired old debate from another angle. Many in the industry, generally not management types, are frustrated by the management’s inability to put in sufficient contingency, resulting in an almost inevitable period of crunch, where the developers put in overtime far over and above their expected working hours, to try and get the title out  for its fixed deadline. Typically, when the ‘more contingency’ argument is rolled out, it is countered with “game development is hard, and unpredictable,” and “you can’t schedule for ‘fun’.” The counter-counter argument to that is typically that other software industries deal with equally unpredictable factors, and they don’t have to crunch in quite as pathological a way as we do. The core of these arguments is really this niggling underlying sense that crunch is a natural consequence of not being quite good enough at making games, and that’s problematic.

Thing is, being bad at making games is a cause of crunch. But not because the people making the games are bad at what they do. Because part of making games is estimating how long it will take (and correspondingly how much it will cost) to make the game, given the team you have. Not an ideal team, not the team you’d like to have, the team you have actually got. Planning is hard. Some game-devs, usually the ones who’ve not had to make a plan for any sort of sizable project, think that all that is needed is ‘more contingency.’ This is waved around as if it was really simply to do, and that the management / planners are not doing it deliberately so that crunch is required, because crunch is cheap, and contingency isn’t. But anyone that has to make a plan, and more importantly anyone that has to sell a plan to the game’s financiers, knows that simply whacking on a bigger and bigger percentage figure for contingency doesn’t work. It is admitting that you don’t know how things are going to go, and trying to pick a single large fudge factor that insulates you against bidding too high or too low. We almost never make the same game twice; previous games aren’t much help at predicting how long future games will take. You can break things down to estimable components, but the way those components interact, in ways which may or may not work, which may or may not be fun, is what turns a project from under-budget to over-budget.

That’s not to say we can’t get a lot closer than we do, with better planning. Game-devs in my experience are almost always hopelessly optimistic, even though project after project teaches them that requirements do change, designs do change, and that a sizeable software project invariably has nuances that couldn’t reasonably be predicted at the start. Fundamentally though, there are two changes that need to happen before we’ll stop seeing regular, mandated crunch.

Firstly, we need to accept that the scope, design and timetable for the development is flexible. Trying to nail down the plan up front is foolish and naive. Either the developer does stick to the plan, and the game is crippled because it didn’t respond to the practically inevitable changes that were needed to make it the game it should have been; or the developer diverges from the plan, and either the publisher has to pick up the cost (from the deadline slipping) or the developer does (either by paying for more development time, or by burning out their staff with crunch). As the development continues, the plan should become more and more clear, but it won’t be clear up front. A good developer, and the publisher/financier that is bankrolling the development, will be continually re-assessing the plan as to what is feasible, and what is desired. The publisher will always be pushing for more for less money, and the developer will be pushing for less, but it needs to be accepted that the ‘plan’ is a continually shifting thing, that is going to end up being a comprimise, negotiated by both sides.

Secondly, both the financier/publisher and developer need to be honest about how much it actually costs to make the games that are being made. Hiding the real development cost of a title by burying it in crunch is effectively passing off some of the cost of development onto the staff, and that is fundamentally bad for all concerned. But more importantly, it’s leading both developer and publisher down the road to bankruptcy, from sticking their heads in the sand. More on that next time.

Management structure

Posted in Industry Rants on June 28th, 2013 by MrCranky

Written in response to musing about whether or not Valve’s ‘cabal’ structures were useful, or just a quirk of the company.

Management isn’t generally the problem, the problem is that after a certain point the structure starts to exist to serve the structure, not the needs the structure was originally supposed to serve. All organisational structures, be they flat, tiered, cabals, whatever, are there to facilitate the business needs. Generally a games developer needs to make better games, faster and cheaper. When you spend all day in interminable meetings because your hierarchy is a bad fit for what actually needs done, then communication overhead means that more time is spent talking about what should be done than is spent on doing it, you’re not serving the business. When you spend a bunch of time flitting between tasks because it’s not clear whether you should be doing something or someone else should, and end up doing the same thing as someone else while other vital things fall between the cracks, you’re not serving the business.

All different sorts of management can be fine, great even, as long as everyone remembers that at the end of the day it’s supposed to make the work go better, not worse. It doesn’t matter whether it’s top down, bottom up, side to side or shaken not stirred, as long as it’s making it easier for real, productive, money-making development to happen. Remember those Time and Motion studies? I think that’s what we need sometimes – someone from outside to point out when our structures are getting in the way rather than helping. It’s very hard to see when you’re in the thick of it; you get a sense that something is wrong, that this madness can’t be the best way to do things, but not how to fix it.

Maturity in fiction and games

Posted in Industry Rants on November 11th, 2012 by MrCranky

I’ve been attempting to thrash out some opinions in my head recently, and I think they’re reached the stage where writing them down would help. I’m thinking about the sorts of games the industry tends to make, and seeing in them parallels with fiction in books. Specifically I’m thinking about the sorts of stories we tell, and the kind of writing involved. Looking back on the most notable games of the last twenty years, it seems to me that many if not most games use a science-fiction or fantasy (SF&F) setting. The ones which don’t (I’m thinking Call of Duty and the other modern FPS games, Uncharted, etc.) all tend to rely on the same tropes which I’ll talk about later.

For some background, I’ve recently read the Game of Thrones series, which for those who haven’t read it is a gritty fantasy series set in an essentially medieval world. The characters are dark and flawed, and the line between the heroes and villains of the piece is most definitely blurred. ‘Good’ characters are not uniformly noble, and ‘evil’ characters are not unremittingly bad. The main characters are vulnerable as everyone else in the world, they don’t have special skills, they’re not extraordinarily lucky. They die just like everyone else, and just being a main character is no guarantee they’ll even survive till the end of the book. Interesting stuff happens all over the place, not just where the main characters are. Fortuitous events are as often bad for the protagonists as they are good. I won’t say “just like real life” because real life doesn’t have a whole lot of dragons in it, but certainly a lot more plausible than a lot of SF&F fiction.

I’m almost tempted to use the term ‘grown-up fiction’ here, but I think that’s doing a disservice to SF&F fiction, which can be as grown-up and compelling as regular fiction. But the tropes that I see in non SF&F games are the same ones you come across in SF&F fiction and games. Here are few:

  • The protagonist(s) turn out to have amazing powers that elevate them far above regular people, e.g. amazing strength, abilities with weapons or magic, or supernatural senses; or maybe they’re the one and only person who is the fulfilment of some ancient prophecy.
  • These powers are often previously undiscovered and the protagonists develop them through the course of the story, leading to the story’s climax where the full range of their abilities will be tested.
  • The antagonists have powers or a similar advantage that rival the protagonists’, but they will already be in full command of them at the start of the piece
  • Alternatively the antagonists will be in control of the world situation (e.g. an evil government commanding an army of minions), and the protagonists are only safe because they are hidden, and achieve victory by using their superior abilities against ever-increasing numbers / strengths of minions.
  • Minions will be so staggeringly ineffective their only purpose is to be cannon fodder for the developing protagonist. The unstoppable army that has supposedly swept away all resistance seems to be entirely staffed by soldiers that seem unable to tie their own shoe-laces.
  • If the protagonists don’t have great abilities, then they are at least unnaturally lucky – other minor characters throw their lives away while the main characters are miraculously untouched, despite the antagonists being in a clearly superior position.
  • Alternatively they will be the rich and noble sons and daughters of the rulers of the land; uniquely placed to get involved in high adventure, without needing to ever sully themselves with something as hum-drum as a regular job, just to earn enough to put a roof over their heads.
  • The protagonists will always be in the right place at the right time for interesting stuff to happen. The village which has been ignored by the evil emperor for years is raided by the empire’s secret police only a day after the protagonists seek refuge there.

Sounding familiar? Star Wars, Lord of the Rings, Harry Potter, Eragon, The Belgariad; Call of Duty, Half-Life, Doom, heck – every FPS ever, Uncharted, GTA, Max Payne, Prototype, Ninja Gaiden, God of War. They’re not unique to SF&F settings, but SF&F does use them rather a lot.

This I think is where my feeling that these are immature stories comes from. They appeal to our sense of wanting to be special, we sympathise with a powerless character becoming powerful, and standing for all that’s good against a clearly evil villain. We don’t want them to have weaknesses because we’re putting ourself in the protagonist’s place, and we don’t want to have weaknesses. But the notion of a super-powerful character who is only vulnerable because they don’t realise just how strong they are is the very definition of an adolescent fantasy of what a great character would be. He’s a ninja with super-strength, who can fly faster than the speed of sound, and can also stop time and can totally be invisible. Really? And he hasn’t conquered every enemy in the entire world yet why? Comic writers have realised this since the start, as the arms race of super-hero versus super-villain is a never ending one. A super hero who is invulnerable and superior to all his foes is a really boring character.  They have to be vulnerable, both in their powers and in their characters, to be able to weave them into an interesting story. And no, not being able to be everywhere at once isn’t a vulnerability, at least not a proper one. This isn’t limited to super-hero fiction either: if you’ve played Call of Duty or Wolfenstein but haven’t seen Band of Brothers, watch at least a couple of episodes; the brutality of fighting in WWII is inescapable – one man wouldn’t be mowing down dozens and dozens of Axis soldiers, they’d be lucky to kill a half a dozen before luck meant that they took a bullet themselves.

Now flip it around the other way. There is a surfeit of fiction out there that doesn’t fall into these traps (classic literature such as Dickens, Austen, etc. not to mention crime novels, historical fiction novels, romance novels). But comparably there are very few games which don’t. There are plenty of abstract games (e.g. Tetris), simulation games (e.g. Gran Turismo, flight sims, or The Sims), but I think most people would struggle to name more than one or two high profile games with narratives that don’t fall prey to these same easy tropes. From memory I’d call out “Hotel Dusk: Room 215,” as being a good story with compelling and believable characters without any of the tropes I’ve mentioned above. Similarly the LucasArts games did very well at telling a story without requiring the main characters to be super-special in any way. But these are the exceptions and hardly the norm.

Of course, there are reasons why the fiction in games is written the way it is. A Call of Duty game where you were dropped by a single bullet quite simply wouldn’t be fun. An RPG where you played a subsistence farmer, struggling to get by, wouldn’t keep any but the most masochist player interested. However I still think it’s important to recognise that there is a richness of narrative fiction out there largely untapped because we are treading the safe road we’ve walked before. When accusations are levelled at the games industry that we only make games for kids, and that we’ll never make a game that will make people cry (a lie, I know), I look at the sorts of games that get made, and I can’t help but think that we’re not doing ourselves any favours.

That’s not to say that some games aren’t bucking the trend. “Dear Esther” sounded like a laudable attempt, although I’ve yet to play it. I’d love to see more crime fiction brought to life through games (L.A. Noire, for all its plodding repetitive game-play, was a great stab at this genre). I wish someone would tell a compelling ghost story in the form of a game. Heck, I’d even settle for romantic comedy. Just, you know, something that stretches our boundaries a bit, and not just another bullet-proof space marine or boy that finds he is actually an ultra-powerful magician.

The importance of (good) teachers

Posted in Industry Rants on June 25th, 2012 by MrCranky

I usually recommend that students looking to get into the games industry as coders stick with traditional, academic courses like Software Engineering or Computer Science. Not because those courses teach the content most appropriate to games development, but because they leave the students with a well rounded education. With a well rounded education, they can learn the practical / vocational skills needed for games development (a higher level of programming expertise usually) on their own, plus they have the option of a career somewhere other than the games industry if they change their mind or find there is a shortage of employment available. If they specialise in a vocational course too early, they wouldn’t get the more general education that would allow them to work anywhere other than games.

That’s not to say that I discount students from vocational games courses though, far from it. But the quality of those courses varies dramatically, and so it’s even more important to assess the quality of the education they’re receiving. The first and probably biggest alarm bell that rings is when courses employ lecturers without games industry experience. That to me is utter madness. They might have masters degrees or doctorates, they might be the most engaging lecturer in the world, but without industry experience, they are wholly unqualified to be teaching a vocational course. That’s like someone teaching others how to swim when they’ve only ever had a bath. There are many other warning signs of course, but to me an institution that thinks to staff their course with vocational teaching staff with no experience in that vocation is only ever going to produce sub-par graduates.

So my advice to those institutions is this: hire industry experienced people. Poach them away from the industry with better working conditions and less stress, even if you can’t offer them more money. Entice them with the notion of enthusing a new generation of games developers. Find the next big studio that gets shut down (there’s no shortage of those), and see if anyone wants to take a break from the industry proper to teach. But whatever you do, don’t hire academics who’ve never shipped a game in their life.

And don’t hire people who couldn’t get into the games industry on their own, but who want to pretend like they’ve made games so get into teaching. Hint: you’re not a professional games designer until someone has paid you real money to design a game which has shipped. That doesn’t include:

  • designing games for your friends
  • designing your own game but never actually making or releasing it
  • writing books about other peoples’ game designs and how they are good or bad

If you’re going to teach games design, personally I think it should be compulsory to detail which games you designed (or part designed), and how well they did. Your students should be able to go find your games and judge for themselves how good your design chops really are, before they start taking your opinions on design as ‘the way things are.’

In defence of middleware

Posted in Industry Rants on May 31st, 2012 by MrCranky

This mini-rant sprang from a discussion on The Chaos Engine about middleware, in answer to the question: “even if it’s the best engine available is it really worth being locked in to anything other than in-house, license-uninhibited tech?”

That depends on whether you’re interested in building games or shipping games. You’re trading many man-months of effort on a new / unknown engine versus a non-trivial licencing cost. How many games do you have to ship on your internal engine before the difference in cost becomes positive? And what do you do with all those engine developers you’re carrying once the engine is done? Because they’re part of your burn-rate now.

Making your own tech is simultaneously the risky option for the business, and the safe option for the developers. Why? Because as long as you can persuade someone to bankroll it, there’s a tonne of work to do, and it’s nice, tangible work with obvious goals and milestones. You know when you’re done. You know what you’re making. The customers are the other developers on your team, and they’re not nearly as fickle as the public. It’s a lot easier to find success in building your own engine than it is to find success making and shipping games.

That is super short-term thinking though. Because once you’ve succeeded in making the engine, you’ve still got to ship a successful game, and worse, you’ve probably got to ship several successful games before the engine development effort is paid back. Plus your engine will have a lifespan just like they all do: if you don’t profit enough from the games made on it in that lifespan, then it’s been a net loss.

It’s no wonder that individual developers don’t like middleware. It’s clunky, it rarely fits right with what you’re trying to make, and you’ve got little to no control over its development. But “it’s expensive” isn’t a great argument against it, because the alternative is expensive too. It’s not risk-free, but it’s certainly less risky than doing it yourself. It’s a known cost, and in most cases a known risk. Fundamentally, it frees your employers from having to take a gamble on the tech you build, and when the money they’re gambling on your tech is money that they could be gambling on your games, I don’t think that’s really very attractive.

I’d prefer to be working for a smaller company that can be more agile, more robust, and capable of shipping more games, over a company that’s carrying an engine development team, that has to build games based on tech that won’t be done till some future date, and which has less capital to work with because it’s invested a chunk of it in an engine that has yet to pay that money back.

Crunch is avoidable

Posted in Industry Rants, Links from the In-tar-web on July 28th, 2011 by MrCranky

I’m putting off my blogging responsibility this week onto someone else: a great opinion piece from Charles Randall of Ubisoft, rebutting entirely the piece by that moron Michael Pachter which I won’t even dignify by linking to it. Here’s Charles’ piece. Stand-out quote for me:

Crunch is avoidable. But it requires a level of maturity and acceptance that the game industry sorely lacks. People argue that there’s always a period of crunch necessary at the end of a project. But that’s not true, either. If you are disciplined enough to accept deadlines and understand that there’s a point where you have to stop adding features, schedules can be planned with some lead time for debugging.

Anyone who tells you crunch is unavoidable is a fool. It might be that the games being made just now are unprofitable without crunch, but that’s not a reason to crunch; that’s a reason to change the way we make games.

On a similar note, you will find a couple of opinion pieces from me over on I <3 Crunch, a new blog set up specifically to raise awareness about articles on crunch, studios who are crunching their staff (and those which aren’t). I hope that by talking about this more we can put to rest this ridiculous notion that crunch is somehow acceptable or something we just have to live with. It’s the industry’s dirty secret, and the more we bring it out into the open, the better we will all be.

 

Opinion: How the IGDA could help tackle crunch

Posted in Industry Rants on July 18th, 2011 by MrCranky

Erin Hoffman’s comment on my previous IGDA post got me to thinking. If the IGDA are looking for a tangible way they can help things, what can they really do? So here’s my suggestion:

My issue with the way the IGDA work with regards to these reports of crunch is pretty much the same every time. They don’t seem to do anything unless someone makes a formal complaint to them, and even then they seem to put the onus on the individuals at the studio to be acting on it themselves. To me, it should be the other way around. There should be a ‘report a company’ button on their website which is 100% anonymous, and really simple to find/use. Once pressed, the IGDA (or whomever) would come along to the company and ask the company if it’s true. Either:

  1. the company says it is, and they’re not ashamed
  2. the company says it is, and they’re sorry, and here’s how they’re going to address it
  3. the company says it isn’t.

In 3) the IGDA can then ask if it can speak to employees at random for their opinion. The company can only really refuse if they’ve got something to hide. The company won’t be allowed to know who said what, and they’ll have to ask enough people so that the employees can’t be threatened or accused of ‘ratting the company out’. The employees will either:

  1. confirm that there’s no crunch, and the original report was bogus
  2. confirm that there is crunch (and ideally give details), showing that the company is both deliberately crunching, and deliberately lying about it.

In most of those outcomes, they can publicly state the results of their investigations. It doesn’t have to be a big fanfare or singling particular developers out (at least to begin with), just quietly announcing what they discovered when they asked the question.

  • If a company is never reported on, you can take that as a good sign.
  • If a company isn’t crunching its staff, it can be held up as a good example.
  • If a company is crunching its staff and isn’t ashamed, the IGDA can publicise that fact (and discourage potential applicants).
  • If a company is crunching its staff but wishes it weren’t, that can be publicised, and the situation monitored; if they have a plan to fix it, the IGDA could go back in a year or two and see if they’ve made progress, and if so hold them up as an example to others as to how to get out of crunch mode.
  • If a company is crunching its staff but pretending they aren’t, that can be publicised as well, including the fact that their staff say something different, all of which will discourage potential applicants.

Even those at the IGDA who are convinced that the “40 hour week” is some crazed ideal that not everyone agrees with can’t really argue against that, because you can do it neutrally, without stating categorically that crunch is bad. Even if you think crunch can be a good thing, it can be highlighted in the findings. What matters is that the situation be made clear to one and all.

It only relies on the simple fact that any organisation can ask a question of another publicly. The respondent is then put on the spot, either they have to ignore the question, lie, admit it, or deny it. Failure to answer the question is damning enough in itself. An organisation which doesn’t crunch has nothing to fear, an organisation which crunches and doesn’t care (like Team Bondi) won’t mind the question being asked. The only organisations which would be disadvantaged are the ones who are crunching and trying to hide it. In which case simply asking the question is enough to bring it out into the light.

Our real problem is that the press and the IGDA and others aren’t talking about it enough. Not in general terms (‘crunch is bad’), but in specifics (‘the kind of crunch being talked about at Bondi is bad’). If no-one asks the awkward questions until after it’s been so f*(&ed up for years, then it’s only going to continue.

Portal 2 / Scope

Posted in Games, Industry Rants on May 17th, 2011 by MrCranky

I thought I’d add my voice to the rest of the gaming community praising Portal 2, which I finished last week. A great story, which made me laugh out loud at least a dozen times, which is rare in any medium, let alone a game. It’s not without its flaws, but all are minor and do not detract noticeably from the overall experience. It most definitely passed my usual acid test for quality: that I wanted to play it even when I didn’t have any free time, to the point where I was skipping sleep to play it some more.

I loved the original, even though I wouldn’t have bought it were it not tacked onto Half-Life 2: Episode 2. It always struck me as a wonderfully weighted title – just the right length, elegant in its simplicity, and with a level of polish that larger titles just don’t achieve. More than anything though, it was a title that left me wanting more, not because it was too short, but because it was so good. Much like a wonderful novel or film where I get immersed in the universe and characters, the end comes with both a warm glow of satisfaction at the conclusion, and an aching for more. More of the characters, more from the rich universe. It’s a rare creation that brings that level of quality to the observer, and both Portal incarnations have that quality in spades.

I’ve been ranting somewhat about the poor judgement of top-end games development recently. Quality of Life and financial issues are just one facet of a deeper problem: that we’ve been trapped into an arms race of scope. To justify a ‘full-price’ cost, developers feel they have to match or out-do each other. Worlds grow larger and larger, not even bound by memory constraints, since every large game streams their environments off disc. Stories grow more and more epic, and require game-play lengths to match. More characters are wedged in, even though there’s not enough time to get to know them in any great detail. Their voices are provided by more and more famous actors. Cut-scenes get flashier and longer.

The problem is that the underlying mentality to it all is ‘go big, or go home.’ Budgets spiral upwards, or if they don’t, then quality spirals downwards. Both hurt a title’s chances of success. But more quality doesn’t justify a higher price tag to match the increased costs. The players have shown in a wide variety of ways that they’re not prepared to pay any more for games than the already high cost. Second-hand sales and rental mean that the RRP quickly gets turned into the ‘real’ price – far lower. Popular titles drop slower than unpopular ones, so market forces still apply. But as an industry we still delude ourselves that we ‘deserve’ the RRP times the number of units sold.

That’s not the real madness though. The real madness is that despite all our profitability numbers showing the decline, developers and publishers keep on down the same path. They know how much more it costs to increase the scope of the games we make, but they do it anyway. Why? Because they know if they don’t invest enough in titles they flop, because they are competing with other titles on quality. But they don’t know how to turn investment money into quality. Quality is hard. It’s intangible, and you don’t always know it until you see it. So they put the money on things they can understand. More levels, more characters, bigger worlds. They set themselves a benchmark of their competitors, plus some. Because if X was a success, and we have more of everything than X, then we’re as good as X, right?

So when a title like Portal comes along, I regain a bit of hope for our industry. By showing that you can make a massively successful title, not by making it bigger, or more complicated, but by making it good, it’s a bit of ammunition for the decision makers. They can point to Portal and say “it doesn’t need to be big, as long as it’s fun”, or “let’s find a mechanic that works well, and just stick with that”. And maybe we can halt this crazy race to massacre our industry’s profit margins.


Email: info@blackcompanystudios.co.uk
Black Company Studios Limited, 14 Belford Road, Edinburgh, EH4 3BL
Registered in Scotland (SC283017) VAT Reg. No.: 886 4592 64
Last modified: August 14 2014.