Why do promising games get cancelled so often?

Stargate Or, whatever happened to Stargate SG-1: The Alliance?

It seems that the long awaited Stargate FPS has been cancelled. It's disappointing news for Stargate fans, and a dark day indeed for its development team. Are the rumours of SG-1's demise true, and if they are, why was the project abandoned?

The crazy wolf-man answers almost nothing of this and instead veers off topic and rants on and on about nonsense like the lunatic that he is.

Did I miss something?

The alleged cancellation of Stargate SG-1: The Alliance is one of those things that reads like a cover-up story from the TV series itself. It seems the game is gone, though vestiges of it remain for now: an official web site that hasn't been updated since June 2005, and a bunch of fan-sites paying homage to a product that may never appear.

If it is dead, the Australian development staff must be feeling pretty depressed to see two years of their work vanish in a puff of 'executive decision'. Will this be the end of Perception? Despite their legendary ability to deliver at low costs and to meet deadlines, Australian developers in general have a hard time surviving. It would be a bitter coating on an already unpleasant pill if this were to spell the end of Perception.

Did they really announce the cancellation?

There are plenty of articles saying that an announcement of the cancellation is forthcoming, but I can't find the actual announcement. Does anyone know where it is? Does it even exist? I'm not sure it does.

Is the whole thing a cover-up to disguise the fact that they've been secretly operating a stargate for nine years? You'd think someone would have noticed all those spaceships appearing in the sky by now... Oh wait, I'm getting confused with the TV series again.

I can't find anything to offically say that this game is cancelled, but then on the other hand there are those obvious signs: the official web page hasn't been updated since June 2005, the release was supposed to be last year, and there's no sign of it on MGM's own games page.

While there's a recent update on the developer's web page, it's two weeks old, which neatly coincides with the appearance of the cancellation rumour - a rumour that allegedly came out of Perception itself.

In the end, all we have is a trail of baffled forum posts by fans, trying to figure out what happened, randomly blaming JoWood and MGM, praising the developers Perception and urging us to wait for the press release. Thers's even a petition to save the project - ain't it sweet?

Everyone seems keen to suggest that the game was almost finished, yet this seems unlikely given its apparent cancellation. While it's true that from time to time, nearly finished, or completely finished games are canned, it's the exception rather than the rule. If the game was as wonderful and as complete as the fans want to believe, then it's unlikely that it would have been dropped after two years of development money was spent on it. It's far more likely that the project had serious quality issues, and spiralling cost overruns. Not least among the latter would be the cost of the Unreal license.

If I was to blame the failure of the game on anything, it would have to be the excessive amount of flash on the official web site. It's completely composed of slow, annoying, flash nonsense. Even worse, it fails to properly recognize your flash install and insists that you need to download a new version even when you already have it. If the game itself was anything like that... Well to be fair, it probably wasn't. No, really, I don't blame the web site...

Projects fail for complex reasons that vary from clashes of personality amongst team members to evil financial tricks in the contract that bankrupt the developer. The usual cause is a gap between publisher expectation and what is realistically achievable with the personnel, time and money allowed.

Middleware: simple solutions to complex problems?

Like so many others before them, poor old Perception ended up using a variety of Unreal to develop the game.

A few years ago, publishers caught a disease. I believe it's a complaint that spread through the producer population like wildfire: I call it middlewareitis.

When a producer gets middlewareitis, he starts to believe that all the problems that he had with the programming schedule on previous games can be cured by bringing in code by someone else.

All producers dread coding delays like most people dread root canal work. The idea of being able to just buy code that actually works is like a dream come true for them. Sadly of course, it is a dream.

They also argue that if all programmers become familiar with middleware it will make it easier for staff to move around, and easier to hire new staff with the right experience when you need it. This would be true if everyone used the same middleware, but they don't. It's confusing what ought to be with what is.

So what's wrong with middleware?

Middleware, despite the considerable marketing efforts of the successful vendors, still has bugs. Throw in confusing documentation, programmers who aren't experienced with the code base, and urgent demands for more new features right now, and you end up with just as many problems as you had writing your own engine. They are different problems, but they exist just the same.

Some middleware is really good. For example, DemonWare's networking system is small, tight, well coded, easy to read stuff that mostly does exactly what you expect it to. The documention isn't so great, but the systems are modular enough for this not to be such a problem.

Or Havok: I used to feel sorry for the Havok developers, at least now Havok is getting the recognition it finally deserves. For years they've had a fantastic product with great features that does everything possible to not steal all your CPU, and they've had difficulty selling it. All the while, people have been ranting about how cool physics in games is going to be and doing it worse than Havok. The last few years must have been frustrating for them, but I guess their future is bright.

Other middleware is better described as adequate: for example Renderware. This supposed multi-platform system often hiccups when introduced to a PC and has been known to have issues running on some people's machines. However, the Xbox and PS2 versions seem to work reliably. Sure, they only get so much of the consoles' potential performance out of them, but it runs and that's enough to get your game finished and onto shelves.

It's not like most proprietary engines are so well written that they really use the machine to the max anyway.

Unluckily for the most producers infected with middlewareitis, Renderware was bought by EA. This makes a lot of other publishers wary of it. They are terrified of becoming dependent on it and then having EA ramp up the price, or just shut it off altogether.

Unreal to the Rescue

So we have Unreal. Realistically, Unreal, or at least the versions we have today aren't so much middleware as games called Unreal [insert your favourite variant here], and they're intended primarily to do one thing well: run Unreal. That you can mod it to do other things doesn't really make it a true multiplatform product, or a true generic rendering solution, unlike say, Renderware. The end result is that Unreal tunnels the developers into 'Unreal thinking mode': a world where its very difficult not to write an FPS, whether you like it or not. Compared to Valve's Source Engine it's hard to understand the code. I've heard that people with a lot of experience of it learn to hate it.

Clearly, there are applications for which Unreal is perfectly suited, particularly first-person-shooters that run on high-end PCs. Because different middleware does different things well, it would be best to let the developers decide which one to use - but it's not unknown for a publisher to demand the use of a certain middleware, regardless of how inappropriate it is.

Unreal teases developers by making it difficult to modify the code in useful ways without touching headers that are 'off limits'. These headers are then changed in the next release of Unreal, leaving you with - at best - a horrible manual merge problem, and quite possibly your whole coding strategy wrecked.

The end result is you can end up locked into a particular release of Unreal, replete with all its particular quirks. You are then worse off than if you used your own engine because you are running around trying to fix the problems in that release of Unreal yourself without sufficient knowledge of the code - and that's if you have a full source license. If you don't have one, you are stuffed.

Enter the PS2 - the most important platform for your sales figures

Unreal does not appear to have been designed from the ground up to run on PS2 hardware. It's seems more a case of determined effort on the part of programmers that a PS2 port was ever produced. When it does run on a PS2 the memory overheads can be shocking and if you need to restart the level (if the player dies) you usually have to reload the entire set of level data, which takes a long time off the PS2 DVD drive. Stories go that this has killed more than one project dead. Presumably they simply can't cope with Unreal's memory requirements on the PS2, which has only 48Mb of physical RAM and no hard-drive to swap to.

It's very likely the case that if you want a good PS2 game you need an engine that was written for the PS2, or at least written for some kind of console, not a PC with endless RAM and a fast hard-drive with 3Gb of swap space.

Obviously, these problems can be solved with sufficient effort, but doesn't that defeat the objective of using middleware? Wasn't it supposed to solve all your engine coding problems and leave you completely free to work on your game code and art?

You get your features for nothing and your bugs fixed for free

Producers with middlewareitis believe that the best thing about middleware is that you get your bugs fixed for you by huge team of experts who beaver away at your problems, hold your hand and offer great support. This is what the middleware vendors suggest you will get.

It doesn't always seem to happen in practice. Middleware vendors have only so many staff and a lot of demands on their time. Sure, they are likely to be really helpful if you are a major customer, but what if you aren't? Add to this, many of the middleware development team will be working on new features, ports to new platforms, or the next major new version and not on supporting external developers.

Because in game development it's usually the case that if you can't fix it today you have to give up and try something else, waiting two weeks for middleware support to help you out isn't going to work. Tight schedules and frequent milestones make it highly impractical: the only support that's worth having is support that can turn around most questions in an hour or two. A developer in Australia can't even begin to hope for that because the American support staff are sleeping while they work.

As I explained above, when you actually get a new release it isn't always your friend. In fact, it might wreck almost everything you've done so far. It can take days to get your code working again after a middleware library update. Or perhaps even weeks.

So how are things better?

With middleware, things are not better at all, they are just different. It's ever more tempting for inexperienced teams to take on projects they can't possibly complete, dreaming that the middleware will solve their problems. Middleware is very expensive, and developers often forget that they could hire several really good engine programmers for a fraction of the price of a top tier middleware license. Usually the publisher foots the middleware bill though, so at first glance it seems like a benefit. Again, developers forget that this is money that could have been paid to them. The profit margin on the engine code goes in the pockets of EA, Unreal or Id rather than to the smaller developers.

It's always been a dream of humanity to produce simple, easy solutions to problems that are in fact, subtle complex beasts. This is obviously impossible when you stand back and take a long look, but it doesn't stop some producers from believing it's really that simple: buy middleware, add game, project complete.

The graveyard of dead projects

There are a great many projects that were started with Unreal, or some other 'middleware' that were cancelled due to coding problems. Stargate SG-1: Alliances is probably just another one.

Coding problems exist on projects for all kinds of reasons: bad programmers, bad management, absurd demands, impossible schedules, legacy code, lousy middleware and ever changing requirements - to name just a few. There is no way that buying in some foreign code is going to fix all the things that can go wrong. Publishers should stop forcing it onto developers who really don't want it, or at least let them choose what middleware to use rather than demanding that they use Unreal. Are you listening Konami?

Of course, my opinions of Unreal and other middleware may be completely unfounded. You should believe everything the middleware sales team tells you about their product: after all, they are the experts on the matter, and they're not just making stuff up to fill column inches like me.