Shouldn't VALVe work on consolidating Source branches? - Games

Right now it seems like there are a whole bunch of different "current" versions of Source out there and all of them are being given the same amount of attention, when it seems like it would make more sense to bring them all together. [b]Source 2013 SP[/b] - Formerly the "Orange Box" branch, this is for the Half-Life 2 subseries and Portal 1. It's still being updated and it's one of the most basic "current" versions of Source. [b]Source 2013 MP[/b] - TF2, CSS, DOD:S, and HL2:DM. Also the updated version of the Orange Box branch, this one's for all the pre-L4D multiplayer games but remains as basic as 2013 SP even though it's still updated. [b]Source L4D2[/b] - L4D2's engine, taking all the features from L4D1 like fog volumes and the AI Director and adding its own enhancements like flowing water. L4D1's engine has been superseded by this and isn't considered "current" anymore (evidenced by nearly all its content being brought into L4D2.) This and all the following don't require the underlying HL2 code anymore (hence the different executable names.) [b]Source AS[/b] - Apparently some "interim" engine between L4D2 and Portal 2, Alien Swarm's engine is slightly more advanced than L4D2's engine but info is scarce. [b]Source Portal 2[/b] - World portals, video materials, blob particles, but no AI Director or a few other features from the L4D2 and AS branches. [b]Source CS:GO[/b] - Lacks some features from Portal 2's branch like world portals, but apparently does things like real-time shadow maps and ambient occlusion on world geometry. [b]Source DotA 2[/b] - Cloth and other soft-body physics, much more dynamic lighting, and better texture blending. Not even counting the basic "2013" branch, the CS:GO, Portal 2, DotA 2, and L4D2/AS branches all have features that the others lack. Wouldn't it make more sense to consolidate everything so that we don't have to keep dancing around all this fragmentation when making new content? It sucks not being able to use stuff like fog volumes or some of the more advanced lighting while making TF2 levels, for example. I mean, isn't Source supposed to be modular so that we can keep adding new features? Why are some games getting features that others aren't when they're all being worked on concurrently? I mean, I'm not the most Source-savvy person out there (I pulled a lot of this info from the dev wiki), but it seems like a really roundabout way of doing things.

Odds are they're probably more focused on implementing all of those features into Source 2, I guess that would be considered consolidating in a way

I mean, consider this: both L4D1 and L4D2 are for sale on Steam, at the exact same price. Now who in their right mind is gonna buy L4D1 when all of its content (sans Last Stand) has been ported away into L4D2 with its more advanced engine and Workshop support, and even a mode to play everything L4D1 style without any of the new zombies or items? I've long advocated discontinuing the old L4D1 installation and instead have L4D1 and L4D2 purchases unlock the associated campaigns in the current L4D2 engine. I mean, why still segment the userbase at this point? But even then, I realized that literally [i]everyone[/i] with a Steam account has access to the basic Source 2013 branch and SDK, since they come included with TF2 for even free players. And every Source game nowadays requires Steam to function anyway. Wouldn't it make more sense to have one major Source installation alongside (if not a part of) Steam, containing all those modular features so the devs can just update that? Then every Source game can just become a content pack to be plugged into that same engine upon execution, activating the appropriate modules or even using modules they currently can't. World portals in TF2 maps, or a HL2 mod using the AI Director, for example. Wouldn't that make more sense? Besides, isn't that how mods using the Source SDK already do it? Only they're just on the core 2013 branch.

I think it's because source it's a very modular engine, like this: They simply add/remove features to fit they needs, and any modder who wants to create a mod (or third-part game licensing the source engine) can just select the version of the engine who has the most features and it would fit most or have a best use of the tools the branch has (like why an military shooter mod would need portals? or a puzzle game needs an ai director?), and them simply adapt the features the mod/game needs It's like "[I]would be too much work for a problem than doesn't in fact exists"[/I] (I don't know too much so i might be wrong)

I just wished that it was all more organized instead of having a bunch of SDKs (half of which don't work anymore). There are still some very prominent bugs because of Steampipe that haven't been fixed, and it seems they're not being worked on. It would be optimal if there was a single hammer/set of SDK tools that could just have an option for which game you want to work with. Although it's too late now, it would be even better if each game was more of an update to source instead of a separate branch.

[QUOTE=Andre Gomes;42209750]I think it's because source it's a very modular engine, like this: They simply add/remove features to fit they needs, and any modder who wants to create a mod (or third-part game licensing the source engine) can just select the version of the engine who has the most features and it would fit most/ have an best use of the tools the branch has (like why an military shooter mod would need portals? or a puzzle game needs an ai director?), and them simply adapt the features than the mod needs like would be [I]"too much work"[/I] for a problem than doesn't in fact exists (I don't know too much so i might be wrong)[/QUOTE] Well, consider this: right now I'm trying to get back into TF2 mapping and not being able to use entities like fog volumes or the more advanced lighting of some later branches is really annoying and I don't think it's out of the question to ask for TF2 to support things like that. Using the right branch for a mod is all fine and dandy (though even then that doesn't help those who want to use features from two different branches - e.g. AI Director and cloth simulation, which is perfectly reasonable), but it doesn't help those who want to create content for existing VALVe games. And that's not even counting the more creative stuff one would be able to do. What about being able to use world portals to create a non-Euclidean TF2 or Counter-Strike map? Or to help you just test a normal one; as VALVe themselves have stated how useful world portals are as a mapping tool so they can build a map in separate chunks yet test them together in game. And yet even CS:GO - released [i]after[/i] Portal 2 - doesn't have world portals for some reason. They just took it out. Understandable for normal play, but why not just keep it in? Space? I consider it wasteful that right now we're all sitting on multiple Source installations for different games anyway. Plus with SteamPipe (which is supported by nearly [i]all[/i] current branches), it's not even a loading issue anymore since each game already just loads up what's needed. The current way we do things just seems... really inefficient.

A lot of the features you've listed are implemented in the client & server, and not in the engine. Dota, Alien Swarm, and their disparity with 2013 SP/MP are the only valid examples there. Alien Swam makes sense since it was destined to be an SDK, so they had to pick a point to say 'alright, it's ready' and gave it to us before they moved on to what would become Portal 2 / Dota 2 / CS:GO's engine. Same applies to the 2013 SP/MP engines; they're maintaining mod compatibility. Source 2 is their most probable 'feature complete' branch as it stands.

Maybe I'm using the wrong terminology, but you'll see more details on the VALVe Developer Wiki. My point is I would like to see a standardization of these features as they're introduced and a lot less redundancy across games. Source's biggest strong point is that it's so modular and at the very least building all this game content around the same base I imagine would only make things easier for developers and modders so that there's not as much fragmentation. I definitely wish there were a way for me to reach out to VALVe and suggest this at the very least. They never read forums and I doubt they respond to emails.

[QUOTE=VinLAURiA;42210770]Maybe I'm using the wrong terminology, but you'll see more details on the VALVe Developer Wiki. My point is I would like to see a standardization of these features as they're introduced and a lot less redundancy across games. Source's biggest strong point is that it's so modular and at the very least building all this game content around the same base I imagine would only make things easier for developers and modders so that there's not as much fragmentation. I definitely wish there were a way for me to reach out to VALVe and suggest this at the very least. They never read forums and I doubt they respond to emails.[/QUOTE] That's the point I just made; they are all the same base engine, or at least mostly. Features like portals are handled in the client & server, not in the engine.

But what about things like the lighting systems or fog volumes, for example? Looking throughout the dev wiki, there's a lot of things like that - even some functions in the SDK - only available in later branches of the engine. Like [url=https://developer.valvesoftware.com/wiki/Prop_dynamic]here[/url]. Why are those last four values only in the Alien Swarm or Portal 2 branches?

[QUOTE=fireball397;42209597]Odds are they're probably more focused on implementing all of those features into Source 2, I guess that would be considered consolidating in a way[/QUOTE] Ah, man. What if Source 2 is just all the current sources put together? :c I know pepper. It would be fucking dumb.

It would be nice that if you simply save a vmf in one version of hammer it doesn't crash when loading with the others. I switched a map from 2013 to SFM hammer because if HDR issues and I can't open it at all because of the changes in the way entities are stored. If I were to push that map into an in-game environment for testing/cubemap compiling, I now have to load it in alien swarm or portal 2, neither of which are ideal for the SP FPS environment I want to have. It would be nice to at least push all the BSP formats to a unified system so you don't accidentally break things by simply saving in some cryptic subversion of hammer. I could make the same argument about studiomdl, but if you compile a simple model in source 2013's version then it's mostly guaranteed to load in everything (unless you need complex features and/or are working with dmx)

The real answer is that merging these engines back together again would be hell. They've been diverging for too long, so each branch has built up tons of changes which are incompatible with the other branches. Trying to merge them together again would resolve in an unholy broken mess that would take a huge amount of effort to fix into a working engine. I can see why they did it this way; if you're building a new product, you don't want to merge the breaking changes you're making to a new product back into updates for the ongoing support of an old product, so by necessity, the two forks start to diverge. This is one of those problems that isn't readily solved by modularity, because the modules co-evolve. The couplings between modules can, and indeed must, change over time. The TF2 game code co-evolved with the 2013 engine branch, for instance, and so the TF2 game code wouldn't be forwards-compatible with the Portal 2 branch. In principle you can manage the project in such a way that you can minimise these sorts of problems, but they have their own trade-offs. You'd have to spend a lot more time worrying about interface versioning and all sorts of things like that, and you'd have to be merging on a practically daily basis to bring changes from one branch forward. You'd probably end up maintaining two versions of TF2, one against the currently shipping public engine version and another against the internal engine version, so that you could smoothly roll TF2 over to the new engine when Portal 2 comes out.

[QUOTE=fireball397;42209597]Odds are they're probably more focused on implementing all of those features into Source 2, I guess that would be considered consolidating in a way[/QUOTE] I'd hope so, as well as some new features like larger map limits. Imagine playing a full game without loading screens.

You missed the SiN Episodes branch. It's Post EP1 with some improved lighting elements and some type of hybrid animated physics too. But it's before Orangebox. It was recently converted to steampipe but I don't think the engine has changed and it has no working SDK Tools (It's MumboJumbo's job to supply them, like hell are they ever going to fix it.)

[QUOTE=ViralHatred;42247659]It's Post EP1 with some improved lighting elements and some type of hybrid animated physics too. But it's before Orangebox.[/QUOTE] Pretty sure it was Source's physics but with a bunch of nVidia shit like boob jiggles and cloth swinging lazily and unclothlike.

[QUOTE=ViralHatred;42247659]You missed the SiN Episodes branch. It's Post EP1 with some improved lighting elements and some type of hybrid animated physics too. But it's before Orangebox. It was recently converted to steampipe but I don't think the engine has changed and it has no working SDK Tools (It's MumboJumbo's job to supply them, like hell are they ever going to fix it.)[/QUOTE] SiN Episodes is a third-party branch; not related to Valve's branches.

[QUOTE=ColossalSoft;42248932]Pretty sure it was Source's physics but with a bunch of nVidia shit like boob jiggles and cloth swinging lazily and unclothlike.[/QUOTE] Boob jiggling was animated and not real time. The animated/hybrid physics was related mostly to gibbing such as a watercooler being broken. Also while this may be a "third-party branch" several Valve updates have affected it in the past. Most noticeably additions to Valve's SDK has broken the SiN Episodes SDK 3 times each progressively getting worse.

Right now, there are only really two that are still maintained, 2013 and Dota 2, I guess you could possibly could L4D2.

i was wondering, since this discussion is most likely headed for Source 2, will Valve retain the .bsp file format? would we still have to make maps using brushes for basic geometry, and models for complex ones? ofc they'd have to ramp up Source's visuals and streamline the toolset, but fundamentally will source 2 be the same engine as source is?

And then, of course, there's Titanfall and its heavily modified iteration of the Source engine.

[QUOTE=VinLAURiA;42210840]But what about things like the lighting systems or fog volumes, for example? Looking throughout the dev wiki, there's a lot of things like that - even some functions in the SDK - only available in later branches of the engine. Like [URL="https://developer.valvesoftware.com/wiki/Prop_dynamic"]here[/URL]. Why are those last four values only in the Alien Swarm or Portal 2 branches?[/QUOTE] prop_dynamic and the global entity flags are outside of the engine; it's client/server code only. The lighting system used in DOTA is shared with CS:GO (And an early version is present in ASW), and most likely all future source engine games. They use the same engine branch. Fog volumes are client/server code. Valve adds them as needed. They aren't in the engine.

Vindictus had some really nice clothe physics.

Seems to me, that the branches of the source engine have undergone all the necessary steps of specialization. There's been a variation within the branches, geographic isolation as the engine moves into different territory/genres, a selective pressure (the mechanics needed for each game), and finally reproductive isolation due to the differences becoming greater. Or maybe I'm just talking out my ass.

[QUOTE=1/4 Life;42261500]prop_dynamic and the global entity flags are outside of the engine; it's client/server code only. The lighting system used in DOTA is shared with CS:GO, and most likely all future source engine games. They use the same engine branch. Fog volumes are client/server code. Valve adds them as needed. They aren't in the engine.[/QUOTE] Well, then what exactly is keeping them from bringing this updated code back into older branches?

[QUOTE=VinLAURiA;42262937]Well, then what exactly is keeping them from bringing this updated code back into older branches?[/QUOTE] The fact that Valve's already working - post payroll-trimming - at full tilt, I suppose. Hell if I'm about to read the tea-leaves not only within the mind of Gabe, but any other individual who could possibly break out and decide (even within a seasonal frenzy) to whip up a team to do just that.

[QUOTE=VinLAURiA;42262937]Well, then what exactly is keeping them from bringing this updated code back into older branches?[/QUOTE] Valve's always been a company of necessity. If they don't need it explicitly for what they're trying to do they won't add it. It's a waste of their time and may or may not break existing content or mods.

Don't forget about Kuma Games' games.