3 ms·

> They could sell an open variant for more money (+40% perhaps?) such that potential losses in games revenue are offset. 1) Developing a second SKU is expensiv

> They could sell an open variant for more money (+40% perhaps?) such that potential losses in games revenue are offset. 1) Developing a second SKU is expensive. 2) It seems that much of the PS4 hacking has been enabled by the minimal "open" surface provided by simply having a browser available on the PS4. The protections of an "open" SKU would likely be a roadbump. 3) Piracy is not the only problem. Hacking undermines multiplayer competition, the value of leaderboards, achievements, ... Frankly, the cheapest option to solve all these problems would be to simply bundle an extra PC to make your "open variant". But of the question is: Why would they? What's the profit in it?

izacus 10y ago
Um, that "open SKU" always exists - it's called the developer unit and can run any binaries so as a developer you can run your own game during the process. They're just locked behind the dev kit licensing costs and NDAs.
- gambiting 10y ago
  As someone who has both the X1 and PS4 devkits on my desk, it's interesting to me that Sony actually goes through the effort and massive cost of developing a separate SKU, where the devkit is a huge machine with extra cooling, more ram, more ports, and then the X1 is exactly the same as a retail unit, just with a different certificate installed on it. But yes, theoretically, "anyone" can buy a devkit and have access to the full architecture of PS4/X1 is they want to.
  - Nexxxeh 10y ago
    How would you compare the experience of working with the two?
    - MaulingMonkey 10y ago
      I had the same a year or two ago - both sets of kit have similar specs and design principles, so most of the differences were in the tooling and APIs. At the time, PS4's tooling seemed much more polished/complete/reliable - I only needed to resort to the command line interfaces for integrating with our existing custom tooling, and CI processes, exactly as you'd hope. The APIs were mostly solid, retro, C style APIs - with sane error handling, few edge cases, and no callback hell. I'm sure the XB1 has caught up somewhat in the tooling department at this point. Also, you may already support D3D11, and get to reuse a lot of code there. Not so much reuse with other WinRT APIs (for Win8/10 apps) although the APIs feel very similar.
- MaulingMonkey 10y ago
  > Um, that "open SKU" always exists - it's called the developer unit and can run any binaries so as a developer you can run your own game during the process. Manmal seemed to be positing some kind of mass access semi-open SKU that didn't completely defeat the purpose of having a closed SKU in the first place. I'd argue that mass access to devkits would defeat the purpose of having a closed SKU in the first place. I suppose you could argue I should've said "developing a third SKU is expensive", though.

izacus 10y ago

Um, that "open SKU" always exists - it's called the developer unit and can run any binaries so as a developer you can run your own game during the process. They're just locked behind the dev kit licensing costs and NDAs.

gambiting 10y ago
As someone who has both the X1 and PS4 devkits on my desk, it's interesting to me that Sony actually goes through the effort and massive cost of developing a separate SKU, where the devkit is a huge machine with extra cooling, more ram, more ports, and then the X1 is exactly the same as a retail unit, just with a different certificate installed on it. But yes, theoretically, "anyone" can buy a devkit and have access to the full architecture of PS4/X1 is they want to.
- Nexxxeh 10y ago
  How would you compare the experience of working with the two?
  - MaulingMonkey 10y ago
    I had the same a year or two ago - both sets of kit have similar specs and design principles, so most of the differences were in the tooling and APIs. At the time, PS4's tooling seemed much more polished/complete/reliable - I only needed to resort to the command line interfaces for integrating with our existing custom tooling, and CI processes, exactly as you'd hope. The APIs were mostly solid, retro, C style APIs - with sane error handling, few edge cases, and no callback hell. I'm sure the XB1 has caught up somewhat in the tooling department at this point. Also, you may already support D3D11, and get to reuse a lot of code there. Not so much reuse with other WinRT APIs (for Win8/10 apps) although the APIs feel very similar.
MaulingMonkey 10y ago
> Um, that "open SKU" always exists - it's called the developer unit and can run any binaries so as a developer you can run your own game during the process. Manmal seemed to be positing some kind of mass access semi-open SKU that didn't completely defeat the purpose of having a closed SKU in the first place. I'd argue that mass access to devkits would defeat the purpose of having a closed SKU in the first place. I suppose you could argue I should've said "developing a third SKU is expensive", though.