Half life development time

[ShepMode]

Joe or anyone that really knows; I remember there being a discussion about the Half Life development time a while back and how it took a long time. Can anyone tell me the actual development time, or link me to a page that will tell me?

Thanks.

[X-Vector]

It's about two years; Valve acquired the Quake source code late '96 (see here (http://www.gamespot.com/features/halflife_final/part22.html)), then started up the company and signed a publishing deal (http://www.gamespot.com/features/halflife_final/part24.html) with Sierra - the game was released towards the end of '98.

[Duoae]

Maybe he's talking about Half life 2? As 2 years isn't long...

[Mountain Man]

Yeah, I though the original Half-Life was in development for longer than that. I do know they had finished the game but weren't happy with it, so they rebuilt it from scratch. That's why it was delayed a year.

[X-Vector]

The rebuild took place within that two year period, about halfway through: http://www.gamespot.com/features/halflife_final/part4.html.

[Kristian Joensen]

Yep, it was a miracle that they where able to that and then release such a excellent game. I don't even think they had that many employees back then compared to now.

Half-Life 2 however went from 1999 to 2004.

[Mountain Man]

The majority of the development time on Half-Life 2 was spent developing the tech since they pretty much started from scratch. They put the actual game content together in about a year's time.

[SyntaxN]

The rebuild took place within that two year period, about halfway through: http://www.gamespot.com/features/halflife_final/part4.html.
thx for the link, that´s a damn interesting article.

[Kristian Joensen]

No that is not true, just because you see a great deal of improvement visually doesn't mean alot of code was changed.

Take Tenebrae for example it has ONLY got a new renderer everything else has stayed the same yet they are able to show a great deal visual improvements.

I don't even think HL2 has got a new renderer just got an improved one with shader support and some oether tings thown in.

The breakdown is probably something like this:
*50-60% Quake 1 code.
*20-30% HL1 code.
*10-30% new HL2 code.

That is the engine I am talking about, with the gameplay code the break down is probably like so:
*100% HL2 code.

[Mongorian]

No that is not true, just because you see a great deal of improvement visually doesn't mean alot of code was changed.

Take Tenebrae for example it has ONLY got a new renderer everything else has stayed the same yet they are able to show a great deal visual improvements.

I don't even think HL2 has got a new renderer just got an improved one with shader support and some oether tings thown in.

The breakdown is probably something like this:
*50-60% Quake 1 code.
*20-30% HL1 code.
*10-30% new HL2 code.

That is the engine I am talking about, with the gameplay code the break down is probably like so:
*100% HL2 code.

I can pull figures out of my ass too, but I don't think anyone would appreciate it.

[Kristian Joensen]

Those are not taken out of my ass, the information behind them is out there. Valve did a few changes here and there to the engine.

[Nacho]

Maybe he's talking about Half life 2? As 2 years isn't long...

An enormous ammount of time for a FPS those days actually.

[Kristian Joensen]

On average perhaps but Duke3D took 3 years. For instance. I am sure there asre other examples like that. Quake took atleast 2-3 years, aswell. However Quake 2 took only 1 year.

[John]

Kristian, he's probably talking about you saying "They are PROBABLY something like this", rather than showing your sources.

[FireFly]

The majority of the development time on Half-Life 2 was spent developing the tech since they pretty much started from scratch. They put the actual game content together in about a year's time.
Not quite. They started full scale production on the game's levels in September 2002, and the game shipped 2 years after that. However even before this point they were creating content for the 'proof of concept' videos. Work started on this content in late 2001, and continued until they were able to start production on the game proper.

Those are not taken out of my ass, the information behind them is out there. Valve did a few changes here and there to the engine.
Here and there? They've completely revised the functionality of the Half-Life engine. The netcode is completely new, there's a new animation system, a new entity/scripting system, a new A.I system, a new lighting system, a new terrain system, a new visibility system, a new sound system.

I mean seriously, what hasn't been changed?

With regard to the ratio between old and new code, no real information has been released. However, Carmack merely states that "there are still bits of early Quake code in Half Life 2", which hardly indicates that 50 - 60% of Source's code is inherited from Quake 1.

In fact I recall that the ratio was less for the original Half-Life. From the unofficial Half-Life FAQ:

Valve originally licensed the source for Quake from id Software and they began working on that code around October of 1996. Between that time and the time they finished Half-Life in October of 1998, they modified/removed/created something like 70% of the code.

http://faqs.neoseeker.com/Games/PC/half_life.txt

[Kristian Joensen]

Where have you got the info on those new systems from ? New entity system ? I HIGHLY doubt it.

AFAIK ALL those systems you have mentioned are from HL1 and Quake 1.

Anyway, then what is your counter to this (http://www.doom3world.org/phpbb2/viewtopic.php?t=7452&start=0) thread, more specificaly posts like these posts:

If you look at the HL2 SDK, the debt that Source owes to Quake is fairly obvious. Anyone familiar with id tech will recognise what those func_* thingies are, let alone the terms BSP, PVS, lightmap, blocksize, detail brush. Source is clearly heavily derived from Quake/HL tech, and that shouldn't really be much of a suprise.


HL2 on the other hand... Anyone who's seen the source code leak can testify that they basically took HL1, wrote a new file access backend and renderer, then bolted about $200,000,000 of proprietary SDKs on to it. The gamecode even uses old HL1 callbacks and uses the old frame/edict based networking stuff. The map format is an attrocious blend of HL1 BSP with displacement-mapped terrain and static meshes. If you wondered why HL2's levels were so short, there's why.

All I know is that Source engine games still load a .qc file...so there's at least that method left over from Quake, and who knows what else.

One thing most people (including me) forget about HL2 is that source wasn't built for HL2, it was built for TF2. Valve started testing the Source net code YEARS ago, so I'd expect that to be pretty simular. But i'm actuatly amazed at what they DIDN't do with source... we've all seen what's been done with the Q1/Q2 source code by home based amatures (tenebrae & code red for example). We know that Valve could of done a better render but they didn't. Maybe it was one of the first hings they finished & spent most of their time on maps & physics implimination.

Tenebrae has only got a new renderer nothing else. How about the fact that the model and level fileformats are virtually identical ?

Or how about this (http://www.quakesrc.org/forums/viewtopic.php?t=5301) thread:

there are alot of code similarities between the two i know first hand. remember when the HL2 source got leaked? well i got a hold of it and poked around for a bit and many parts are identical to Q1src. i dont have the src anymore though for obvious reasons

And false attribution to boot:

valve doesn't even acklowledge id technology copyright in their code headers anymore

Edit 2:

How about this (http://www.quakesrc.org/forums/viewtopic.php?t=5301&postdays=0&postorder=asc&start=45) post ?

[Opus131]

^ You still haven't proved your figures...

[Kristian Joensen]

They where just guestimates based on info like the above, I wasn't amking any argument with the figures at all.

I still stan by them though, but they aren't important.

You don't find misattibution bothersome ?

[John]

Valve already said they used a small amount of Q1 source code, and we all agree with them there. (More than a small amount)

But the majority is far different, in gameplay wise, than Q1 and Q2.

[Kristian Joensen]

Yes, but you gotta appriecate that there is a difference between gameplay code and engine code.

Obviously Valve basicaly wrote the gameplay code from scratch since HL2 is a different game. Plus they don't use QuakeC for the game logic they didn't even do that in HL1.

[FireFly]

Where have you got the info on those new systems from ? New entity system ? I HIGHLY doubt it.
From all the pre-release information pertaining to Source, as well as the various pieces of post release documentation, made for/by modders. One example is the IRC developer chatlog, which contains pages of information about the new advances in Source.

http://www.planethalflife.com/features/articles/hl2chatlog/

AFAIK ALL those systems you have mentioned are from HL1 and Quake 1.
Note that when I say new system I'm referring to a new set of functionality, I'm not claiming that each system was completely rewritten from scratch.

To illustrate this, lets look at Half-Life 2's lighting system. With Source, Valve have adopted a new radiosity based approach. Radiosity information is calculated offline, and then applied dynamically to normal maps, creating a form of real time radiosity. This is then fed into the specularity system (with each object having its own specular map) and finally cubemaps are used to apply general ambient lighting. You can see each of the several lighting stages in Valve's shading presentation.

http://www2.ati.com/developer/gdc/D3DTutorial10_Half-Life2_Shading.pdf

The point is that none of these stages were present in the original Half-Life engine so this lighting system is entirely new. The real time shadowing systems are also different, with Valve going for a full shadow mapping implementation for all dynamic objects.

A.I

On the A.I side of things Valve have implemented a new squad based A.I system, allowing enemies to move together in groups, sharing information on their surroundings (and each other, so squad members know when an ally has died), and taking turns providing cover and suppressive fire. Battles are now dealt with as "assaults", with each NPC being assigned a 'rallypoint' to secure, where they'll wait for the order to commence the assault. This is different to Half-Life's squad system which used squad leaders (not present in Source) to distribute information. If they'd simply built on the previous system, you'd think this functionality would be present.

For more tactical control, 'standoffs' can be set up, meaning NPCs will only fight within given battlefronts, displaying varying degrees of willingness to advance or find cover. These battlelines can move or change dynamically, for example in response to the death of NPCs.

All of this is detailed in the Devloper wiki:

http://developer.valvesoftware.com/wiki/Category:AI

Animation

With regards to animation, the old animation system has been massively revised (if not replaced). In Half-Life the engine could only blend two animations - a lower body animation, and an upper body animation. In Source you can have an infinite number of animation channels layered on top of each other, with individual bone constraints. In fact, the system uses Inverse Kinematics to procedurally generate animation, meaning you don't have to animate every bone, instead you can just move one bone and the rest of the skeleton will compensate.

But it goes even beyond that - the animation system will intelligently blend animations to achieve the required objective:

"For character movement, the animators could give the character scene direction such as locations to move to, and people or places to look at. The AI system would then automatically animate the motions by blending between several different animation sequences. All character animations in Half Life 2 were created in this manner without motion capture."

http://www.gamedev.net/columns/events/coverage/feature.asp?feature_id=79

There's some incredibly sophisticated tech like this in the Source engine that people simply don't do justice to when they say that it's simply 'the HL engine with a new renderer bolted on'.

I haven't even touched on the muscle system, which attaches to the skeleton, providing muscle groups for each joint that are automatically modified in response to movement. For example if you rotate a character's forearm, the affected muscle will realistically 'roll'. Not only that but the muscles actually modify the movement itself! This also plays a part in the facial animation system, with 40 individual muscles that work together realistically.

Finally, bones are dynamically added and removed as part of the LOD system. To get an overview of the advances in the new animation system, I would watch this introductory video:

http://www.fileplanet.com/139025/130000/fileinfo/SoftImage|XSI-EXP-for-Half-Life-2-Tutorial-Part-1

Netcode

With the netcode you're talking about a complete rewrite. Following the source code leak, Valve handed the netcode over to another programmer who was tasked with rewriting it. This was explained in a Valve post on the Steampowered forums, justifying the netcode issues players had been experiencing (at the time the new netcode had only been in place for a few months). I can't locate the post now, however if you recall, Drazula (who had access to both the source code and the SDK) made the same claim entirely separately.

Entity System

When you migrate a map from Half-Life 1 to Half-Life 2, you're going to want to redo all of the entities (and texturing). While some familiar entities remain (and some familiar entity properties as well), the entity system as a whole has gone through a major upgrade, giving you far more flexibility and a cleaner method of controlling events in your map.

http://www.halflife2.net/forums/printthread.php?t=1298&page=10&pp=15

Can you explain what the new Entity I/O system is?

Entity I/O is the way entities are connected in the Source engine. It's essentially an inter-object messaging system. When certain internal events occur, an entity can fire outputs, which can be connected to inputs of other entities.

The output can potentially pass data to the receiving input, for example a wheel can pass its Position as a value from 0 - 1 to the Alpha input of a sprite, so as you turn the wheel the sprite gets brighter.

A given entity can have many different outputs, for example doors can fire an output when they are Opened, Closed, BlockedOpening, BlockedClosing, etc. which can be connected to any other entities in your map. The level designer controls all of this from Hammer, so you have a lot more power for building things.

http://collective.valve-erc.com/index.php?faq=source_mod_faq&section=106159031874671600&question=106159081054303400

Sound

Some of the advances made in the new sound system:

Sounds are all driven by a script file, and sounds are played by label, not by .WAV filename, so once you add the hooks into the game code to play the sound, exactly which WAV gets played, over what channel, and with what probability is all controlled by the script. This is great because the sound guy can iterate on sounds without the help of a programmer. We also Doppler-shifted bullet sounds, which is just cool!

Half-Life 2 supports 5.1, 4.1, and 2 speaker systems. Half-Life 2 supports wave files with 8/16bit, mono/stereo, optional ADPCM compression, and arbitrary sampling rates up to 44.1KHz, and MP3 files as well. We support our own DSP in software. We're working with creative on supporting EAX for that as well.

The sound engine also includes functions for directionality and environmental falloff (atmospheric dB attenuation, etc.). Everything's modeling at real dB levels and all blended together. There's also a whole set of tools for adding dramatic soundscapes and multiple layers of audio - background, action, talking, etc. - that gets blended together cinematically

There's also very fancy stuff like Bullet sounds that are modeled and spatialized as continuous sub-sonic 120db sound sources moving through space.

I think what's most impressive is they've actually incorporated their own DSP system to handle sound propagation.

Visibility/Terrain system

With the terrain system Valve are using deformable subdivision surfaces, in contrast to Half-Life, which had to rely on BSP. And for visibility:

Fifth, we have some additions to our outdoor rendering, including a realtime occlusion system for dealing with issues unique to outdoor environments. We still maintain a BSP-tree based system for dealing with more traditional indoor environments. So, you can now do extremely large outdoor environments which seamlessly transition indoors. I'm excited to see the mods go nuts on this stuff.

So the point is that Valve have overhauled all of these subsystems, they haven’t just made changes "here and there".

Anyway, then what is your counter to this (http://www.doom3world.org/phpbb2/viewtopic.php?t=7452&start=0) thread, more specificaly posts like these posts:
The highlighted comments don't contradict anything I've said. I accept that Half-Life 2 inherits some base functionality from HL/Quake, the point is that Valve have made massive modifications to the HL tech base. What I'm contesting is that:

1.) Close to 50% of the code remains from Quake 1 - when this figure wasn't even true for the original Half-Life.

2.) That Valve haven't overhauled the individual engine subsystems.

Tenebrae has only got a new renderer nothing else.
Yes, and nearly all of the revisions described above don't relate to the renderer. And what exactly is meant by "better renderer"?

How about this post ?
... what advantages does HL2 have over any Q1, Q2, or Q3 based projects? None really.

Again, see my writeup above. The animation system alone is a huge step beyond anything else.

[Mongorian]

That has to hurt. :)

[Kristian Joensen]

That was a informative post Firefly. It seems that we where just talking past eachother ?

But what about the removed copyright notices, that where removed without corresponding alterations of the files ?

Edit:

"... what advantages does HL2 have over any Q1, Q2, or Q3 based projects? None really.

Again, see my writeup above. The animation system alone is a huge step beyond anything else."

What he is talking about is user created modifications of those games source code like Tenebrae, Tenebrae 2, Darkplaces, Quake2MAX, Quake2Evolved, Xreal, etc.

I suspect he is hinting at the lack of per-pixel lighting.

Firefly, it would seem you would disagree with Drazula when he says that lightmaps and bsps where outdated already in 1999, why ? What is your take on that ?

[FireFly]

That was a informative post Firefly. It seems that we where just talking past eachother ?
I'm not sure what you mean here.

But what about the removed copyright notices, that where removed without corresponding alterations of the files ?
Well, I don't think this is that relevant to the discussion. But without knowing why they were removed I wouldn't like to comment.

What he is talking about is user created modifications of those games source code like Tenebrae, Tenebrae 2, Darkplaces, Quake2MAX, Quake2Evolved, Xreal, etc.
That's how I interpreted it, but obviously Source does plenty of things that these projects don't.

I suspect he is hinting at the lack of per-pixel lighting.
Even if he is, the fact remains that Source supports more advanced static lighting.

Firefly, it would seem you would disagree with Drazula when he says that lightmaps and bsps where outdated already in 1999, why ? What is your take on that ?
Drazula generally looks at these issues purely from a technological perspective. In 1999 Kingpin shipped with shadow mapped characters, so his argument was that Source was using a shadowing system that was 5 years old.

This ignores the fact that even in 2002 'blob shadows' were still being used. From UT2003 onwards games started shipping with reasonable shadow mapping implementations, and it was only in 2004 that we saw an FPS ship with stencil shadows.

I don't recall Drazula's argument being about lightmaps, but a similar situation applies, and Doom 3 was the first PC FPS (to my knowledge) to completely do away with them. I personally think that lightmaps look great even today - in many respects they look a lot better than stencil shadows.

I'm not so sure about the situation with regards to BSP adoption, but it was certainly the standard in 1999 and even up to present day (UE3 still uses BSP).

[Mountain Man]

And false attribution to boot:
valve doesn't even acklowledge id technology copyright in their code headers anymore
Begging the question. It is just as possible that they don't acknowledge id technology in the copyright in their code headers for the simple reason that it's not id's code.

[IceColdDuke]

I don't see why everyone cares so much sinse most of you aren't in the industry you are just getting annoyed over nothing ; ). The renderer is a 100% re-write(hence the OpenGl to DirectX), which is what your paying the big $$$ for the SDK + steam + lip syncing + sound code + bone animation code + guided step by step tutorials on getting your game running, the onyl thing I dont like is Hammer, which is the only reason why I like the Unreal Engine.

So I don't see what your problem is firefly....

[FireFly]

You don't need to be in the industry to be interested in engine technology, or to want to promote a better understanding of said technology.

[Kristian Joensen]

Begging the question. It is just as possible that they don't acknowledge id technology in the copyright in their code headers for the simple reason that it's not id's code.

Ehh, I posted a link with a CONCRETE example.

[Cerberus_e]

The renderer is a 100% re-write(hence the OpenGl to DirectX)

Medal of Honor and Call of Duty are also DirectX... still Quake 3 Engine.

Begging the question. It is just as possible that they don't acknowledge id technology in the copyright in their code headers for the simple reason that it's not id's code.

If you downloaded the leaked sourcecode you'd see parts with id's headers, with the exact same code as the final version. At least I've heard so.

[Jokke_r]

Medal of Honor and Call of Duty are also DirectX... still Quake 3 Engine.



If you downloaded the leaked sourcecode you'd see parts with id's headers, with the exact same code as the final version. At least I've heard so.

I'd say MOH:AA and COD are both openGL, atleast afaik.

yep a quick google verified this.

[Mountain Man]

Ehh, I posted a link with a CONCRETE example.
No, you posted a link to hearsay.

[Kristian Joensen]

Why are you putting my words into Cerb's mouth ?

I linked to post containing a QUOTE from such a header with the attibution, which had been removed in the SDK.

Also this isn't a court.

[Mountain Man]

I linked to post containing a QUOTE from such a header with the attibution, which had been removed in the SDK.
Two things are worth noting:

1) Your source admitted that the code had been changed even if he tried to hedge his bets by calling the changes "only minor". It is entirely possible that the admitted changes were sufficient for Valve to claim the work as their own.

2) You have no idea what contractual agreement there is between Valve and id software. It is entirely possible that Valve is in full compliance with their contractual obligations and that there is no intent to deceive on their part.

In short, you accused Valve of false attribution, but you have not presented sufficient evidence to support your accusation.

[Kristian Joensen]

2) is completely irrelevant since wheter or not they are allowed to do it is besides the point.

1) is a matter of trust I see no reason to doubt what he says unless Valve can prove otherwise.

"It is entirely possible that the admitted changes were sufficient for Valve to claim the work as their own."

Well then they wouldn't be minor, he said they where minor there is no reason to doubt that.

[Mountain Man]

2) is completely irrelevant since wheter or not they are allowed to do it is besides the point.
If they are allowed to then it is not false attribution and your accusation is false.

1) is a matter of trust I see no reason to doubt what he says unless Valve can prove otherwise.
Sorry, but you can't arbitrarily shift the burden of proof onto Valve. You accused them of false attribution, and unless you can offer sufficient evidence to support your claim (in other words, something other than an anonymous post on a message board run by Quake and id fans) then your accusation is without merit.

Q.E.D.

[Kristian Joensen]

"If they are allowed to then it is not false attribution and your accusation is false."

Nope this is wrong, they are attributing something to themselves instead of id, that is false attribution.

"Sorry, but you can't arbitrarily shift the burden of proof onto Valve."

It is you who are shifting the burden of proof from yourself unto that poster. YOU made a claim namely that he was lying about the extent of the modifications.

"on a message board run by Quake and id fans"

This is not relevant nor is it a bad thing.

[Jokke_r]

it's relevant since he and you are biased.

[Kristian Joensen]

So ? a pro-Quake bias is not the same as a anti-Valve bias and bias doesn't detemine truth.

Also you have yet to show that I have a pro-Quake bias(Which I do) yet alone a anti-Valve bias(Which I don't).

I could also say the same about Mountain Man, he is biased too, so is everybody that does, ever has or ever will live on this planet.

[Opus131]

Nope this is wrong, they are attributing something to themselves instead of id, that is false attribution.


But what should you credit Id soft for?

A modification is only marginally different the writing something from scrap, so even assuming Source it's a Quake based engine (which it isn't) then credit still goes to Valve for doing those modifications.

The only reason Valve kept strands of Quake code within Source is to allow for compatibility with their previous games, and the results have been ample for everybody to see.

Only a die hard Id fanboy would assume Valve simply couldn't rewrite code that has been obsolete for almost a decade and try to attribue Source to anybody else but Valve...

[Kristian Joensen]

I wasn't talking about the Source engine as whole but some specific files that are in the SDK.

[Opus131]

Firefly, it would seem you would disagree with Drazula when he says that lightmaps and bsps where outdated already in 1999, why ? What is your take on that ?

Does anybody need a reason to disagree with Drazula?

[Opus131]

I wasn't talking about the Source engine as whole but some specific files that are in the SDK.

Ok, done. Id soft gets credit for the Quake code found in Source.

Now what?