Article : Only 30% of games even break even!

[ERP]

You don't ship if you don't have some sort of architectural understanding when your codebase is 2Million+lines. We have more discussions about the semantics of Init and Shutdown than we do how to optimize a particular piece of animation code. Because the former causes more issues.

Game development can be somewhat Ad-hoc at the gameplay level because design fluctuates so violently through a large portion of development, but even there my experience is the "hackiness" is at the bottom not at the top level.

The problem is as much about differing cultures accross large companies as much as anything else, when you have several thousand engineers and probably several hundred senior engineers you're not going to get agreement on even what the definition of a term like resource management is never mind on implementation details.

There is no "right" way to write a game, there are plenty of wrong ways, but if you take two people senior people (with decades of experience a piece) with disparate visions, stick them in a room and tell them to figure it out about 50% of the time it turns into what I like to call "programmer survivor", and you get a bad compromise out the other end.

The next step in the technology unification process is usually aquiring something external and dictating its use top down, this usually causes issues because the imported tech is less well featured than the old internal tech was. It leads to mass "fixing" of the technology accross the teams and usually the loss of the most talented technical people.

There are secondary costs to sharing, if I'm writing a "graphics engine" for one game it's a few thousand lines of code, to generalize that for arbitrary usage it's as much as 10x that, plus it's a significantly more difficult architectural problem. Tools go the same way. The advantage of the specific solution in this case is it's simpler and I personally understand it, so when there is an issue I can quickly isolate it. In the shared tech case this usually degenerates into a debugging nightmare and an agument as to who's code the problem is in.

The other issue in shared tech is misuse of the external interface, programmers make assumptions about what an external interface does, and if those assumptions proove to be wrong, it can lead to extremly subtle difficult to isolate bugs.

Plus the usual nightmare of living libraries, where someone subtley changes the semantics of an interface in a code drop.

Now I'm not suggesting you build everything from scratch for a game, I'm suggesting you look at what's available and make informed decisions, assume any technology you adopt, your going to end up doing a large portion of the maintenance. You make technology decisions based on technology merit for your application.

Our current codebase has a lot of external code in it, most of it was selected for solid technical reasons, but some of it was selected because of internal political pressure.

 

[Shifty Geezer]

Again, the only advantage I see to each studio rolling their own engine is if that it may be easier to meet a deadline.

If that's the only advantage you see, you haven't been paying careful attention! As different folk have said here, one solution doesn't fit all problems, and any that does will do so imperfectly and inefficiently, wasting a lot of resources.

Putting it another way, if UE3 is that great, saves that much money, everyone would be using it, costs would all be below $10 million (according to Epic's PR) and we wouldn't have 70% economic failure of titles! Companies try, evaluate, and decide for and against 3rd party versus in-house engines. Sure, not every decision made in that respect is going to be perfectly considered, rational decision-making, but I wouldn't want to suggest that pretty much every studio out there creating their engine is too dumb to realise that buying in UE3 would work wonders and save them a bundle

 

[obonicus]

You don't ship if you don't have some sort of architectural understanding when your codebase is 2Million+lines. We have more discussions about the semantics of Init and Shutdown than we do how to optimize a particular piece of animation code. Because the former causes more issues.

Naturally, I didn't mean to maintain that there is no architectural work in games, my apologies.

Game development can be somewhat Ad-hoc at the gameplay level because design fluctuates so violently through a large portion of development, but even there my experience is the "hackiness" is at the bottom not at the top level.

And this is probably what I was referring to.

Still, the rest of what you said doesn't seem to be entirely unique to game development. Like you point out, engineers aren't going to agree on a single architecture that easily, so it has to be enforced from above, unfortunately. And software engineering is heavily driven by 'best practices'; there usually is more than one way to do something correctly, but usually only one is chosen, and others have to conform. Software houses do agree on a single architecture, they do agree on a standard set of tools to use. Very few developers would have the courage to roll up their RDBMS or web server. In part because these are difficult endeavors, in part because because targeting known platforms makes staffing easier. And that's not to talk about the lack of standards in game development; probably due to the large number of engines/toolsets in existence, there's just nothing to standardize on.

These are all things that other industries have had to deal with one time or another. Gaming has its unique aspects, but it's not the only industry where you have to deliver (usually) real-time performance on (initially) unfamiliar hardware with (hopefully) 0 errors (though it may be the only one where you sell your product at $60). I understand the hurdles as you point them out, but they do seem in great part to be a matter of culture, rather than something inherent to the process of game development (which of course makes them very very difficult to overcome).

I mean, maybe a full engine isn't a good idea, but again, if in EA's case we have the city-states being completely independent (please correct me if I'm wrong) it does seem like they paid multiple times for the same thing. How is that a good thing? And, if what people on this forum have to say on the subject is true, what they paid for multiple times wasn't cheap.

 

[Carl B]

I mean, maybe a full engine isn't a good idea, but again, if in EA's case we have the city-states being completely independent (please correct me if I'm wrong) it does seem like they paid multiple times for the same thing. How is that a good thing? And, if what people on this forum have to say on the subject is true, what they paid for multiple times wasn't cheap.

Think of it instead like this; the technical talent that created those engines, and the engines themselves, are part of what EA paid for in the first place. What you are suggesting is tossing out those assets and starting fresh on a corporate level. Now, do you think that's going to be a net positive or a net negative to both the efficiency of the game development and the morale of the technical teams involved?

Should EA succeed in taking over Take-Two/Rockstar for example, in your model that entire 'fiefdom' is then to be migrated over to the EA "monolith" engine in the middle of current game development. I mean, that sounds like it would be a bad idea to you, right?

 

[obonicus]

If that's the only advantage you see, you haven't been paying careful attention! As different folk have said here, one solution doesn't fit all problems, and any that does will do so imperfectly and inefficiently, wasting a lot of resources.

Okay, you explain to me how, exactly, reinventing the wheel 2+ times SAVES you money. Software development is heavily driven by 'best practices'. Why is gaming different? Because we all get software that's custom-crafted to our enjoyment, for the best performance? At $60, we're certainly not paying for that. We're talking about the health of the games industry, right? This isn't a consumer thread, AFAICT. This is usually not the stance I take, but honestly, I'd rather see a lot of uglier games that perform only acceptably across a broad spectrum of genres and possibilities than a handful of proven franchises rehashed over and over because they're safe, polished to perfection. (Just see the latest Activision news, on Radical.) I know, anathema on B3D. But really, this situation doesn't seem like it can be kept up.

Putting it another way, if UE3 is that great, saves that much money, everyone would be using it, costs would all be below $10 million (according to Epic's PR) and we wouldn't have 70% economic failure of titles! Companies try, evaluate, and decide for and against 3rd party versus in-house engines. Sure, not every decision made in that respect is going to be perfectly considered, rational decision-making, but I wouldn't want to suggest that pretty much every studio out there creating their engine is too dumb to realise that buying in UE3 would work wonders and save them a bundle

Hey, I'm not saying UE3 is great. I don't know their pricing structure, I don't know its quality, I don't know much about it at all. I'm saying that no, reinventing the wheel again and again is NOT the best solution because, even if individual quality goes up, we're seeing diversity go down. How many new IPs have we seen this gen? How many sequels? We've had more than one dev comment on this thread that there are games that just never see the light of day.

 

[Shifty Geezer]

Okay, you explain to me how, exactly, reinventing the wheel 2+ times SAVES you money.

See my own personal example. Creating a universal UI engine would have cost more than the project warranted. Creating a 'disposable' engine was more economical. And ERP's point, large engines often add a whole load of redundant stuff to bog your game down with. Also I repeat, sometimes you have to reinvent the wheel. Modern cars would not be possible if we had stopped with the wooden cart wheel. The added expense is necessary to push forwards what is possible. We could settle on a finite universal engine and save a bundle, but all the games produced on it would be capped at yesteryear's technology. Then the moment someone came out with a new, custom-built engine, they'd blow away everything we're used to, and suddenly everyone would want to follow suit. Why aren't Guerilla buying in an engine to create Killzone 2? Why is Media Molecule writing their own engine for LBP's fancy lighting and 2D fluids based particle effects driven game? Because they have to to do what they want.

How many new IPs have we seen this gen? How many sequels? We've had more than one dev comment on this thread that there are games that just never see the light of day.

This isn't unique to this industry or this generation. And I think it was Peter Molyneux recently saying gaming diversity is better now than it's ever been. I'm not sure I agree with him, but things aren't that bad. Do you not remember the millions of platformer clones on 8 bit?! And the fighter clones on 16 bit?! Every gen has it's core game experiences, as all creative industries follow the pattern of 'try stuff until someone gets a success, copy them and form a trend'. The gaming industry is no worse off than Hollywood, literature, music etc. And I dare say all are having difficulties, but reducing costs won't save things. The market will adapt and find its successes. Halo3 raked in crazy amounts of dough by following a pattern. LBP looks set to make loads of wonga with a team of less than 40, maybe nearer 30. That's not gonna cost the earth to make, but may well see Snoy spend a bundle on marketing which counts towards the costs. Project Offset was started by a team of three. MGS4 cost an arm and a leg and made it back with knobs on. Countless cheap products the names of which we've never heard of have been released and flunked. Braid was scraped together by an indie dev and it looks like that one will be a success. Who knows how many mobile games have failed. I don't see anything is dependent on reducing costs. Mkaing the right product for the budget is what leads to success, and knowing what the right product is is a complete mystery, because us consumers are unpredictable!

 

[obonicus]

Think of it instead like this; the technical talent that created those engines, and the engines themselves, are part of what EA paid for in the first place. What you are suggesting is tossing out those assets and starting fresh on a corporate level. Now, do you think that's going to be a net positive or a net negative to both the efficiency of the game development and the morale of the technical teams involved?

Again, this stuff does happen. The game industry isn't a unique snowflake, is it? Throwing work already out without analysis is dumb: but say, EA bought Criterion and with it, Renderware. This was what, 4-5 years ago? Was it the wisest move for DICE to roll their own engine, cost-wise? In other industries, when one company buys another, and they have similar products one of the products ends up phased out.

As for morale... well, alone, no, it'd probably hurt morale. If you can (by reducing expectations as well) reduce game cost, maybe you'd have developers sleeping more soundly at night knowing that they don't have to sell x million to be considered profitable.

Should EA succeed in taking over Take-Two/Rockstar for example, in your model that entire 'fiefdom' is then to be migrated over to the EA "monolith" engine in the middle of current game development. I mean, that sounds like it would be a bad idea to you, right?

I've been mulling this over myself, actually. And indeed, it's the biggest hurdle, as I see it. Because even legacy code has value, and because of deadlines you can't very well just wait for the common tech to be ready. And then you're stuck with a semi-next-gen engine ready, which might just be easier to prop up for next-gen than using something new. Of course, the problem comes when two, three, four different studios do the same. What's more cost-effective then?

But I've been in companies just after mergers; migrating systems ain't pretty, but it happens. It has to, because it's often too expensive to support more than one system. So no, you don't make the games in development shift, unless maybe they're very very early in development.

 

[ERP]

Still, the rest of what you said doesn't seem to be entirely unique to game development. Like you point out, engineers aren't going to agree on a single architecture that easily, so it has to be enforced from above, unfortunately. And software engineering is heavily driven by 'best practices'; there usually is more than one way to do something correctly, but usually only one is chosen, and others have to conform. Software houses do agree on a single architecture, they do agree on a standard set of tools to use. Very few developers would have the courage to roll up their RDBMS or web server. In part because these are difficult endeavors, in part because because targeting known platforms makes staffing easier. And that's not to talk about the lack of standards in game development; probably due to the large number of engines/toolsets in existence, there's just nothing to standardize on.

These are all things that other industries have had to deal with one time or another. Gaming has its unique aspects, but it's not the only industry where you have to deliver (usually) real-time performance on (initially) unfamiliar hardware with (hopefully) 0 errors (though it may be the only one where you sell your product at $60). I understand the hurdles as you point them out, but they do seem in great part to be a matter of culture, rather than something inherent to the process of game development (which of course makes them very very difficult to overcome).

I mean, maybe a full engine isn't a good idea, but again, if in EA's case we have the city-states being completely independent (please correct me if I'm wrong) it does seem like they paid multiple times for the same thing. How is that a good thing? And, if what people on this forum have to say on the subject is true, what they paid for multiple times wasn't cheap.

The last paragraph isn't actualy accurate, the structure is extremely complicated, with independence/integration at various levels. EA also has central technology groups, and has had them as far back as PS1 development.

It's not a unique problem, but the problem is ill defined, "game engine" doesn't mean anything, even "graphics engine" is meaningless, even something as trivial as "Resource management" is ill defined. Games tend to have radically different requirements across the board, this is especially true of the lower level components like resource management which affect the architecture of the layered components.

The rate of fluctuation of the design (which often affect core requirements) is significantly larger than any other field I've ever encountered. That coupled with constraints on performance, and the reliance on a small group of very talented people (even on very large teams) make broad sharing difficult at best.

Perhaps the primary difference is that most of the really talented people in games don't do it for the money, they do it because it's something they enjoy doing, and they can get another job some where else tomorrow.

As a company you could decide to standardise on say Unreal engine, you could accept all the constraints of the technology and just assume they are not fixable, and build good games within those constraints. It's more or less what the successful RenderWare licensees did in the PS2 era.

I honestly wish I could share some of the central tech sharing stories, but it would be unproffesional.

I've certainly adopted technology from various locations over the years that in hindsight I could have spent less time writing than maintaining long enough to ship.

And FWIW everyone I have ever talked to about using external game engines (and my own experience) is that they do not save engineering time or effort. They do allow you to start developing gameplay earlier in the cycle (which is a huge win), but in the end they are as expensive or more expensive than developing internally.

 

[Carl B]

But I've been in companies just after mergers; migrating systems ain't pretty, but it happens. It has to, because it's often too expensive to support more than one system. So no, you don't make the games in development shift, unless maybe they're very very early in development.

That's because 'support' is something that is top-down in those companies, normally traversing CRM, customer databases, and enterprise-wide integrated systems. In the game development model, each dev house is fully capable of internal support, because their product exists in a relative void.

The model you are suggesting already exists - Unreal Engine 3 *is* the uber-engine/tool-set of this generation. Yet quite plainly it is no panacea for developers, because they need to finesse it to their own needs regardless.

The suggestion of a singular engine at EA is no different than suggesting everyone there adopt UE3, save for the licensing cost differential, because you are still creating a system in which a general base will need to be adjusted/altered/integrated into the individual teams projects. The advantage of straight internal development and tech-team involvement, is that there's little 'bringing up to speed' or lag time when someone else on the team starts having problems with a tool or something else. Bill the artist can walk down the hall to Jake the tools guy and say, hey, this isn't working, and this is what I need. Jake is already familiar with Bill's project, created the tools, and knows exactly what needs to be done to get Bill what he needs.

There are advantages to having something ready-made for you, but either way you are asking for members of the dev house to become experts in an engine; it's either their own, the one you've told them to become familiar with, or a combination of the two.

 

[obonicus]

See my own personal example. Creating a universal UI engine would have cost more than the project warranted. Creating a 'disposable' engine was more economical. And ERP's point, large engines often add a whole load of redundant stuff to bog your game down with. Also I repeat, sometimes you have to reinvent the wheel. Modern cars would not be possible if we had stopped with the wooden cart wheel.

True enough, to a point. But your metaphor fails. Cars share wheel-bases; in fact, they share them across industries, even. And you can put any brand tire on that wheel, as well. I'm not saying that 3d engines should have stopped at Quake. I'm questioning the need to have 4+ different engines within a single company for a given generation.

The added expense is necessary to push forwards what is possible. We could settle on a finite universal engine and save a bundle, but all the games produced on it would be capped at yesteryear's technology. Then the moment someone came out with a new, custom-built engine, they'd blow away everything we're used to, and suddenly everyone would want to follow suit.

Sure. Except at $xx million, they'd have to sell millions of copies and still might not break even, while team B, working on a much more reasonable game could actually make money on a game that sells 100k.

Why aren't Guerilla buying in an engine to create Killzone 2? Why is Media Molecule writing their own engine for LBP's fancy lighting and 2D fluids based particle effects driven game? Because they have to to do what they want.

First-party is always a bit different; Guerilla does what it does because it's been insanely funded. Numbers float around claiming it's cost $70 million so far. It only happens because it interests Sony to show off their platform to the greatest extent, to draw people to it. Why should EA do the same? Dev-houses want to make fancy tech. It's up to the pubs to fund them.

This isn't unique to this industry or this generation. And I think it was Peter Molyneux recently saying gaming diversity is better now than it's ever been.

Except... I'm seeing fewer interesting games, even among the upcoming titles. Molyneux says a lot of things. Activision is cancelling a great deal of its new IPs; EA has a few, bless their hearts, Sega has quite a few (though they're losing their pants too, so let's take their judgment with a grain of salt). I don't even know what Ubi has that's not a sequel. The biggest games this gen have had '4'(or IV) in their titles. Maybe I'm crazy, maybe I'm missing all the creativity, but the coolest titles so far this year have been on the portables, where the barrier to entry is much lower.

I'm not sure I agree with him, but things aren't that bad. Do you not remember the millions of platformer clones on 8 bit?! And the fighter clones on 16 bit?! Every gen has it's core game experiences, as all creative industries follow the pattern of 'try stuff until someone gets a success, copy them and form a trend'. The gaming industry is no worse off than Hollywood, literature, music etc. And I dare say all are having difficulties, but reducing costs won't save things.

True enough; but you do realize that Sturgeon's law applies always, whether it be to a thousand or a million, right? With earlier platforms, most of the games were crap, but the gems did stand out. I'm not a deranged GAFer to think that that was the golden age of gaming. But again, look at what some of the devs had said in this thread: for AAA titles the ratio is more likely in the single digits, rather than 30%. The release of good games is much more stark when compared with last-gen. I was a PC gamer then, though my housemate was a console gamer. Things seemed better back then (though maybe I'm just getting old and bitter).

The market will adapt and find its successes. Halo3 raked in crazy amounts of dough by following a pattern. LBP looks set to make loads of wonga with a team of less than 40, maybe nearer 30. That's not gonna cost the earth to make, but may well see Snoy spend a bundle on marketing which counts towards the costs. Project Offset was started by a team of three. MGS4 cost an arm and a leg and made it back with knobs on. Countless cheap products the names of which we've never heard of have been released and flunked. Braid was scraped together by an indie dev and it looks like that one will be a success. Who knows how many mobile games have failed. I don't see anything is dependent on reducing costs. Mkaing the right product for the budget is what leads to success, and knowing what the right product is is a complete mystery, because us consumers are unpredictable!

But aren't you looking at the outliers? The curve, as the thread itself indicates is much more bleak. And actually, it may be best to leave LBP out of this: no one knows how it'd do, no one knows how much it cost (though maybe not that much) and Sony is backing it as a system seller so even if it doesn't make a profit but it expands the PS3's userbase significantly it'd be a success. Because the other two huge hits are both sequels. Braid is a different story. It MAY be a success; at 50k sales it's not one yet.

I don't know; the gaming market has grown. But is it enough, along with a $20 price increase to justify the increased production costs? From where I'm sitting the situation doesn't seem positive; Activision is doing exactly what makes sense to me, as much as I hate to admit it. I do think our expectations are high for what we're paying, too.

 

[obonicus]

That's because 'support' is something that is top-down in those companies, normally traversing CRM, customer databases, and enterprise-wide integrated systems. In the game development model, each dev house is fully capable of internal support, because their product exists in a relative void.

Right, so migration would be easier with dev-houses. I think you're agreeing with me?

The model you are suggesting already exists - Unreal Engine 3 *is* the uber-engine/tool-set of this generation. Yet quite plainly it is no panacea for developers, because they need to finesse it to their own needs regardless.

Right, which is why I'm not referring to UE3. It has its problems; Epic is not a services company and the support they give seems inadequate. Let's run with the premise that UE3 is unsuitable and that EA-engine does have some degree of support. Otherwise, you're right.

The suggestion of a singular engine at EA is no different than suggesting everyone there adopt UE3, save for the licensing cost differential, because you are still creating a system in which a general base will need to be adjusted/altered/integrated into the individual teams projects. The advantage of straight internal development and tech-team involvement, is that there's little 'bringing up to speed' or lag time when someone else on the team starts having problems with a tool or something else. Bill the artist can walk down the hall to Jake the tools guy and say, hey, this isn't working, and this is what I need. Jake is already familiar with Bill's project, created the tools, and knows exactly what needs to be done to get Bill what he needs.

On the other hand, the advantage to a single engine is that because it's shared, it's possible that certain technical hurdles have already been overcome. If Title A needed to figure out the PS3, and Title A shipped having figured it out, you can use that to your advantage for Title B. And vice-versa. Otherwise, what you mention is what support teams and training are for. Did I mention that other advantage? With a common toolset, it's far more cost-effective to actually train people to use the tools.

There are advantages to having something ready-made for you, but either way you are asking for members of the dev house to become experts in an engine; it's either their own, the one you've told them to become familiar with, or a combination of the two.

Right; again, this is my point. Being an expert at a common engine means your expertise is far more useful elsewhere. Or you can hire outside help and can expect a certain degree of familiarity with the toolset. Again, please, what's so unique about the gaming industry that it can't work towards more standardized tools and skillsets?

 

[obonicus]

The rate of fluctuation of the design (which often affect core requirements) is significantly larger than any other field I've ever encountered. That coupled with constraints on performance, and the reliance on a small group of very talented people (even on very large teams) make broad sharing difficult at best.

This is true. Still; I'm still wondering how much of it is truly irreconcilable.

Perhaps the primary difference is that most of the really talented people in games don't do it for the money, they do it because it's something they enjoy doing, and they can get another job some where else tomorrow.

I think this is the crux of it; it might actually be endemic to the problem, though. Word of mouth says that game development doesn't pay that well, especially not for the work they're expected to do. It's sexy (for a geek) work, though, so morale seems far more important. I actually think QoL could be improved by bringing game development closer to regular software development, though, but that's just my gut feeling and far too broad a statement.

Thanks for your responses, and of course I understand that you can't share more.

 

[Carl B]

Right, so migration would be easier with dev-houses. I think you're agreeing with me?

Yes, it would be easier than on the enterprise level; it would also yield less. In fact, the case being made repeatedly here is that the yields can be negative.

What are the efficiencies you're seeing under your model?

Right, which is why I'm not referring to UE3. It has its problems; Epic is not a services company and the support they give seems inadequate. Let's run with the premise that UE3 is unsuitable and that EA-engine does have some degree of support. Otherwise, you're right.

What problems does UE3 have in your mind that an EA-monolithic engine - or any other engine - wouldn't have? Epic is indeed a services company by the way, because the Unreal Engine tools and associated support comprise a massive part of their business.

On the other hand, the advantage to a single engine is that because it's shared, it's possible that certain technical hurdles have already been overcome. If Title A needed to figure out the PS3, and Title A shipped having figured it out, you can use that to your advantage for Title B. And vice-versa. Otherwise, what you mention is what support teams and training are for. Did I mention that other advantage? With a common toolset, it's far more cost-effective to actually train people to use the tools.

Yes, the users of the tools benefit in terms of proficiency/transportability. This is the biggest known advantage of using externally developed tools, and one of the big draws of UE3... or any prolific middleware. But as many difficulties crop up at the technical level as development progresses, it's not all roses.

Right; again, this is my point. Being an expert at a common engine means your expertise is far more useful elsewhere. Or you can hire outside help and can expect a certain degree of familiarity with the toolset. Again, please, what's so unique about the gaming industry that it can't work towards more standardized tools and skillsets?

The problem is I think your sense of scope/scale is off. There are standardized tools and skillsets, but let's take your example out to its logical extreme and say that there is only one "engine" in the world, and all games are built around it. Do you see this as a net economic benefit for gaming companies, vs were there to be greater diversity and thus a broader range of titles in terms of 'feel'? You brought up car platforms earlier in the thread, and that works well here. Yes, multiple models are built on the same platform. This is also the case in the games industry, and at EA. Now, would you have GM build all their cars on the same platform? You probably wouldn't, and neither should EA. Different games have different needs, and there are advantages to having those teams work with an engine more finely specialized towards their needs.

 

[Shifty Geezer]

I'm questioning the need to have 4+ different engines within a single company for a given generation.

because one engine wasn't able to do all the different games they're creating with the different features . If the engine they used on Game one would work for Game 2 without any changes it'd be used! The reason for reworking it, or writing one from the ground up (as ERP points out, what counts as an engine is basically immeasurable), is to accommodate a change from the original spec.

Sure. Except at $xx million, they'd have to sell millions of copies and still might not break even, while team B, working on a much more reasonable game could actually make money on a game that sells 100k.

But a game that cost little enough that it'd turn a profit at 100k would be a totally different sort of game. Such a game could be created on a download service. Yet the financial returns on Live! Arcade for example are clearly not stellar. Likewise there are millions of mobiles out there, but you can't guarantee a success. Whereas Gears and Halo3 have made huge returns. There are no safe bets, it's a gamble no matter how much you spend. The upside to gambling with big-bucks is the returns tend to be better, though of course a clever/lucky hit like Brain Training is the Holy Grail.

Maybe I'm crazy, maybe I'm missing all the creativity, but the coolest titles so far this year have been on the portables, where the barrier to entry is much lower.

I think this is too subjective for this thread. Tastes vary wildly. Unless there's evidence that the financial failure rate on mobiles is much lower than this 70% figure, diversity of title doesn't really impact the decision making processes of the publishers.

But again, look at what some of the devs had said in this thread: for AAA titles the ratio is more likely in the single digits, rather than 30%.[q/uote]Again, quality of games is too subjective for discussion here. Plus we're all guessing at figures, even the 30%.

But aren't you looking at the outliers? The curve, as the thread itself indicates is much more bleak.

It's only bleak because we've heard about it and it sounds rough. If it's been that way for 20 years, it's not bleak but the norm! And if in other creative industries the economic failure rate is 90% of all products (film. books and musicians) then suddenly gaming with it's 70% failure rate is a huge success story!

Braid is a different story. It MAY be a success; at 50k sales it's not one yet.

Mr. Blow said he's well on his way to profitability.

I don't know; the gaming market has grown. But is it enough, along with a $20 price increase to justify the increased production costs?

If all the publishers lose money, no. If they report record profits, yes.

 

[dobwal]

But I've been in companies just after mergers; migrating systems ain't pretty, but it happens. It has to, because it's often too expensive to support more than one system. So no, you don't make the games in development shift, unless maybe they're very very early in development.

Most companies don't operate like giant game publishers. Maintaining a common system makes sense for traditional companies because they are more dependent on interoperability between individual departments. Giant pubs aren't as dependent on interoperability because individual dev houses don't depend on a high level of infomation exchange to complete their project. Individual devs operate rather autonomously from other devs with EA.

Yes, you can save money by sharing assets but forcing common technology and maintaining homogenity of that technology would only be useful if EA's structure became more centralized almost assembly line like. Where content creation, coding and testing weren't performed by individual teams but by large centralized departments that serviced numerous projects at a time.

Most of the redunancy that exist within EA isn't the technology its the manpower. However, with that scenario, I see better profits but a less than ideal enviroment for producing great games like the difference between a home cook meal versus a meal served at a franchised restaurant.

 

[obonicus]

The rate of fluctuation of the design (which often affect core requirements) is significantly larger than any other field I've ever encountered. That coupled with constraints on performance, and the reliance on a small group of very talented people (even on very large teams) make broad sharing difficult at best.

Sorry for returning to you, but I had to comment on this: is this true on all levels? Once you have, say, the renderer done, do you really have to return to it again and again because of shifts in design?

Yes, it would be easier than on the enterprise level; it would also yield less. In fact, the case being made repeatedly here is that the yields can be negative.

Certainly they can! That's why analysis is important, but this whole argument came up because Shifty was disputing the notion that it is wasteful to have 4 different studios all spend money trying to, say, figure out the PS3! No one's quite addressed that; ERP addressed what's different about game development as a discipline in software engineering, but nothing about it makes the problem of game design non-factorable.

What problems does UE3 have in your mind that an EA-monolithic engine - or any other engine - wouldn't have? Epic is indeed a services company by the way, because the Unreal Engine tools and associated support comprise a massive part of their business.

The problem with using UE3 as an example is that we have first-hand accounts that UE3 ain't all that. And the problem with THAT is that by using UE3 as the only possible example for a unified toolset, it becomes a basic assumption that 'unified toolsets ain't all that'. And I'm disputing that premise; because Epic can't do it, doesn't mean no one can.

And yes, UE3 comprises a massive part of their business; I was being facetious when I said they're not a service company. I said that because it's hard to take them seriously as a 'service' company when they're unable to provide proper support. Maybe it just speaks to the desperate need in the industry for a set of quality tools. Good news for Mr. Carmack.

Yes, the users of the tools benefit in terms of proficiency/transportability. This is the biggest known advantage of using externally developed tools, and one of the big draws of UE3... or any prolific middleware. But as many difficulties crop up at the technical level as development progresses, it's not all roses.

No, certainly not. No middleware, no toolset is all roses, but then probably engine development isn't either. No one's suggesting a panacea.

The problem is I think your sense of scope/scale is off. There are standardized tools and skillsets, but let's take your example out to its logical extreme and say that there is only one "engine" in the world, and all games are built around it. Do you see this as a net economic benefit for gaming companies, vs were there to be greater diversity and thus a broader range of titles in terms of 'feel'? You brought up car platforms earlier in the thread, and that works well here. Yes, multiple models are built on the same platform. This is also the case in the games industry, and at EA. Now, would you have GM build all their cars on the same platform? You probably wouldn't, and neither should EA. Different games have different needs, and there are advantages to having those teams work with an engine more finely specialized towards their needs.

Your car analogy isn't great. GM builds cars on several different platforms. Are these platforms developed independently? They don't share tech and research?

And hold on: does engine influence feel, or doesn't it? I thought, for instance, that UE3 titles didn't all HAVE to feel alike. This isn't a new argument. Otherwise... it depends? How good is this engine, how much variance does it allow? There's nothing inherently wrong with all games being built on a single engine, no, if the engine can handle it. Is there, other than some unsubstantiated and unsubstantial 'likeness of feel'?

because one engine wasn't able to do all the different games they're creating with the different features . If the engine they used on Game one would work for Game 2 without any changes it'd be used! The reason for reworking it, or writing one from the ground up (as ERP points out, what counts as an engine is basically immeasurable), is to accommodate a change from the original spec.

Right, but here you're saying 'they're different because they're different'. And I'm asking: is this true? These games can't be factored into common, reusable factors, do they all need their own renderers? Are they really that diverse? (We know this isn't entirely true: as ERP points out, they do share tech to a certain extent.)
Because, though I hate to go back to UE3, referring to the 'do engines dictate how a game looks' thread in the tech forum there were several strong arguments (including yours) that said that no, you can essentially build any sort of game on top of any sort of engine. Which is correct?

But a game that cost little enough that it'd turn a profit at 100k would be a totally different sort of game. Such a game could be created on a download service. Yet the financial returns on Live! Arcade for example are clearly not stellar. Likewise there are millions of mobiles out there, but you can't guarantee a success. Whereas Gears and Halo3 have made huge returns. There are no safe bets, it's a gamble no matter how much you spend. The upside to gambling with big-bucks is the returns tend to be better, though of course a clever/lucky hit like Brain Training is the Holy Grail.

Look at the Japanese market. Their focus is on portables, the Wii and PS2, and there, games that get less than 500k on those platforms often are successful enough to get a sequel (some even come Stateside!). How many games were million-sellers last-gen? How many games got sequels? It seems like we're worse-off, in terms of that ratio, but maybe it's just an impression.

 

[ERP]

Sorry for returning to you, but I had to comment on this: is this true on all levels? Once you have, say, the renderer done, do you really have to return to it again and again because of shifts in design?

The short version is that IME nothing is done until you ship.
The somewhat longer version is it depends how you define renderer, you'll likely be doing tool chan changes all the way through deveopment, and optimisations very late into development, but the interface won't change much.

On my current game we radically changed the way foliage was rendered with siginificant impact on what we could and couldn't do from a gameplay standpoint several times including very late in development.

Gameplay requirements coupled with performance requirements often require very specific implementations all the way down to the guts of the renderer. For the most part you try and identify these up front and solve the problems early. However sometimes seemingly subtle changes can have very significant low level ramifications.

 

[Carl B]

Certainly they can! That's why analysis is important, but this whole argument came up because Shifty was disputing the notion that it is wasteful to have 4 different studios all spend money trying to, say, figure out the PS3! No one's quite addressed that; ERP addressed what's different about game development as a discipline in software engineering, but nothing about it makes the problem of game design non-factorable.

The problem with using UE3 as an example is that we have first-hand accounts that UE3 ain't all that. And the problem with THAT is that by using UE3 as the only possible example for a unified toolset, it becomes a basic assumption that 'unified toolsets ain't all that'. And I'm disputing that premise; because Epic can't do it, doesn't mean no one can.

And yes, UE3 comprises a massive part of their business; I was being facetious when I said they're not a service company. I said that because it's hard to take them seriously as a 'service' company when they're unable to provide proper support. Maybe it just speaks to the desperate need in the industry for a set of quality tools. Good news for Mr. Carmack.

No, certainly not. No middleware, no toolset is all roses, but then probably engine development isn't either. No one's suggesting a panacea.

Your car analogy isn't great. GM builds cars on several different platforms. Are these platforms developed independently? They don't share tech and research?

And hold on: does engine influence feel, or doesn't it? I thought, for instance, that UE3 titles didn't all HAVE to feel alike. This isn't a new argument. Otherwise... it depends? How good is this engine, how much variance does it allow? There's nothing inherently wrong with all games being built on a single engine, no, if the engine can handle it. Is there, other than some unsubstantiated and unsubstantial 'likeness of feel'?

Obonicus I think honestly your classification for engines as they relate to redundancy here may be overly broad. For example when you're saying four different studios trying to figure out the PS3... let's remember that though the engines themselves may be 'unique' so to speak, they are leveraging tool/practice advances made elsewhere in the chain. For example ERP referenced EA's internal technology teams. These are the guys 'figuring out' PS3 in the broad sense, and making their findings and suggestions available to the individual studios. So there is a centralized effort in terms of the 'tough nuts' and such. Conversely, when individual studios within the organization make a noteworthy advance, that can in turn be passed up the chain and made available to all other studios.

Sony's core development teams/partners for example share a lot of their findings/advances with one another - Naughty Dog, Guerilla, and Insomniac are all prominent in advancing code base, tools, and best practices. Yet each certainly has their own engine technology, despite drawing from each other. Naughty Dog likes Sony's SPURS - Insomniac doesn't; a greater pool of 'resources' is created by the combined efforts of multiple studios, but directions taken and technology decisions are unique. There is no single 'best' solution, which is something that I think you may be hopeful for given your cynicism towards UE3.

And by that I mean, you seem to think that UE3's not a good example of a "monolithic" engine/tool paradigm because people are saying that it's not all that great. But they would be saying that about any engine. What good would an engine that places a heavy emphasis on enabling destructible environments and massive particle effects be, for say the average sports title? There are a different set of weighted needs there. If you are saying that the monolithic model can work, but we shouldn't consider UE3 as the exemplar because people are saying it's not "all that," well consider that those same people are saying that an umbrella engine is just not the answer period.

As for the "feel" of UE3, I think again it's a point of clarification. Yes, UE3 lends itself to a certain 'feel;' but when I use the word I'm not alluding to the whole "plastic-y FPS" nonsense of fanboy deliberation months and years past, but to a certain set of supported features that more strongly support certain gameplay elements out of the box than others. Change the word 'feel' to 'path' and that's probably a closer match to my intended meaning. And the more you deviate from the default path, the more you have to wonder whether an internal effort drawing from external offerings might not be better than an external solution re-worked to fit an internal need.

Ending on the car analogy... first of all it was your analogy.

But yes, "engines" relate directly to car "platforms" IMO. EA uses a certain engine arc for their core sports titles, their individual studios at times have internally grown engines, some of their studios use UE3... these are different platforms for different product ranges. When you are talking about the base technology that goes into all platforms, for me that reflects lower-level R&D, such as that done by the R&D technology teams at EA, such as that done by Sony's R&D teams, such as that done at MS wrt to their compilers, and such as that done internally at forward-thinking studios. The effort is already leveraged towards helping studios/developers get a leg up in areas where there might otherwise be redundancy.

 

[obonicus]

Obonicus I think honestly your classification for engines as they relate to redundancy here may be overly broad. For example when you're saying four different studios trying to figure out the PS3... let's remember that though the engines themselves may be 'unique' so to speak, they are leveraging tool/practice advances made elsewhere in the chain. For example ERP referenced EA's internal technology teams. These are the guys 'figuring out' PS3 in the broad sense, and making their findings and suggestions available to the individual studios. So there is a centralized effort in terms of the 'tough nuts' and such. Conversely, when individual studios within the organization make a noteworthy advance, that can in turn be passed up the chain and made available to all other studios.

It was just an example; I have no idea of WHAT sort of work was done more than once, but with several difference engines, undoubtedly some amount of work was done more than once. This is clear, no? This is the crux of your argument, isn't it, that this sort of rework is beneficial? And that's what I have a problem with. I don't see how it can be, not for EA (or insert your third-party here).

Sony's core development teams/partners for example share a lot of their findings/advances with one another - Naughty Dog, Guerilla, and Insomniac are all prominent in advancing code base, tools, and best practices. Yet each certainly has their own engine technology, despite drawing from each other. Naughty Dog likes Sony's SPURS - Insomniac doesn't; a greater pool of 'resources' is created by the combined efforts of multiple studios, but directions taken and technology decisions are unique. There is no single 'best' solution, which is something that I think you may be hopeful for given your cynicism towards UE3.

Again, Sony's a different beast, as are all first-parties. Sony (allegedly) spends 70 million on a sequel to a game that wasn't even a big hit (or very good) to begin with -- I don't think anyone else not a first-party would or should do that. Sony needs to convince people that the PS3 is superior to the 360. So it's hard to discuss what's best for Sony under these circumstances, and it's best not to even try.

And by that I mean, you seem to think that UE3's not a good example of a "monolithic" engine/tool paradigm because people are saying that it's not all that great. But they would be saying that about any engine. What good would an engine that places a heavy emphasis on enabling destructible environments and massive particle effects be, for say the average sports title? There are a different set of weighted needs there. If you are saying that the monolithic model can work, but we shouldn't consider UE3 as the exemplar because people are saying it's not "all that," well consider that those same people are saying that an umbrella engine is just not the answer period.

The problem with using UE3 as an example is that, as posted in this thread (see NavNucST3's hypothetical example) there are problems with the engine that aren't exactly technical. If UE3's support is less than stellar in part because Epic is a game studio itself, explain to me how this is an inherent quality of this sort of tool? This is core to my argument, and I don't think you've understood. You're arguing on single examples and I'm saying that rather than representing the whole, what these may represent is just poor choices.

And as to these toolsets and libraries having more features than you need, again, why isn't this an architectural problem, rather than an inherent problem with the concept of shared libraries/tools?

And to clarify, I'm not arguing for a monolithic engine, but for R&D/core development work to be pooled, rather than repeated across different studios, especially within a single publisher. Code bases are just increasing; other disciplines learned the hard way about the need to simplify and consolidate, and I can't see any reason that gaming would be different.

As for the "feel" of UE3, I think again it's a point of clarification. Yes, UE3 lends itself to a certain 'feel;' but when I use the word I'm not alluding to the whole "plastic-y FPS" nonsense of fanboy deliberation months and years past, but to a certain set of supported features that more strongly support certain gameplay elements out of the box than others. Change the word 'feel' to 'path' and that's probably a closer match to my intended meaning. And the more you deviate from the default path, the more you have to wonder whether an internal effort drawing from external offerings might not be better than an external solution re-worked to fit an internal need.

As I said to Shifty, I think the game industry can afford to have games with the same engine, even a similar feel. I think it could only benefit by having cheaper software because I don't think the current model is sustainable. I don't think we're paying enough for the quality of software we're getting (most of you think I'm crazy, I imagine).

Ending on the car analogy... first of all it was your analogy.

Shifty's, actually. I just ran with it.

But yes, "engines" relate directly to car "platforms" IMO. EA uses a certain engine arc for their core sports titles, their individual studios at times have internally grown engines, some of their studios use UE3... these are different platforms for different product ranges. When you are talking about the base technology that goes into all platforms, for me that reflects lower-level R&D, such as that done by the R&D technology teams at EA, such as that done by Sony's R&D teams, such as that done at MS wrt to their compilers, and such as that done internally at forward-thinking studios. The effort is already leveraged towards helping studios/developers get a leg up in areas where there might otherwise be redundancy.

But is it sufficient? Sun provided the Java runtime and compiler, and by itself this simplified things a lot. There's been a lot of library work done since, because it wasn't enough.

 

[Carl B]

The problem with using UE3 as an example is that, as posted in this thread (see NavNucST3's hypothetical example) there are problems with the engine that aren't exactly technical. If UE3's support is less than stellar in part because Epic is a game studio itself, explain to me how this is an inherent quality of this sort of tool? This is core to my argument, and I don't think you've understood. You're arguing on single examples and I'm saying that rather than representing the whole, what these may represent is just poor choices.

There are two issues with UE3 in that sense. One, it doesn't mesh well with all (or even most) projects right off the bat, and two when problems arise there is a protracted process of dealing with Epic to get support. The support teams at Epic are dedicated to this, however, so their being a game company has nothing to do with it. They emphasize support that reflects their internal project(s) at the time, as this is what they are generally focused on. But with an internal monolith engine at EA, no matter the improvements in support, you will still introduce an inherent support latency into the equation via needing to make a call or send an email to someone external to the direct team, bring said person up to speed on the problem, and expect that said person might have other projects he is supporting at any given time... thus reducing his focus/attention to the problem at hand.

Where it might (or might not) be better than Epic's own support situation, I am saying that the inherent negatives of said situation still exist, it's simply a matter of degrees.

And as to these toolsets and libraries having more features than you need, again, why isn't this an architectural problem, rather than an inherent problem with the concept of shared libraries/tools?

Not sure what you mean by architectural problem. If an engine is geared towards certain strengths, it is almost by nature going to be weaker in certain areas because those areas are not built around explicitly. If a game is focused on mechanics featuring said 'weaknesses,' well... then the engine is going to look a lot different at the end of the process than it did at the beginning anyway.

And to clarify, I'm not arguing for a monolithic engine, but for R&D/core development work to be pooled, rather than repeated across different studios, especially within a single publisher. Code bases are just increasing; other disciplines learned the hard way about the need to simplify and consolidate, and I can't see any reason that gaming would be different.

As I said to Shifty, I think the game industry can afford to have games with the same engine, even a similar feel. I think it could only benefit by having cheaper software because I don't think the current model is sustainable. I don't think we're paying enough for the quality of software we're getting (most of you think I'm crazy, I imagine).

I don't think you're crazy Obonicus, indeed I understand what you're going for. But I really feel you over-emphasize the gains that can be made from further centralization on engine work. We're talking about financial gains here, right? You're just approaching it too Fortune 500 IMO, viewing the IP and the tools as more valuable than the individuals. In fact it seems to me that your ideal has a model where the team members become devalued to commodity level, easily shifted from product to product, familiar with 'the tools,' and uniform in practices and standards. It's macro, but too macro. As has been pointed out here already, this is a creative medium. The studios/titles that shine do so because of their teams much moreso than do to any tools or technology they've been given access to. When you force these guys to conform to an externally imposed straightjacket approach, you are most likely going to lose them, and development times will either increase and/or product quality will suffer. A lot of the top guys on the top teams like approaching the problems on their own terms, feeling they are contributing to the greater dialog in the development community, and building tools around the needs of the in-house artists/programmers that they have personal relationships with.

Cookie cutter games shines through, whether the technology is up to par or not, and that's what I feel you'll get with a heavy top-down approach. Hell even EA themselves has recently said they've been micro-managing too much, at the expense of disaffecting some of the developers that made their acquired dev houses what they were pre-acquisition... to say nothing of what a Politburo-style technology 'efficiency' imposition would do.

This is an industry of fixed costs - the costs pre-release are primarily head count. If your title launch is delayed, as has been indicated already in this thread as a frequent effect of external sourcing, than more likely than not you have ended up losing more money supporting said fixed cost structure than you have on the gains you achieved on 'fast-tracking' engine development. To say nothing of the compounded effects from potentially missing a certain launch window that was viewed as previously advantageous...

Now, you're saying that you would like to see the wages increased and game prices raised. I love all the developers of the world, but those wage increases would start adding the millions to title expenses real quick, far far exceeding any hypothetical gains from even an utopian technology situation. When you're thinking game development... it's been said before but it really does apply... think Hollywood rather than Microsoft (OS/Office). You are going to do a lot more damage than good by moving teams that are creative not just on a story/gameplay level but on a technology level as well to a super-centralized structure such as exists in the enterprise software space. The industry being hit-driven, such as with Hollywood or other 'artistic' mediums, is not new.