Slashdot Mirror

You post anonymously because you know not of what you speak.

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization

He already posts his business e-mail all over the internets.

He already posts his business e-mail all over the internets.

Port Windows-based games to the Linux platform.

The problem is that at this point is been over a year and we have seen no progress. So it's hard to say if they are hard at work or gave up for now.

From their tutorial: http://developer.valvesoftware.com/wiki/L4D_Level_Design/Panic_Events "You still will only have limited control over where they will come from, but you can at least have control over them spawning. "

Any software model that forces customers to phone home/connect to the mothership is flawed at best and horrific at worst.

Regarding Team Fortress 2 (arguably one of their most successful recent titles)

Valve as a company has ridden on the coattails of technology originally developed (and not significantly improved since) from around 1997. The HL/HL2 entity/brush system hasn't changed significantly since Quake1 and to date they still haven't achieved the stunning leap forward of the original Team Fortress "mod". To be clear, the features and functionality available in Quake1 with the original Team Fortress Mod has not been seen in TF2. You would think after 12 years they could have come up with something better. Nope! (No, from a development/mapping perspective, more eye candy does not equal "better")

Take a walk through their bug database and see how long it takes to get anything acknowledged, never mind fixed. It's atrocious. It's embarrassing. The number of developers at Valve that actually know enough about their "flagship" engine and SDK is less than two, that is, one. And he has all the arrogance such a unique position would create. Two for two, Valve, well played.

Oh wait, you can't look through their bug database! Looky here... the buglist was retired late in 2008/early in 2009, and used to reside at http://developer.valvesoftware.com/cgi-bin/bugzilla/buglist.cgi

Apparently now you can't submit bugs. http://developer.valvesoftware.com/w/index.php?title=Bugzilla&redirect=no

That's awesome. How is removing the only publicly accessible bug submission and tracking tool a good thing? Oh right, it's not.

Steam is a cancer on the gaming world. Here's the way it should work: I give you money, you give me a product. That's where our business relationship ends, after the payment transaction.

Want to try something fun with Steam? Play your favorite game. Shut down your computer. Disconnect from the Internet (I know, shocking, but try it!). Now start up the computer and play your favorite game again. Oh wait, you CAN'T. In fact, without planning ahead and jumping through all their lame ass hoops, you CANNOT. EVER. PLAY. AGAIN. Until you reconnect to the Internet.

Guess what? Some of us don't live in a world of 100% guaranteeed Internet Connectivity. Yeah, like ... you know, the part of the world that isn't australia, north america, and western europe. Well that's ok, says Valve, you're boned! Thanks for the money, we'll be snorting more coke off hookers while you can't play your game! Woo hoo!

Until it is possible to play the games I paid for without planning ahead for an Internet "outage", Steam is fundamentally broken. 100%, forever, stick a fork in it, it's done.

Any software model that forces customers to phone home/connect to the mothership is flawed at best and horrific at worst.

Regarding Team Fortress 2 (arguably one of their most successful recent titles)

Valve as a company has ridden on the coattails of technology originally developed (and not significantly improved since) from around 1997. The HL/HL2 entity/brush system hasn't changed significantly since Quake1 and to date they still haven't achieved the stunning leap forward of the original Team Fortress "mod". To be clear, the features and functionality available in Quake1 with the original Team Fortress Mod has not been seen in TF2. You would think after 12 years they could have come up with something better. Nope! (No, from a development/mapping perspective, more eye candy does not equal "better")

Take a walk through their bug database and see how long it takes to get anything acknowledged, never mind fixed. It's atrocious. It's embarrassing. The number of developers at Valve that actually know enough about their "flagship" engine and SDK is less than two, that is, one. And he has all the arrogance such a unique position would create. Two for two, Valve, well played.

Oh wait, you can't look through their bug database! Looky here... the buglist was retired late in 2008/early in 2009, and used to reside at http://developer.valvesoftware.com/cgi-bin/bugzilla/buglist.cgi

Apparently now you can't submit bugs. http://developer.valvesoftware.com/w/index.php?title=Bugzilla&redirect=no

That's awesome. How is removing the only publicly accessible bug submission and tracking tool a good thing? Oh right, it's not.

Steam is a cancer on the gaming world. Here's the way it should work: I give you money, you give me a product. That's where our business relationship ends, after the payment transaction.

Want to try something fun with Steam? Play your favorite game. Shut down your computer. Disconnect from the Internet (I know, shocking, but try it!). Now start up the computer and play your favorite game again. Oh wait, you CAN'T. In fact, without planning ahead and jumping through all their lame ass hoops, you CANNOT. EVER. PLAY. AGAIN. Until you reconnect to the Internet.

Guess what? Some of us don't live in a world of 100% guaranteeed Internet Connectivity. Yeah, like ... you know, the part of the world that isn't australia, north america, and western europe. Well that's ok, says Valve, you're boned! Thanks for the money, we'll be snorting more coke off hookers while you can't play your game! Woo hoo!

Until it is possible to play the games I paid for without planning ahead for an Internet "outage", Steam is fundamentally broken. 100%, forever, stick a fork in it, it's done.

Unless the game you're playing trusts the client to do its own hit detection (which would preclude any competitive Internet play), it's the server that disagreed over whether you hit the person, not their client. (although it's possible that some artifacts are produced due to lag compensation)

The only game that I'm aware of that doesn't do server side hit detection is bzFlag, where each client checks for hits against itself which would make cheating trivial, even if the source code wasn't already available. (More server side logic is planned for v3.0.)

Further reading:
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
http://developer.valvesoftware.com/w/index.php?title=Lag_Compensation
http://my.bzflag.org/w/Lag

Unless the game you're playing trusts the client to do its own hit detection (which would preclude any competitive Internet play), it's the server that disagreed over whether you hit the person, not their client. (although it's possible that some artifacts are produced due to lag compensation)

The only game that I'm aware of that doesn't do server side hit detection is bzFlag, where each client checks for hits against itself which would make cheating trivial, even if the source code wasn't already available. (More server side logic is planned for v3.0.)

Further reading:
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
http://developer.valvesoftware.com/w/index.php?title=Lag_Compensation
http://my.bzflag.org/w/Lag

What makes you think there is going to be a Linux steam client?

The only thing I've heard about it is a nonsense rumour from a valve job advertisement.

Maybe you should update your facts. The Postal 3 dev listed Linux as a confirmed platform for the Source Engine in 2009. Since I doubt Valve will sell their games without Steam compatibility if they have a native Source engine I'm assuming they will also provide a native Steam client. This not only to me acts as proof that the "nonsense" rumor (actually from a really unsubstantial source: the Valve website!) is actually true and one of the precursors to a Linux port of Steam and the Source games.

With Source already ported to OpenGL on the PS3 there is further evidence that a port is not only possible but likely. Postal 3 is a confirmed Source engine based game for Linux in 2009. I'm expecting delays but this is as close to a Linux client Valve has ever confessed. They know through their hardware survey and forum participation that their users use WINE and Linux operating systems. They know the direction of the market and know that Steam is the perfect platform to distribute games to alternative OSs. I would actually be more surprised if they hired a Senior Linux Engineer and DIDN'T port Source/Steam.

OMG! PC Games: What systems will Postal III be released on?

Vince Desi: Xbox 360, PS3, PC, Mac and Linux.

http://www.omgpcgames.com/content/view/45/37/

If someone made a CPU with many cores (>25, let's say), then one easy way to use all those cores would be to have each NPC have their own pathfinding thread.

The problem right now in game design is the wide variety of hardware on the market. You still have gamers like me who are still running on single-core machines, and you have people who are running quad-core hyper-thread machines. As a game studio, you have to code for everyone. If you make a thread for each NPC now, then the task switching alone would choke the CPU for most games.

You can read about Valve's difficulties making the Source engine multi-threaded in their paper "Dragged Kicking and Screaming: Source Multicore". http://valvesoftware.com/publications.html

and seem to be completely devoted to Microsoft for some crazy reason

Not so much that, as apparently the PS3 is very hard to code for, especially when you're used to Windows coding. Apparently the 360 is easier to port from Windows, or to code alongside Windows.

Take a look at "How To Go From PC to Cross Platform Development Without Killing Your Studio" here:
http://valvesoftware.com/publications.html

From Valve's Developer Forum

Please note: Games run with these methods will be slower than running them on Windows because the games are not native executable files. To get the best performance we will need to wait for Valve to release a native Steam client

While it may work for some things (as I mentioned in my accidentally anonymous post, I've got software that I rely on that refuse to run under WINE) under the best conditions, it adds layers in the execution tree.

This slows things down. In today's performance-driven market, that means the bleeding-edge games don't run as fast with all the eye-candy turned on.

I say "under the best conditions" because it's a re-implementation of the Windows APIs. There's all sorts of opportunities for them to rewrite things less efficiently and end up with less stable code.

When we were getting very close to releasing Half-Life 1 (less than a week or so), we found there were already some projects that we needed to start working on, but we couldn't risk checking in code to the shipping version of the game. At that point we forked off the code in VSS to be both $/Goldsrc and /$Src. Over the next few years, we used these terms internally as "Goldsource" and "Source". At least initially, the Goldsrc branch of code referred to the codebase that was currently released, and Src referred to the next set of more risky technology that we were working on. When it came down to show Half-Life 2 for the first time at E3, it was part of our internal communication to refer to the "Source" engine vs. the "Goldsource" engine, and the name stuck.

Steam/Valve uses "opt out" rather than opt-in marketing, Valve gives users the option of discontinuing receipt of promotional email communications from Valve.

Further, "Valve may use customer contact information provided by users to send information about Valve, including news about product updates, contests, events, and other promotional materials, but only if the users agree to receive such communications." Not untypical for this type of scum, your agreement is via,

By using Valve's online sites and products, users agree that Valve may collect aggregate information, individual information, and personally identifiable information, as defined below. Valve may share aggregate information and individual information with other parties.

Of course, the FIRST thing I do before considering a purchase is read the privacy policy. If I don't like it, you don't get my business.

This article doesn't really make it clear what time system they're using to specify "soon". Could it possibly be Valve Time (http://developer.valvesoftware.com/wiki/Valve_Time)? In that case, you guys will have to wait until Duke Nukem Forever goes gold.

Since we're on the topic of games

ArenaNet (Guild wars): http://www.arena.net/contact.php

Ironclad Games (Sins of a Solar Empire) http://www.ironcladgames.com/contact.html

Blizzard Entertainment (World of Warcraft) http://us.blizzard.com/support/webform-us.xml?gameId=0

Firzxis (Civilization IV) http://www.firaxis.com/support/

Electronic Arts (lots of games) http://www.info.ea.com/company/company_prlist.php

Valve (Steam: Counterstrike, other games) http://www.valvesoftware.com/contact.html

Activision (Gun) http://www.activision.com/index.html#contact|en_US

And code for WINE.

ArenaNet (Guild wars): http://www.arena.net/contact.php

Ironclad Games (Sins of a Solar Empire) http://www.ironcladgames.com/contact.html

Blizzard Entertainment (World of Warcraft) http://us.blizzard.com/support/webform-us.xml?gameId=0

Firzxis (Civilization IV) http://www.firaxis.com/support/

Electronic Arts (lots of games) http://www.info.ea.com/company/company_prlist.php

Valve (Steam: Counterstrike, other games) http://www.valvesoftware.com/contact.html

Ask for either native Linux port or Wine-compatible Windows binaries.

Unfortunately 3d Realms adopted VALVe time.
http://developer.valvesoftware.com/wiki/Valve_Time

As you can see DMF wont be out until 2009.(but we already knew that didn't we)

It could happen.

No I am not a Valve Employee.

But it appears Phil Co is or was at some point. http://www.valvesoftware.com/people.html

So perhaps the book is worth a look.

No, there isn't a problem. Id software does just fine without using DirectX components. Portability of games based on Id's engines to linux is relatively easy. There are rumors that Valve is thinking of porting over to linux. http://valvesoftware.com/job-SenSoftEngineer.html . Note the section that says, "Port Windows-based games to the Linux platform."

Sounds to me like they've been using Valve Time.

Give Anachronox a try if you haven't already.

As long as Erik Wolpaw from Old Man Murray is still involved, any sequel should be good. For those who don't know, Old Man Murray was one of a few honest game review sites. In days when most websites would gush over upcoming games to secure future access, Chet (Faliszek) and Erik applied their knowledge of what was wrong with games in general to their review of each new game. Read their preview of Serious Sam (linked below). It's hilarious on many levels, and very incisive besides. So it's easy to see why Psychonauts was fun fun fun.

• Erik Wolpaw
• Chet Faliszek
• Serious Sam: The Interview

Yeah, but a lot of the appeal of Portal is the storyline. Without it, it would have been fun, but not half as good.

Yeah, Valve hired Chet and Erik of the hilarious and much-missed Old Man Murray (remember them?) to do the writing for Portal, and it shows.

Got a copy of Episode One, and want some more single-player Half-Life 2 before going all orangey with the Orange Box on Wednesday?

I prescribe my own MINERVA, complete with needlessly cryptic website.

Random games journalist types are quite keen on it. No bribery was involved whatsoever, honest. Other links? Wikipedia! My blog-thing! ... Um ... Valve Developer Community! Even Steam!

Described by random inhabitants of the internet as having: "extremely bad writing", with "some of the most dreadfully boring environments you'll ever see" - the "puzzles and triggers in the game are horrific", and "combat is done exactly the wrong way" - what are you waiting for?

http://www.valvesoftware.com/job-SenSoftEngineer.html

See that "Port Windows-based games to the Linux platform" thing?

Firefox will warn you if a program tries to use other protocols. It will allow you to suppress the warning, however, which can cause the same problem as IE, but at least you can't say you weren't warned. So from this POV, it is IE's problem moreso than Firefox's, especially when it's considered that the URLs can't do anything from WITHIN Firefox, and that (I haven't checked this, just heard it somewhere) the protocol was requested by MS for some Vista compatibility thing or some such nonsense. Not sure if there's anything to that.

However, on the flip side, anyone who implements a protocol needs to be aware any web page can invoke the protocol at will, without the consent of the user (well, thanks to IE's "standards"). This results in being able to do things like this. This webpage redirects the browser to steam://open/main, which will open the main Steam window. The user never sees the actual url. This could work with the firefoxurl protocol as well. Here are some other things that can be done, some of the uglier ones have confirmation screens I believe, but launching a game or connecting to a server does not. Note the first one which promises that it can redirect command line arguments, just like firefoxurl... however I cannot get that to work (I tried -shutdown and it just focused the main window like my current sample does). Also note the hackish steam://openurl/, which is designed to allow Steam's built-in IE browser to invoke the computer's default browser. Theoretically this could be used to bypass a popup blocker.

Of course it would appear that Steam at least can't run arbitrary programs and is limited to it's own folder in terms of effects (I could force you to join my UBER LAME COUNTER STRIKE SERVER but that's about it).

I think both Microsoft and Mozilla need to take steps to fix this problem. Microsoft needs to improve external protocol handling to at least what Firefox does (Firefox could even secure its own handling more, but that might detract too much from the flexibility. Not that that's stopped anybody before). Mozilla should remove this silly firefoxurl bit. I can't think of any legitimate reason for it (anyone have any clue?).

As for Valve with Steam... steam://openurl/ is a bit much I think. It's expected for users who don't know what MSHTML or ActiveX are to think it's a bug that external windows open in IE, but us devs know that, internally, IE is just spawning a new window for a page. Since when were you browsing the web in IE and click on a link and it popped open in Firefox? I wouldn't want that to happen if I preferred IE! (Yeah... firefoxurl is definitely useless.) I mean, can't Valve say that because Steam uses Internet Explorer internally for the Store, all launched webpages will appear in Internet Explorer and there's no way around it? Eh probably not. The technically inclined probably think everything is great now and wouldn't care if anyone told them Valve used a hackish and possibly unsafe solution.

Although at the least they could use a whitelist for urls to use for openurl... IE steampowered.com and whatever other sites they link to... although considering the number of third party games being added it could be a largish list. :(

Perhaps steam could kick the steam:// thing entirely, but the only alternative I can think of is an Internet Explorer BHO (ick, not worth the trouble IMO), unless they can do something fancy with javascript or java or flash or something.

Here's a bonus for reading all this: You can see what available protocols Windows / Internet Explorer can use (Firefox too, although it has its own extras like about: and data:) by checking HKEY_CLASSES_ROOT in regedit. Search for Values with the exact name of "URL Protocol" and the keys you find (or maybe it's in the default value?) are the protocol names. With a look it can be easy to figure out how

Yes. You may be thinking of cs_havana, for Counter-strike Source. That map is reconfigured at the start of each round so that the routes available are different (cite).

I personally find that map extremely confusing and not much fun. It is hard enough learning a new map without it changing every time. I have enough trouble with the static maps!

These "textures" were things like the light attenuation pattern of a flashlight. You buy this stuff from a specialist because you can't afford the time it'd take for one of your artists to even figure out how to make something like this, let alone perfect the process to where it's going to look as good as the ones you can buy.

Actually, the engine supports graphics cards supporting features from right back to DirectX 6.0.

From a design point of view, surfaces in the game are defined by materials, which include however many texture references and shader parameters as are necessary for each set of hardware features. The difficult thing about backwards-compatibility is more making sure that there's always a fairly good-looking fallback for lesser hardware - meaning a fancy shader effect might have to be replaced with something much cruder. Neglecting to do so might result in an important prop, character or whatever appearing as wireframe or a magenta-and-black checkerboard.

The DirectX 10 support in Episode 2 is more just forwards compatibility, I imagine - I wouldn't be surprised if the visual enhancements were very subtle, but nice nevertheless for people with the necessary hardware and software. Other changes might make the rendering pipeline more efficient, or whatever it is DirectX boasts about. Plus, with the materials system, it's more just a task for engine programmers and artists - updated materials will slot straight into previously designed maps. The actual, time-consuming gameplay design and implementation can run entirely in parallel, done by completely different people...

Actually, the engine supports graphics cards supporting features from right back to DirectX 6.0.

From a design point of view, surfaces in the game are defined by materials, which include however many texture references and shader parameters as are necessary for each set of hardware features. The difficult thing about backwards-compatibility is more making sure that there's always a fairly good-looking fallback for lesser hardware - meaning a fancy shader effect might have to be replaced with something much cruder. Neglecting to do so might result in an important prop, character or whatever appearing as wireframe or a magenta-and-black checkerboard.

The DirectX 10 support in Episode 2 is more just forwards compatibility, I imagine - I wouldn't be surprised if the visual enhancements were very subtle, but nice nevertheless for people with the necessary hardware and software. Other changes might make the rendering pipeline more efficient, or whatever it is DirectX boasts about. Plus, with the materials system, it's more just a task for engine programmers and artists - updated materials will slot straight into previously designed maps. The actual, time-consuming gameplay design and implementation can run entirely in parallel, done by completely different people...

Why would Valve want to distribute open scientific research via Steam?

It will be interesting to read Dr. Gordon Freeman's research on quantum mechanics from the Black Mesa Research Facility...

Hello? Valve Time? http://developer.valvesoftware.com/wiki/Valve_Time

I believe the term you're looking for is Valve Time.

In all honesty, I think we already hit the delay, and now we are just waiting for the final release. We will probably hear more precise rumours as the date goes by, then we will hear the giant WHOOOSH as they go flying by, and eventualy we will have out precious HL2:EP2, TF2, and Portal (time to wipe up the drool again), at the very, very end of summer.

What a bountiful collection of jargon you have... it's clear that you come from a dogmatic school of 3D modeling. (if any school... and if you are self-taught, I applaud you... even if not for the lack of humility)

Texture deformation happens on the contiguous mesh, (one-piece models) though it is generally a real-time feature of the engine and not the model itself. Part of Valve's innovation was making model-animation specifics part of the engine, rather than relying on design-time parameters. Why did you not make the leap to this conclusion? Are you so steeped in static modeling that you fail to envision the model in action?

As to the idea that I was even referring to consoles in the first place, I didn't. Valves efforts were founded in the PC gaming arena, and eventually tossed a bone to the sixth-gen consoles such as Xbox, GameCube and PS2. For the benefit of my first post, I was only referring to PC game technology and relevant hardware. (3dfx, nVidia, S3 and ATI) If you remember, the consoles of that age aspired to the performance of even a mediocre 3D-accelerated PC back in the day.

For this thoroughly unrelated claim, I have to make a mention of its inaccuracy. Half Life had plenty of UV mapping; it's now an indispensable part of 3D design! Sometimes the interactive objects in HL reassigned texture-maps, sometimes they used a procedural texture, thereby changing the visible surface in real-time. This is a relatively simple technique and is prevalent in many games since HL, Quake II, and even Unreal.

Have you modded or mapped any Valve games? Used Hammer recently? It's a free download. (or you can jump all the way up to the Source SDK) I encourage you to try it out, after all, it beats the $500+ price tags of 3D Studio and the like.

Skeletal Kinetic Animation as a technique is, in fact, a bit after the first Half Life release. It did not really have a name at first, but it came to be known as such. Valve was good enough to help distribute the technique around the 3D community rather than patent and camp on it. (they earn my respect with such gestures) Though Valve did not, themselves, invent or introduce it, they played a significant role.

This is why I've said that the state of modern 3D-dev is thanks in part to the efforts of the Valve team. This, in and of itself, is the only point I wish to make; all other ideas from my initial post seem to have dropped from your radar

I'm not sure of your exact stance in this discussion... frankly, it's a bit troll-ish. (debating irrelevant details and trying to intimidate with barrages of so-called uber-speak) If there is nothing more constructive to add, let's call it a day, shall we? If you feel like debating yourself even more, feel free to do so. I will have moved on.

Werd.

From all of the Quake-clones, only a few really stand out. Unreal branched to make their own engine, (recently licensed by EA Games, in fact--NOTE: link downloads PDF file) so did Half Life (the first). (partly responsible for the industry movement to "skeletal" modeling) Of the two, Source engine is truly the more powerful. (even if not the more ubiquitous)

Steam resembles a constant hack-in-progress, and the "Content Servers" are what get my goat every time. (2 megabit pipe and I'm still downloading at 80kbps?!?!) Let's join hands and pray for it's quick emergence into robustitudity. (yes, I made that up... what, you don't invent any words?)

In all, it only amounts to the partly-bruised banana in an otherwise delicious arrangement of delights in the gaming industry.

'click' ... purchased ... 'click' ... installed ... 'click' ... start game -- nobody else has that

Can you say VaLVe?

Revolutionary 3D engine. Online direct-to-drive purchasing and net-play platform. Open door to the community to modify their products, and turn-key partnering for smaller developers to release new and innovative titles. (2D/3D/RPG... you name it)

Often remembered for their "just in time" releases, they have always put quality at the forefront.

If EA has any lessons to learn, they could far worse than learning from VaLVe's example.

Hopefully Minerva Episode 3 before HL2 Episode 2? ;)

Heh. Ideally before Christmas, although that's possibly pushing things just a bit... ;-)

Definitely before Valve's release, anyhow. I'm not quite running on Valve Time...

There also exists C++ code to produce lip-synched speech truly on the fly, which is then spoken externally, but concurrently with, the HL2 engine. Essentially, there is a function in the codebase that takes a string to say, speaks the string through the TTS engine, and lipsyncs the actors' lips as the text is being spoken. With this technique, for example, you could have a cute multiplayer mod where any messages sent textually are actually pronounced on the other clients' machines.

There also exists C++ code to produce lip-synched speech truly on the fly, which is then spoken externally, but concurrently with, the HL2 engine. Essentially, there is a function in the codebase that takes a string to say, speaks the string through the TTS engine, and lipsyncs the actors' lips as the text is being spoken. With this technique, for example, you could have a cute multiplayer mod where any messages sent textually are actually pronounced on the other clients' machines.

For example, instead of using true type fonts that use vectors, and would look nice at any resolution and scale, they still used plain old bitmaps.

Truetype fonts for text and other graphical elements? That's so last-generation...

Also, don't stab me in the eyes for this - but Flash could be an interesting addition for a game's controllable panels, interfaces and so on. Doom 3 was nearly there, but if you manage to get the game to run at a high resolution, you'll soon discover that it's all based around relatively low-resolution bitmaps.

If one of these über-games-consoles dedicated a core to rendering Flash elements where necessary, then there'd be loads of new possibilities. And, being an excessively common design target already, everyone knows how to design Flash animations anyway...

http://developer.valvesoftware.com/wiki/Valve_Time

And, according to a Mr. Gabe Newell himself, the release of TF2 is to be coincident with the Rapture.

At this point, I'd be suspicious if a Valve game was released on schedule. Their understanding of the concept of time is a little ... unusual, to say the least.

Great known writers are unnecessary. Games with a solid premise (i.e. Half-Life) can have their story fleshed out into the HL excellence by nonprofessional writers.

"Marc Laidlaw joined Valve in 1997, bringing his experience as an author of weird fiction to bear on creating the Half-Life storyline. He was sole writer on Half-Life and Half-Life 2, and persists as lead writer for the Half-Life 2 Episodes [...] His novels include Dad's Nuke, Neon Lotus, Kalifornia, The Orchid Eater, and the award-winning The 37th Mandala, as well as The Third Force"

Sorry but the facts don't seem to support your argument here...

Wouldn't they hire great known writers to create game-friendly stories

I completely buy into the possibility that games can be designed well enough to abstract their graphics to a point where the same exact graphics package can be used in even several different types of games.

Brillant! You could call it a graphics engine and sell it to people to make their own games with!

I think these guys might be on to something:
http://www.valvesoftware.com/sourcelicense/
http://ftp.idsoftware.com/business/technology/

The guys at Valve totally rock with their Stem technology.
They are already moving to the next step, testing it on humans.

If you take the number of employees into account then Valve Corp with a little more than 70 employees made $70mil in 2005. That is $10mil per employee. Compare that to the number of human resources involved in the "Titanic" or "Star Wars" and you get a better picture of who's making a more efficient use of human resources.