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:
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.
Genesis:
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:
C: true
V: false
Z: true
N: false
X: false
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:
int a=5;
int b=5;
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).
What is a console?
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:
Hardware:
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.
User Experience:
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.
User Interface:
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.
SDK
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.
Posts
SteamOS: The User Interface
SteamOS is really the heart of valve's next-gen initiative, even more so than the physical steam machines themselves. SteamOS is the key piece that makes everything happen, really. SteamOS looks like it'll be a freely available operating system that aims to provide everything people expect from a box under their TV, along with providing a method of delivery. SteamOS is more than simply a series of menus, it's an entire platform. This bundles together a web interface for a store along with various hardware abstractions. It's the piece people will download to turn their normal PC into a steammachine. It's a completely independent version of steam. This way, people don't need to add 'the windows tax' to a build. Toshiba doesn't have to try and negotiate with microsoft to license their operating system to build a competitor to their xbox one. Anybody can use it, and anybody can modify it. Just like how Amazon modifies the stock android rom to provide an amazon-themed version of android for the kindle, so can they do the same thing with Steam. What this means is that any person wanting to build their own console can do so. They can download a common interface, tweak it to their liking, and run it. Add in a desktop environment if you'd like.
Going far back, valve has been pretty open about allowing competitors to build rival ventures out of their own technology. This is a key difference between the steam store and stuff you get from microsoft, nintendo, or sony. If you want to buy a Sony digital game, for example, you have to buy it through sony's playstation store. All digital sony sales go through sony. It's possible to buy a Steam-compatible game without giving valve a dime, however. GoG, Amazon, and GMG, for example, all provide Steam-compatible games, and their sales do not go through valve. That means if I, a developer, have a game that I want to sell, and valve offers to sell my game through steam where I can keep $0.70 on the dollar, and amazon will let me offer the same game for the same price, but I keep $0.80 on the dollar, I am free to go with amazon and make more profit. Or I can go with both. Or neither. I can side load an application, completely bypassing valve. All this will be possible from SteamOS. You will be able to buy products from anywhere, not just their own locked down, proprietary store. And they're aiming to make the software they built to power their store freely available to competitors, so they can build their own storefronts too.
Going back to that example of a settop box provided by a cable company - imagine a comcast version of the steammachine that, when you turn it on, has a built in comcast store. Comcast can offer games and you can buy them directly through comcast, like on-demand games. Or, to make a more palpitable comparison, notice the way every phone manufacturer comes with a proprietary MP3 store attached to the service. Of course itunes and amazon exists, but if you get your cell phone service through sprint, you might have sprint zone pre-loaded, a special sprint run store where they sell mp3s. In the end, it's all the same technology - all the same MP3s. but you have a variety of choices about where to buy from. They all work on any device, but they're provided by a variety of outlets. This empowers the consumer. this is a good thing, for both developer and consumer. It's the way a free, open market should operate.
SteamWorks GameWorks: The SDK
So, what makes valve's approach to the console game so unique is that the steam machines they're looking to provide are just one venue for their platform. Valve's emphasis isn't to get people off of windows and onto Linux, or onto OSX, or whatever - it's to get people onto SteamWorks GameWorks. SteamWorks GameWorks, under this initiative, is evolving into a total SDK, a powerful API to aid cross-platform development. That's the ultimate goal. Going back to the subjects I touched upon at the beginning of this post about high level programming and portability, SteamWorks GameWorks aims to provide an alternative to DirectX and SDL and OpenGL and all these other APIs that worked really on only certain subsets of hardware. Ideally, Valve sees SteamWorks GameWorks as a universal middleman. They'll produce a version of SteamWorks GameWorks for Linux, and there are already versions of it for windows and OSX. The goal is that you will be able to write one game, one application, that will run on any x86 processor with whatever video card configuration, so long as that platform runs SteamWorks GameWorks.
That is the revolutionary part of their plan. Imagine a world where one game is written and it work on Windows, Mac, Linux, even stuff like the playstation 4 and xbox one. Imagine a free set of tools and engines that will empower developers to target virtually every box under the sun, flying their games under the universal banner of "SteamWorks GameWorks games." The trick isn't getting people to start making games for linux. it's not to get them to leave windows development (and thus hundreds of millions of users). The trick is to make linux development and windows development concurrent and the porting process between OSes invisible to the developer. Just write a single game, and it works.
This is all similar to what AMD is trying to do with Mantle as well, and I would think valve has no problem with mantle. The issue isn't that they want their API to rule the world, it's that they want people to start using an API that is cross-compatible with a variety of operating systems, regardless of who maintains it. Mantle's success would be a boon to Valve provided it has SteamOS support.
Virtual Reality
One other major component of valve's next-gen plans is their still unannounced virtual reality initiative. It's the worst kept secret in the industry that Valve is looking to push VR very hard going forward. They may position their steam machines platform as being the first to offer VR. Luckily, penny-arcade has a huge, robust topic centering around Virtual Reality development if this is your subject of interest.
Going forward
There are those who will see all this and ask why I'd believe this is the future of home entertainment. It doesn't really offer anything that the PS4 or Xbone don't offer, merely an alternative. Why does it instill confidence in me? Again, I look at android and the x86 processor in general. As a pretty big android supporter, I recognize that it won its support by essentially being the cheap knockoff on the market. It was the cheaper, mass produced alternative to iOS that every other manufacturer who wasn't apple could use to provide parity. It was the phone OS that could do enough of what iOS could do, that could be purchased in a $50 phone over a $500 iphone. The SteamOS doesn't need to do more than xbone and PS4 to succeed. it just needs to do enough of what they do, under a model that will allow them to be the fallback option for every manufacturer out there that isn't nintendo, sony, or microsoft. And they've done just that.
Today, the x86 architecture is about to secure a victory as the dominant non-mobile processor type. It did this by being the most widely cloned CPU on the market. In an age where PowerPC and m68k and all the other processors were proprietary, AMD cloned intel's design and started providing cheap, mass produced "IBM compatible PC clones." And that's how it won the market. the Amiga and Apple II provided considerably better UX and UI designs compared to pure DOS that ran on an IBM compatible, but they weren't able to be mass produced on the cheap by rival manufacturers. IBM compatibles were.
This is an ancient video game philosophy. it's not much different from the 3DO, and people have pointed that out. The 3DO didn't fail because the concept was flawed, it failed because it lacked a big muscle backer and struggled to find an audience. Steam already has both of these. It's always been dumb to me that we buy sony games for sony machines and microsoft games for microsoft machines, even if they're the same game. It makes much more sense to simply buy games, period, and having confidence that they will work with the games hardware you have. That's the future valve is working towards.
Discuss.
EDIT: After a bit more research, it appears Valve's API is developing under the name GameWorks, not evolving the existing SteamWorks API.
but the washington post luckily did an excellent write up on precisely that component of valve, so I'll just link it here instead and urge everybody to read it. The OP is why valve is something to be considered in the hardware space. This article is why valve must be considered as a software company: http://www.washingtonpost.com/blogs/the-switch/wp/2013/11/20/inside-valves-plan-to-revolutionize-the-world-of-video-games/
Sounds like a smart, crowd sourced method to lift better games up above their peers without the ability to stuff the ballot with phony reviews.
Developers will be able to directly respond to reviews, too, and aggregate review scores will be posted on steam separate from metacritic scores.
EDIT: Running Windows 7 Ultimate, btw. Dedicated to gaming, nothing else on it, so it boots straight into steam BPM. No other services started.
That was quite an impressive OP! Great work!
One thing which excites me quite a bit is the simple fact that Valve is not a public company (and will never be, from the sounds of it). This means less focus in quarterly reports and more focus in whatever the people in charge think is neat. And it just so happens that Valve seems to have a bunch of very bright peoples employed....
(Not coming from a SW development background this might be a stupid question, but...) Would it be feasible to add to the steam OS APIs to also target ARM? In that case, you would not only have a nice console, but also heaps of potential portables...
The steam review thinggy sounds nice. I hope they add some sort of filter function which will allow me to (more) consider people with similar taste as me when looking at reviews.
It is, and almost assuredly is coming, but games still wouldn't be cross compatible with x86, not unless they were running some sort of virtual machine interpreter (like java).
Or just streamed, I guess. Which seems to be a core part of the steam OS anyways...
Sure, but until there will be loads of cheap, portable x86 things avaliable, streaming is not too bad. Especially the ps4-vita and wiiU sorry range version of streaming seems to be quite solid.
The surface pro, for example? The big deal about that is it's the relaunching of x86 tablets. I say relaunching because we had x86 tablets 15 years ago.
perhaps this will be the start of a new era of mobile x86? That would be pretty cool, IMO. The problem with streaming is that it doesn't play well with regards to VR. That's why the current oculus rift is wired - wireless technologies induce too much latency. It'll be a problem for at least a few more years.
And if the controller works / feels like my imagination tells me it could (especially when it comes to virtual buttons through the haptic feedback), then I think after a little bit of "brain training," it will be a really nice way to play traditionally KBM games.
One of those situations where it benefits the whole of technology, you know?
That looks fucking slick. Two models, one called Gordon and one called Freeman.
No price or specs yet.
EDIT: But since everybody loves delicious unconfirmed, unsourced rumors from The Verge, $499, AMD multi-core processor and a Radeon 270 inside. Wowza!
That should be about Jan 7th-10th, 5 days before their Dev Days conference.
Like, how many baselines will there be, how often will they be updated, how will machines outside the baseline be handled (eg can i build a steambox from a raspberry pi?)
I am really concerned at how they will get over the cross platform hump of a pc multitask environment if they intend for these to be more than TV/stream boxes.
As far as i understand, all of the Linux games on steam will work and all games will work by streaming from a Windows pc to the steambox.
See, that's not the answer I want to hear. Try again.
the operating system is fully open source and moddable. You can do whatever you'd like to SteamOS.
All games work natively? What games? Windows games will not run under steamOS natively. But a steam machine isn't limited to just running SteamOS.
Uh, ok, here goes: every game ever released on every platform* works out of the box on any steambox.
*virtualboy support will be patched in with a day one patch.
I know this makes me a huge nerd, but I COULD BUILD MY OWN GAME CONSOLE. As someone who grew up with an Atari 2600 that I loved so much I still have it as well as every game I ever owned, this is something I never would've even thought possible.
There is still a lot of stuff that has to happen between now and that point, but it's still fun to think about.
It's not the answer you want to hear, but that's the answer. No, the latest Windows Shootymans or SomethingShock or whatever isn't going to natively work on SteamOS unless the developer puts out a Linux port. Valve is talking to developers to start getting that bandwagon rolling, and if this thing picks up some steam (snicker) you'll see more developers jump on board. In the mean time, if you like, you can play Windows games by streaming them off a Windows PC.
This is not a device for someone who wants a single "console" to play Windows games. At the start, it's a device for gamers who want access to Linux/Indie games, or for current PC gamers that want a way to play their libraries on their TVs. From this starting group, they hope to build support until it CAN be a stand-alone platform with a robust library for all types of gamers.
See, I knew that was the answer I was going to get, I'm not actually as daft as I came across. I guess I was hoping that I could dispose of Windows altogether once SteamOS was released. As it stands, I have no real reason to use SteamOS upon release, and its kind of disappointing.
I feel ya. It's not for you... yet. Cheer on it's successes, and maybe, one day, it'll get there. It's a long, hard road to where they hope to be, though, and I'm hopeful, but not optimistic.
What's preventing you from building your own console now? If anything, Valve's Steam Machine initiative is for people who don't want to build their own console.
Er, the concept of "console" usually carries baggage with it beyond "PC". I mean, I have my PC hooked up to the TV for when I want to couch-up my Steam library, but I wouldn't call it a "console". Most people would say that, before it's a console, it needs a simple, controller navigated UI and unifying architecture to ensure that "everything works" right away.
Sure, you can build a SteamBox right now, but you'll spend a lot of time fiddling with the OS, getting Steam to auto-boot, games that don't fully support controllers, tweaking alternate input methods (on-screen keyboards and the like). There's setup involved; it's a hobbyist thing right now. SteamOS has the potential to smooth out a lot of those edges, though, and make building your own SteamBox far more accessible.
Support? A licensed OS? A viable SDK? Virtually everything not on the consumer end of the equation? How do you propose someone provide that?
Steam: adamjnet
It's like that discussion about HL3 as a SteamOS exclusive.
"Steam Machine" is a fancy name for a set of standards Valve is trying to implement into PC gaming on a wide scale.
SteamOS is just Valve's take on Linux as a couch-appropriate OS, with built-in Steam functionality.
Saying "SteamOS exclusive" is saying PC (or Linux, if you want to be pedantic) exclusive.
Having lots of friends with Macs I've realized saying something is a PC exclusive is actually a big deal a lot of the time so saying something is "SteamOS exclusive" is still a big deal. Even if the OS is free, lots of people aren't going to want to go to the trouble or even know how to set it up.
Nothing will ever be SteamOS exclusive, at least not for many years (I suspect never).