I've been given permission to make this thread from the mods as a place to talk about valve's next-gen plans. While there is still a thread to talk about the current reality of using steam as a platform
(i.e. a hub for the community to organize games to play online, trade stuff, or announce sales), this thread is more about Valve's vision going forward. This thread could have been called a lot of things given the nature of valve's plans for next-gen gaming and the implications it'll have over PC gaming as a whole, but I figured focusing on SteamOS would best encompass everything they want to do.
I'm making this thread because there is still a ton of confusion about just what valve is planning on offering next gen, what their long-term goals are, what differentiates them from every other platform holder around, and why those who are following what they're doing are so over-the-top excited. Because the playstation 4, xbox one, and WiiU all got deserving "mega"threads leading up to their launch and PC gaming, as a whole, generally gets ignored. Because valve's still in the process of unveiling their next-gen platform and a central repository for news on their platform is logical and helpful. And because, full disclosure, I've hitched all my hopes of the future of gaming to Valve's vision and model.
I'm trying my damnedest to not come off as a frothing fanboy in this topic, but what valve is planning is so unconventional that I feel, to adequately explain the full extent of their next-gen plans, I need to go in depth and explicitly define home entertainment with emphasis on the details that might come off as gushing. You've all been fully warned.
Game Development and Porting games: A brief history
Part of understanding just what valve is attempting to do and how out of the box their conventions are requires one to be familiar with just what goes into game development, both historically and currently, and precisely what a port is and how they are handled. Having frequented many Steam threads across a variety of forums, typically the one who don't understand what is special about valve's proposition also have a shaky grasp on the fundamentals of software design. To make sure everybody is on the same page before we begin discussing valve's plans for steam, I'd like to break down some historical problems with developing for multiple types of hardware at once. I'm going to spoiler this section, as it's mainly primer reading for the rest of this topic, and as such isn't actually on topic itself:
What is a console?
In the past, hardware platforms were massively different from one another, which could complicate development. A Sega Genesis, component for component, was wholely incompatible with a Super Nintendo. Not a single component between the two machines - CPU, video display, audio processor and chip, etc - were cross compatible. When developers made a game for both systems, they'd literally form two entire teams to handle each version of the game, and would build two completely different games for each system. Sometimes the two games they'd build acted very similar to each other, like how NBA Jam on the Genesis, despite having less colors and poorer sound, still looked, sounded, and played like the game that was NBA Jam on the SNES. Sometimes, the two games they'd build would be completely different, as is the case with Sparkster, where the SNES version has different levels, graphics, enemies, bosses, and even gameplay from the Genesis version.
To drive the point home about how different each platform was, even the languages spoken by their processors were completely different. The Opcodes generally the lowest level of machine language programming (literally a set of operations like "divide" or "add" or "move data from register X to register Y" that the CPU can perform), for the Genesis m68k CPU are completely different from the Opcodes for the SNES' 65c816 CPU. This is typical between CPU types, all CPUs have their own internal logic and flags and registers that are setup differently from one another. A RISC processor is a completely different setup from a m68k processor which is different from a PowerPC processor and so forth. Their assembly mnemonics - the closest to english source code that machine language can get - for these opcodes are different too. Without going into a lot of microprocessor assembly, and only to give a real-world example of how drastically different work between two machines could be, here's a quick rundown of the difference between merely adding two numbers together on the Genesis's m68k processor and the SNES 65c816 processor.
first, the genesis had 8 general data registers, d0-d7, which can be thought up as variables. They are, in hardware, where numbers are stored. There are also 8 address registers, a0-a7, which function essentially as pointers, storing memory locations. There are also generally 5 boolean flags that need to be monitored because they'll be set by various operations of the CPU, which are as follows:
C - carry flag, this is set when doing math and one needs to carry a digit during addition and multiplication. So, for example, if you added 19+2, the carry flag would be set because 9+2 carries a 1.
V - overflow flag, set when an overflow has been detected. This can be done for error checking or boundry checking. For example, if you're iterating through a series of values, and you reach the limit of the index, the overflow flag will set. Checking for the overflow flag can let you do things like testing eof.
Z - zero flag. This is set when a mathematical operation has nothing left over. If you do subtraction of 55-5, for example, when it performs the first 5-5, it'll set the zero flag after to let you know that no more operation is left to be done.
N - negative flag. This is set to negate a value. For example, if d0 contains the value 5000 and sets the N flag, then it's read as -5000. If you do a math operation like 5-10 stored into d0, then d0 will read 5 but set the N flag so the answer is actually -5.
X - extend, a complicated flag to understand without really getting into microprocessor assembly. It's generally used to separate bits like a carry flag when doing bitwise operations.
with that in mind, to do a simple addition of 5 plus 5, the genesis code would look something like this
move.b #5,d0 //store 5 in data register 0
move.b #5,d1 //store 5 in data register 1
add.w d0,d1 //add d0 to d1, store in d1, set flags for status
after the last command, d1 would now contain the result of d0 + d1, or 10, and the following flags would be set:
now let's see how you do the same sort of thing on the Super Nintendo. Unlike the genesis, the SNES had 9 specialized registers:
A: Accumulator - this is where the results of arithmetic operations are stored
X, Y: Index registers - these work as a generalize pointer, and can pass memory indexes or data directly
S: Stack pointer - a memory location that points directly to the next available location in stack at all times
DB: Data bank - a general data register
D : Direct Page bank - a place to hold the address of the data being directly accessed by the CPU during direct page mode
PB: Program bank - holds the current program operation to be executed by the CPU
P: Processor status - this behaves like the flags set by the genesis, except they are stored in a register as data to be masked and read rather than a series of boolean values (and there are more flags to be set)
PC: Program counter - the current location of CPU instruction on the rom
now, examining P for flags that can be set (in order they need to be masked to be read):
N: Negative flag - behaves like N on genesis
V: Overflow flag - behaves like V on genesis
Z: Zero flag - behaves like Z on genesis
C: Carry flag - behaves like C on genesis
D : Decimal position - sets the decimal value of a floating point digit, so that if DB is holding 5, the decimal flag can turn it into .5
I: IRQ disable flag - set during v and h blank to monitor interrupt requests
X: Index register size - sets the size of memory index (either 8-bit or 16-bit)
M: Accumulator size - sets the size of the accumulator register (either 8-bit or 16-bit)
because these values are set as masked data, not simple boolean flags, each P value can contain more than simple 1 or 0. The Decimal position value, for example, can specify just how many spaces the decimal position is at.
With that said, the opcode for adding with carrying is different on the SNES than it is on the genesis. We used add.w to add two registers on the genesis. To do the same 5 + 5 addition on the SNES, our code looks like this:
db: #5 sta $0001 //Stores 5 to $0001
db: #5 sta $0002 // Stores 5 to $0002
LDX $0002,Y //load $0002 into index Y
ADC $0001,Y //Add with carry from $0001 to index Y
the last opcode adds with carry from $0001 (5) to index Y (5) with the result, stored at A (10). The following "flags" are set: N, V, Z, C. The others are ignored.
This has all been a quick lesson in how different the underlying logic of different CPUs can be. You see that we're doing the same math - 5+5=10 - on each CPU, but the syntax, the method of actually storing and accessing data, the logic behind how the data is represented, where it's all stored, how it's stored... it's all completely different. Nothing about it is the same.
The reason games could vary so greatly came down to how they were made. In cases where games were very similar across both platforms, the games were generally made for a third, independent standard first, then ported to the genesis and SNES. Using NBA Jam as an example again, the original game was built for an arcade board at Midway. Hence, all the sprites and gamelogic and everything was written for something separate from the SNES and genesis first, and then converted into appropriate approximations. So, somewhere, there is a high quality sprite of scottie pippin in more colors than either the genesis or snes can handle, that they then ran through something like photoshop (or, much more likely, Paint Deluxe) to reduce the color depth into something acceptable for the genesis and then something acceptable for the snes. They already had the logic flow of the game written out somewhere else, so, for example, they might know that "Ok, when the player is holding the turbo button and running down court at 16 units, and hits "shoot" for 5 units, to set the ball's velocity +15 as it travles through the air. So, when porting the game, it's simply a method of re-writing these arithmetic algorithms into something the genesis or SNES can handle. Like I demonstrated above, both consoles can do the same math, they just do it in different ways. In this instance, the "porting" process is mainly on rewriting the math formulas in the correct syntax for the genesis or SNES.
By contrast with Sparkster, there was no single game that was being ported between the two consoles. Since both teams were making wholely independent games to begin with, it didn't really matter if they went in wildly different directions. From the get go, they were making different games.
now, this isn't even an attempt to explain the differences between modern architectures, nor do programmers these days have to constantly deal with these sorts of compatibility issues (because, rarely, are you writing an entire game in assembly these days). Rather, to make life easier for programmers, high-level languages began appearing that would mask the differences between processors. By writing to a specific Application Program Interface, or API, developers can write to an abstraction layer which gets compiled to the appropriate machine language during build. So, again, using the above examples, a programmer could simply write something like this:
a = a+b;
which would get interpreted into the above code for the SNES and Genesis methods of addition. this is the basic premise behind languages and tool sets - a series of small standards that maintain compatibility among a variety of hardwares. I've been describing the difference between talking to CPUs, but this applies to all sorts of hardware, including video cards. That's where OpenGL and DirectX come into play - both are tools used to talk to video cards (among other devices, in directX's case). The onus is then on the group that maintains each API to keep up compatibility among different hardware. SDL, a popular 2D/input API, is notoriously great at getting versions of SDL out working for virtually any type of hardware or operating system. DirectX, by comparison, is proprietary of microsoft, and thus only works on microsoft products and operating systems.
Now, as time has progressed, hardware has begun to standardize, and it's hitting a high point currently. The dominant CPU among next-gen machines is an x86 processor (once called IBM compatible processor). The specific variant is an AMD Jaguar, executing x64 code. The PS4 uses it, as does the xbox one, and virtually every PC in the world. Tablets still mainly use ARM processors, and every now and then you'll run across other processors, but for the main part, x86 is going to be the dominant processor type going forward for gaming. Similarly, modern machines all use common graphics cards, which are widely supported by a number of APIs. In short, the amount of work one has to do to get a game running on one machine vs the other has decreased dramatically, thanks to improved tool sets and convergence of hardware standardization. One console might be less capable than another, but their underlying tech is the same. They can do the same types of things, but maybe one is better at doing this and that compared to the other, if that makes sense.
(incidentally, the WiiU is the odd man out here, using a custom processor design. This is precisely the reason the WiiU is in danger of missing out on ports).
I'd like to think that Valve, being the pragmatic group of geniuses they are, began their quest to define the next iteration of PC gaming by deconstruction what the essence of console gaming is. From the approach valve is taking, they seem to have boiled down what defines a console platform into a variety of components and are, one by one, working their way down this list and producing their own solutions that can be hobbled together. When you stop and think about what precisely differentiates an Xbox One from a Playstation 4, we begin to realize that current gaming machines are more alike than they are different. At a core, a platform can be expected to standardize the following:
All consoles need hardware to run on. Usually, the specifics of the hardware are set so that you can maintain some level of compatibility. In recent years, it's become vogue to have a variety of hardware configurations, so that revision 1 of a console might be less capable than revision 2 of a console or vice versa, but, for the reasons I explained in the porting part of this post, there is usually a level of compatibility across these configurations. So, revision 1 of a console might produce better music than revision 2, but they both operate on the same kind of music.
All consoles have some sort of abstraction between the player and the machine they're interacting with, usually in the form of a controller. There are a variety of input devices, from tablets to cameras to the traditional gamepad. but developers of a console can be reasonably sure that most people using their game will have access to a specific type of input and can expect it to be there. Peripherals which are optional tend to typically become ignored by developers over time as they cannot reliably expect a user to have this input type.
The actual interaction with menus and screen real estate. Early consoles had minimal user interfaces, but they've since become very important. People expect an overlay menu these days that is accessible at a button's press. They expect to be able to navigate every function of their machine from a series of standardized menus. The User Interface is usually tied to the operating system of the machine.
Consoles usually have a form of standardized tool sets available that makes development for said console easy. This is everything from a series of maintained APIs to debuggers to modeling suites.
These four components are ultimately provided by every console on the planet. Typically, each component of a console is a tightly guarded proprietary piece of technology owned by the platform holder. Joe Schmoe, for example, cannot license Microsoft's UI for the Xbox One to use on their machine. Sony probably does not provide an SDK for developing on xbox hardware. Nintendo's UX peripherals will not run on Microsoft's console. That's just how it's gone.
What valve is doing is aiming to provide each piece of the console puzzle, freely and openly, to the general public and even to competition. That's the secret to valve's next-gen plans. They're building a console that can be freely and easily hobbled together, so that gamers will not have to go to Sony to get their UI for a machine they want to build. Here's how each component of Valves's console operates
Steam Machines: The Hardware
Rather than releasing one box, with specs that only they decide, Valve is allowing anybody to piece together their own hardware, provided they fall under an acceptable range of power comparable to what they envision. This is contrast from the way Sony and Microsoft work in that, if you want to play PS4 or Xbone games, you have to buy a machine built by either sony or microsoft. Both companies are enormous with large manufacturing arms. Valve isn't lucky enough to have that sort of ability. Thus, they're relying on other hardware manufacturers to pick up the slack for them. Expect a wide range of steam machines from a variety of manufacturers that all run the same games.
If this sounds familiar, it should, because it's not a new concept. This is precisely how Android works. Valve is betting that companies like Amazon or Toshiba or Samsung or Mitsubishi will be wanting to provide a console box to compete against the xbox one and playstation 4, and because valve is providing all the parts that make up a console, they can do just that.
I routinely see people asking "how is a steam machine different from a PC." That question completely misses the point - a steam machine IS a PC. It's an OEM PC built by a hardware manufacturer, not any different from what you can buy from Alienware or dell or gateway or whatever right now. I see a similar question often repeated: "Why would any PC gamer want to buy a steam machine when they could just build a PC instead?" Again, that misses the point - PC gamers are already steam machine owners. The machines they can build are steam machines. Any PC, provided it's powerful enough, is a steam machine. Valve isn't looking to convert the enthusiast crowd into buying pre-fab boxes from them - they already have them in their fold already. The $1000 box timmy down the street owns and operates is already a part of valve's empire. They're already in the steam machine economy.
The inherent advantage of this model of distribution is the competition it invites. Yes, at launch, these classes of steam machines will likely be much more expensive than their xbone or PS4 counterparts. but they won't always be. So long as the kid down the street has the ability to come in, buy the parts himself, piece together the box, and sell it on his own, he will always be able to threaten to undercut the cost of an OEM box. Similarly, as tech matures, the price of equivalent technology will come down. In 2006, building a PC that would best a PS3 would have cost quite a bit more than a PS3 itself. By 2009, one could pretty easily put together a machine that would run circles around a PS3 for either the same price as a PS3 or, sometimes, for even less. As manufacturers start competing and making OEM mass bundle deals and generally working to provide a cheapest box available, we'll see prices fall.
If one wants a vision into how this hardware incentive might play out, one can look towards android and see how that works out for them. Amazon aggressively pushes their Kindle Fire product, pricing it competitively against the ipad. The kindle is, of course, an android product. I could see a future where Amazon is offering a rival box that can do all the things a PS4 or Xbone can do, only through steam, under the same mentality. I could see TVs with this hardware built in, being sold similar to smartTV technology. I could see cable companies offering settop boxes that are steammachines. The benefit of all this is an economy where all these machines, by different companies and manufacturers, can run the same games. Toshiba doesn't have to lure in developers to make games for their hardware, because, so long as the games run on steam, they'll run on a steammachine.
Steam Controller: The User Experience
Valve is also attempting to provide a standardized controller for their steam economy. The much publicized steam controller attempts to wrap a keyboard and mouse. The end result is a controller which, supposedly, is inherently compatible with any game, regardless of control method. That's the claim, at least. This is the piece of the puzzle that is most open to interpretation because the controller they've designed sounds so unlike any other controller on the market, that nobody really will know how it works until they hold it in their hands.