Valve talks Half Life 2 modding! feature

Cheers goes out to Pcgnetworks.com whom hosted the IRC channel conducting the discussion

@valve-gabe: The blades cutting zombies in half is physics and AI as well. They've been modelled so they can be cut in half, but other than that they walk into the blades and the physics causes damage and they get split in half.
@valve-gabe: Vehicles are mod'able.
@valve-gabe: You can create wheeled vehicles, or flying & hovering vehicles.
@valve-gabe: We'll ship all of the HL2 AI code to mod authors as a reference for creating their own AIs with physics behavior.
@valve-gabe: Some of HL2's NPCs use physics as their basis of movement and interaction with the world.
@valve-gabe: The AI has lots of interactions with physics. You can control the AI collisions and collision response, navigation around/with physics objects, and specific behaviors involving physics (exerting forces on objects, etc).
@valve-gabe: Alot of people have asked about fluid simulation in Source. We simulate objects moving through fluids with surface fluid pressue and buoyancy. We don't simulate the fluid itself, but floating works automatically based on the density & volume of the objects and the fluid (all masses & densities of objects & fluids are scriptable).
@valve-gabe: The zombie is aware of objects in the environment. His AI realizes when he can throw an object at you and applies the appropriate physics forces to make it happen. The zombies are not scripted to throw specific barrels; it's all tactical.
@valve-gabe: The tradeoffs between the two models are the accuracy of the simulation at the wheels. You can trade less accurate wheel collisions/response for less CPU time. You can do several vehicles with the full simulation on our target machines, but you can always use the CPU for something else if the wheel simulation isn't as important to your mod.
@valve-gabe: "What was the polycount on the driveable buggy?" Currently it's a bit heavy at around 12000 triangles. It's going to get a reduced before the game is done.
@valve-gabe: Weapons have two models - the in-view model and the world model (seen in 3rd person).
@valve-gabe: You can set a separate FOV to render the in-view model if you'd like. Our artists find it easier to get the weapons to look the way they want with this feature.
@valve-gabe: "How do I convert my Half-Life mod to Half-Life 2?" Models, animations, and textures just need to be compiled with the new tools. The maps can be loaded into Hammer and saved in the new format (VMF). The code should be pretty familiar to Half-Life mod authors, but there is some porting of the code as some specific engine features are implemented differently usually - much more generally.

@valve-david: Map editing for the Source engine will be very familiar to those who did mapping for Half-Life. We've always tried to extend rather than reinvent whenever possible. The main challenge will be digesting all the new tools and capabilities to get the most out of them.
@valve-david: The rough structure of the map is still BSP-based, built from brushes, but the details are fleshed out with more props that are built in XSI, Maya, or Max.
@valve-david: AIs are aware when squad members die.
@valve-david: People have asked about entity system changes...
@valve-david: Entity I/O is the way entites are connected in the Source engine. It's essentially an interobject messaging system. When certain internal events occur, an entity can fire outputs, which can be connected to inputs of other entities.
@valve-david: 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.
@valve-david: Next question?
@valve-david: 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. This can all be hooked up by the level designer in Hammer, so you have a lot more power for building things.
@valve-david: As for key new features in Hammer -- please ask for clarification on any of these -- entity I/O, displacement surfaces, hierarchical visgroups, HL1 -> HL2 conversion path, per-face luxel density with preview, smoothing groups for brushes, graphical/editing helpers: radius, lightcone, line, text based, extensible VMF file (no more RMF versioning!)
@valve-david: You create a brush, and can tesselate any four-sided face or faces to up to 17x17 verts.
@valve-david: More entity stuff: Hierarchy is a way of attaching entities to each other so that they move together despite being of different entity types. For example, you can have a func_rotating in hierarchy with a func_tracktrain to give the train a rotating part, or you can parent a breakable window pane to the train.
@valve-david: 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!
@valve-david: What role will Steam play in the mod community? First, it's a great development tool for running betas, rolling changes, getting instant feedback, etc. Second, it will improve the distribution problem -- your mod will be played by more people. Finally, it will introduce a more direct path to consumers for those who want to take their mod into the commercial space.
@valve-david: Back to changes to the map production process: we have found that a large part of the cost of creating a Half-Life 2 quality level is in the art production process. Building all the props and textures required for the level of visual quality people saw at E3 consumes a lot of man-hours. As for building a Half-Life 1 quality map in the Source engine, the new tools and entity I/O makes it go much faster than it did on HL1.

@valve-yahn: For artists, we currently have exporters for XSI, 3dsmax and Maya
@valve-yahn: A lot of people have asked about the networking system and how flexible it is. Here's some of the new stuff:
@valve-yahn: Second, you can write custom data proxy code to massage data values into more network values on the fly
@valve-yahn: Third, you have all of the low level prediction code exposed to you in the client .dll and you have all of the server-side lag compensation code exposed to you in the game .dll
@valve-yahn: Fourth, there are a bunch of useful new diagnostic modes to show you when things mis-predict and help you track down inconsistencies between the client and server versions of things
@valve-yahn: Also, entities that go out of the PVS on the client are no longer destroyed and recreated upon re-entry to the PVS. The entities live continously on the client. In fact, you can create additional purely client side entities and have them simulate completely locally, too.
@valve-yahn: If you're familiar with the HL1 SDK code, there's now a C_BaseEntity on the client which matches the CBaseEntity on the server in almost all ways.
@valve-yahn: All of the vehicle code is in the game and client .dlls and there's a seperate set of script files which modmakers can create and tweak. We allow for NPCs/AIs to drive the vehicles.
@valve-yahn: You also have full control over the rendering loop and could even insert your own rendering primitives ( as long as you ultimately end up rendering triangles... )
@valve-yahn: A bunch of people have emailed me the following question: How would I use Source to create a BF1942-like game? Okay, here goes:
@valve-yahn: First, BF1942 has pretty large maps, so you'd probably want to scale your units down to allow for a multiple mile x mile playing field
@valve-yahn: 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 seemlessly transition indoors. I'm excited to see the mods go nuts on this stuff.
@valve-yahn: We have a really neat tool called the "Half-Life Face Poser" which allows you to control all of the facial muscles on our humanoids' (could be faces on Alien legs in a mod though...) faces. In particular, you can store set poses as facial expressions or you can animate the face muscles in timing curves. These primitives can be placed together on a timeline to have your actors act out a scene
@valve-yahn: We've also collapsed the notion of cvars and commands into a root console primitive, the "ConCommand". Cvars and commands are defined in a single line, so there's no more registration system as well. The whole console autocomplete logic is mod-extensible.
@valve-yahn: Entro|Prozac: LOD's are defined by a set number of static mesh LOD's set in the qc based on distance. So yes if you desired 8 levels you could do so. Primarily we shoot for 3 or 4.
@valve-yahn: Finally, we have another built in tool called the "Demo Smoother". This tool allows for completely re-authoring the camera track of a demo as a post-process. The tool allows for placement of a spline for the camera and then computes the correct camera position and orientation based on the spline positions and quaternions.
@valve-yahn: You can also draw 3d things into vgui panels so you can put a rotating model inside your menu. Also, you can have a vgui panel in your 3d world which you can manipulate so you can have an object in the world containing your menus, etc.
@valve-yahn: What are the capabilities of VGUI2? First, vgui2 is much more robust and feature complete than the original vgui in HL1. We've added systems to allow script files to dynamically animate the positions and other variables in VGUI2 panels. Mods will also have source code to all of the default controls.
@valve-yahn: How different is the console in Source? The console is now a separate VGUI window. We still support "aliasing". One of the cooler features we've added is the ability to do full command completion. We do this with the map command, e.g., where as you type, we scan the Hard Disk looking for available maps. This saves a fair bit of typing :)

@valve-gary: On budgets: Our budgets are time based. We've set target machine specs and target framerates, and we give the level designers framerate targets.
@valve-gary: "How much control do modders have over rendering?" You have access to the material system from the client dll. You can render anything that is rendered anywhere else in the game. You also will be able to write your own shaders that are accessed by the materal system. Without making new shaders, the existing shaders can be tweaked with scriping in vmt (material) files.
@valve-gary: "Can I put normal maps on everything?"
@valve-gary: In dx8, you can put specular normal maps on all models, and you can put diffuse and specular normal maps on world geometry (including displacement maps).
@valve-gary: In dx9, you can additionally put diffuse normal maps on models.
@valve-gary: "How would I do cel shading with Source?"
@valve-gary: You would write your own vertex/pixel shader combination for a new custom shader and then use that shader in your materials that you want to be cel shaded.
@valve-gary: "Are shaders based on PS1.0 or PS2.0? What about old hardware that doesn't have pixel shaders?"
@valve-gary: Shaders are ps1.1, ps1.4, or ps2.0 depending on what hardware you are running on. You can also code up fixed-function shaders for older hardware if you wish.
@valve-gary: "What's the strategy for scalability?"
@valve-gary: All models are LOD's discretely. You can make lower-end versions of the models as necessary. Displacement maps are simpler on the lowend. You can also tag entities as only showing up on specific dx-levels in the maps. On the lowend, you get less lightmap resolution. As for shaders, shaders typically fallback from complex normal-mapped, specular shaders to single pass simple shaders on the lowend.
@valve-gary: "What about FSAA?" - Anti-aliased has been fixed on all cards.
@valve-gary: "Do you use HLSL or Cg for your dx9 shaders?" - HLSL.
@valve-gary: Anti-aliasing has been fixed for all cards.
@valve-gary: "Will there be a benchmarking routine in HL2?"
@valve-gary: Yes. There is a detailed benchmark released before the game ships where you can run a particular card through any of the DirectX levels where appropriate.
@valve-gary: "How do 3d skyboxes work? Can I animate a skybox?"
@valve-gary: The 3d skybox is a part of the level at a different scale that the rest of the level. You can place entities in the 3d skybox (like flying objects, etc). There is a "normal" skybox on the outside of the 3d skybox as well. We also have animated cloud layers, and I could see a mod going nuts with this. That would be great!
@valve-gary: "How can we use Steam to deliver card-specific resources?"
@valve-gary: We can deliver special versions of content to users with particular hardware based on the hardware that they have in their machines. Using this, you could conceivably make a mod that really pushes the limit of hardware and requires specific hardware to run. With the flexibility that you'll have with rendering, I could see mod makers go nuts with this.
@valve-gary: "What's the replacement for r_speeds?"
@valve-gary: There is a new system for budgetting that shows where time is being spent in the code at a high level. We are setting framerate targets for different levels of harware capability. The display of the budgetting info is in the format of a graphics equalizer-like view of where time is being spent. This gives you a good view of where you are getting spikes, and the average perf.
@valve-gary: "What's the most complex shader that you've written."
@valve-gary: As far as rendering complexity, probably the fully generic diffuse and specular bump mapped shader that we use on models. Some other complex ones are the refraction effects (like the Gordon stained glass in the E3 demo) and a camoflaged model shader.

@valve-chrisb: Prozac, if you're refering to maintaining a collection props, all of the HL2 props will be usable by the community. I will probably setup sometype of storage site for quality community created props as well.
@valve-chrisb: (by props, i'm referring to models)
@valve-david: Were the I-beams and dumpster in the trap town demo scripted or physics + AI? They were all AI, we just hinted for the soldiers to stand in opportune spots so they could get smashed by the heavy physics objects. :)

[page=Messy transcript]
@valve-david: Map editing for the Source engine will be very familiar to those who did mapping for Half-Life. We've always tried to extend rather than reinvent whenever possible. The main challenge will be digesting all the new tools and capabilities to get the most out of them.
@valve-gabe: Vehicles are mod'able.
@valve-david: The rough structure of the map is still BSP-based, built from brushes, but the details are fleshed out with more props that are built in XSI, Maya, or Max.
@valve-gary: On budgets: Our budgets are time based. We've set target machine specs and target framerates, and we give the level designers framerate targets.
@valve-yahn: All of the vehicle code is in the game and client .dlls and there's a seperate set of script files which modmakers can create and tweak. We allow for NPCs/AIs to drive the vehicles.
@valve-david: AIs are aware when squad members die.
@valve-gary: "How much control do modders have over rendering?" You have access to the material system from the client dll. You can render anything that is rendered anywhere else in the game. You also will be able to write your own shaders that are accessed by the materal system. Without making new shaders, the existing shaders can be tweaked with scriping in vmt (material) files.
@valve-david: People have asked about entity system changes...
@valve-david: Entity I/O is the way entites are connected in the Source engine. It's essentially an interobject messaging system. When certain internal events occur, an entity can fire outputs, which can be connected to inputs of other entities.
@valve-gary: "Can I put normal maps on everything?"
@valve-gary: In dx8, you can put specular normal maps on all models, and you can put diffuse and specular normal maps on world geometry (including displacement maps).
@valve-gary: In dx9, you can additionally put diffuse normal maps on models.
@valve-yahn: You also have full control over the rendering loop and could even insert your own rendering primitives ( as long as you ultimately end up rendering triangles... )
@valve-david: 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.
@valve-gabe: You can create wheeled vehicles, or flying & hovering vehicles.
@valve-david: Next question?
@valve-david: 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. This can all be hooked up by the level designer in Hammer, so you have a lot more power for building things.
@valve-yahn: For artists, we currently have exporters for XSI, 3dsmax and Maya
@valve-yahn: A lot of people have asked about the networking system and how flexible it is. Here's some of the new stuff:
@valve-gabe: The AI has lots of interactions with physics. You can control the AI collisions and collision response, navigation around/with physics objects, and specific behaviors involving physics (exerting forces on objects, etc).
@valve-gary: "How would I do cel shading with Source?"
@valve-gary: You would write your own vertex/pixel shader combination for a new custom shader and then use that shader in your materials that you want to be cel shaded.
@valve-yahn: Second, you can write custom data proxy code to massage data values into more network values on the fly
@valve-yahn: Third, you have all of the low level prediction code exposed to you in the client .dll and you have all of the server-side lag compensation code exposed to you in the game .dll
@valve-gabe: Some of HL2's NPCs use physics as their basis of movement and interaction with the world.
@valve-yahn: Fourth, there are a bunch of useful new diagnostic modes to show you when things mis-predict and help you track down inconsistencies between the client and server versions of things
@valve-gabe: We'll ship all of the HL2 AI code to mod authors as a reference for creating their own AIs with physics behavior.
@valve-gary: "Are shaders based on PS1.0 or PS2.0? What about old hardware that doesn't have pixel shaders?"
@valve-gary: Shaders are ps1.1, ps1.4, or ps2.0 depending on what hardware you are running on. You can also code up fixed-function shaders for older hardware if you wish.
@valve-david: As for key new features in Hammer -- please ask for clarification on any of these -- entity I/O, displacement surfaces, hierarchical visgroups, HL1 -> HL2 conversion path, per-face luxel density with preview, smoothing groups for brushes, graphical/editing helpers: radius, lightcone, line, text based, extensible VMF file (no more RMF versioning!)
@valve-yahn: Also, entities that go out of the PVS on the client are no longer destroyed and recreated upon re-entry to the PVS. The entities live continously on the client. In fact, you can create additional purely client side entities and have them simulate completely locally, too.
* Halfrules|Berserk (~Berserk@43.Red-80-24-233.pooles.rima-tde.net) Quit (Signed off)
@valve-yahn: If you're familiar with the HL1 SDK code, there's now a C_BaseEntity on the client which matches the CBaseEntity on the server in almost all ways.
@valve-gary: "What's the strategy for scalability?"
@valve-gary: All models are LOD's discretely. You can make lower-end versions of the models as necessary. Displacement maps are simpler on the lowend. You can also tag entities as only showing up on specific dx-levels in the maps. On the lowend, you get less lightmap resolution. As for shaders, shaders typically fallback from complex normal-mapped, specular shaders to single pass simple shaders on the lowend.
@valve-gary: "What about FSAA?" - Anti-aliased has been fixed on all cards.
@valve-gary: "Do you use HLSL or Cg for your dx9 shaders?" - HLSL.
@valve-david: You create a brush, and can tesselate any four-sided face or faces to up to 17x17 verts.
@valve-yahn: A bunch of people have emailed me the following question: How would I use Source to create a BF1942-like game? Okay, here goes:
@valve-gabe: Alot of people have asked about fluid simulation in Source. We simulate objects moving through fluids with surface fluid pressue and buoyancy. We don't simulate the fluid itself, but floating works automatically based on the density & volume of the objects and the fluid (all masses & densities of objects & fluids are scriptable).
@valve-gary: Anti-aliasing has been fixed for all cards.
@valve-yahn: First, BF1942 has pretty large maps, so you'd probably want to scale your units down to allow for a multiple mile x mile playing field
@valve-david: More entity stuff: Hierarchy is a way of attaching entities to each other so that they move together despite being of different entity types. For example, you can have a func_rotating in hierarchy with a func_tracktrain to give the train a rotating part, or you can parent a breakable window pane to the train.
@valve-gabe: The zombie is aware of objects in the environment. His AI realizes when he can throw an object at you and applies the appropriate physics forces to make it happen. The zombies are not scripted to throw specific barrels; it's all tactical.
@valve-yahn: 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 seemlessly transition indoors. I'm excited to see the mods go nuts on this stuff.
@valve-gabe: The blades cutting zombies in half is physics and AI as well. They've been modelled so they can be cut in half, but other than that they walk into the blades and the physics causes damage and they get split in half.
@valve-gary: "Will there be a benchmarking routine in HL2?"
@valve-gary: Yes. There is a detailed benchmark released before the game ships where you can run a particular card through any of the DirectX levels where appropriate.
@valve-david: 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!
@valve-gary: "How do 3d skyboxes work? Can I animate a skybox?"
@valve-gary: The 3d skybox is a part of the level at a different scale that the rest of the level. You can place entities in the 3d skybox (like flying objects, etc). There is a "normal" skybox on the outside of the 3d skybox as well. We also have animated cloud layers, and I could see a mod going nuts with this. That would be great!
@valve-yahn: Finally, we have another built in tool called the "Demo Smoother". This tool allows for completely re-authoring the camera track of a demo as a post-process. The tool allows for placement of a spline for the camera and then computes the correct camera position and orientation based on the spline positions and quaternions.
@valve-gary: "How can we use Steam to deliver card-specific resources?"
@valve-gary: We can deliver special versions of content to users with particular hardware based on the hardware that they have in their machines. Using this, you could conceivably make a mod that really pushes the limit of hardware and requires specific hardware to run. With the flexibility that you'll have with rendering, I could see mod makers go nuts with this.
@valve-yahn: We have a really neat tool called the "Half-Life Face Poser" which allows you to control all of the facial muscles on our humanoids' (could be faces on Alien legs in a mod though...) faces. In particular, you can store set poses as facial expressions or you can animate the face muscles in timing curves. These primitives can be placed together on a timeline to have your actors act out a scene
@valve-gabe: The tradeoffs between the two models are the accuracy of the simulation at the wheels. You can trade less accurate wheel collisions/response for less CPU time. You can do several vehicles with the full simulation on our target machines, but you can always use the CPU for something else if the wheel simulation isn't as important to your mod.
@valve-yahn: We've also collapsed the notion of cvars and commands into a root console primitive, the "ConCommand". Cvars and commands are defined in a single line, so there's no more registration system as well. The whole console autocomplete logic is mod-extensible.
@valve-david: Back to changes to the map production process: we have found that a large part of the cost of creating a Half-Life 2 quality level is in the art production process. Building all the props and textures required for the level of visual quality people saw at E3 consumes a lot of man-hours. As for building a Half-Life 1 quality map in the Source engine, the new tools and entity I/O makes it go much faster than it did on HL1.
@valve-yahn: Entro|Prozac: LOD's are defined by a set number of static mesh LOD's set in the qc based on distance. So yes if you desired 8 levels you could do so. Primarily we shoot for 3 or 4.
@valve-gary: "What's the replacement for r_speeds?"
@valve-gary: There is a new system for budgetting that shows where time is being spent in the code at a high level. We are setting framerate targets for different levels of harware capability. The display of the budgetting info is in the format of a graphics equalizer-like view of where time is being spent. This gives you a good view of where you are getting spikes, and the average perf.
@valve-gary: "What's the most complex shader that you've written."
@valve-gary: As far as rendering complexity, probably the fully generic diffuse and specular bump mapped shader that we use on models. Some other complex ones are the refraction effects (like the Gordon stained glass in the E3 demo) and a camoflaged model shader.
@valve-gabe: "What was the polycount on the driveable buggy?" Currently it's a bit heavy at around 12000 triangles. It's going to get a reduced before the game is done.
@valve-yahn: How different is the console in Source? The console is now a separate VGUI window. We still support "aliasing". One of the cooler features we've added is the ability to do full command completion. We do this with the map command, e.g., where as you type, we scan the Hard Disk looking for available maps. This saves a fair bit of typing :)
@valve-chrisb: Prozac, if you're refering to maintaining a collection props, all of the HL2 props will be usable by the community. I will probably setup sometype of storage site for quality community created props as well.
@valve-chrisb: (by props, i'm referring to models)
@valve-david: What role will Steam play in the mod community? First, it's a great development tool for running betas, rolling changes, getting instant feedback, etc. Second, it will improve the distribution problem -- your mod will be played by more people. Finally, it will introduce a more direct path to consumers for those who want to take their mod into the commercial space.
@valve-gabe: "How do I convert my Half-Life mod to Half-Life 2?" Models, animations, and textures just need to be compiled with the new tools. The maps can be loaded into Hammer and saved in the new format (VMF). The code should be pretty familiar to Half-Life mod authors, but there is some porting of the code as some specific engine features are implemented differently usually - much more generally.
@valve-yahn: What are the capabilities of VGUI2? First, vgui2 is much more robust and feature complete than the original vgui in HL1. We've added systems to allow script files to dynamically animate the positions and other variables in VGUI2 panels. Mods will also have source code to all of the default controls.
@valve-david: Were the I-beams and dumpster in the trap town demo scripted or physics + AI? They were all AI, we just hinted for the soldiers to stand in opportune spots so they could get smashed by the heavy physics objects.
@valve-yahn: You can also draw 3d things into vgui panels so you can put a rotating model inside your menu. Also, you can have a vgui panel in your 3d world which you can manipulate so you can have an object in the world containing your menus, etc.
@valve-gabe: Weapons have two models - the in-view model and the world model (seen in 3rd person).
@valve-gabe: You can set a separate FOV to render the in-view model if you'd like. Our artists find it easier to get the weapons to look the way they want with this feature