When I first saw the switch I said that it could potentially become a huge platform for indie developers. This is definitely a step in the right direction, although I don't see why a devkit would even be necessary. Perhaps you're paying for software? Will this open the portable market to indie developers beyond phone games?
You are generally paying for unlocked firmware that will run whatever code you want, a feature that pirates would target on retail consoles. IIRC, some consoles also put more RAM in development kits.
It's a really interesting approach, considering how rampant Wii hacking was. Maybe instead of hacking the consoles, pirates will just buy dev kits, paying Nintendo a bit of a premium for the privilege?
Maybe they're hoping to make a little money on the pirates...
Modern dev consoles use the same DRM scheme as the retail consoles, they simply use a different (most of the time per developer) certificate, and won't boot retail signed titles.
But there's nothing stopping someone who wants to play a game "for free" from finding a torrent of a retail copy, downloading it, stripping the retail signature off it, using the SDK tooling to apply their own developer cert's signature, and then booting that on their console.
Likewise, "homebrew" on such a system would probably be like iOS homebrew is currently: an ecosystem of open-source projects where users are expected to download, compile, and sign the binaries themselves using their personal developer certs.
> But there's nothing stopping someone who wants to play a game "for free" from finding a torrent of a retail copy, downloading it, stripping the retail signature off it, using the SDK tooling to apply their own developer cert's signature, and then booting that on their console.
The way this has been impeded on previous consoles is to encrypt retail executables and lock the key in some "secure" coprocessor. These obviously do eventually get cracked, but at that point the system is probably so thoroughly exploited that you can do everything with a retail console anyway.
Why do they do that kind of thing? If anything, you might expect them to include less RAM & storage so that you're forced to work under tighter limitations.
It's so you can leave debug symbols in your executable: for a release you'll strip your binaries and pack them quite tight. For developing you'd like to have more uncompressed data in ram, and you want full debug symbols and debug info on the stack. Not to mention that debuggers themselves take a non-zero amount of ram.
There is no reason to work under tighter constraints. You want developers to be able to push the retail version of the hardware to the limits. In order to do that and still be able to run debug builds you need the dev kit to be more powerful than the retail version.
Previous gen Xbox dev kits generally had double the RAM and came with a Visual Studio license. They were very expensive. Now you can pay $19 to unlock a retail Xbox One to run any code you like with a 1GB RAM limit.
1: Nintendo portable systems have sold really well, so the market could be large. DS sold 154 millions units, 3DS has sold 65 million units so far. Of course no guarantee Switch will approach that. It is more risky with the hybrid approach, and continuing stiff competition from smartphones and tablets.
2: Handheld/portable systems are often better fits for indie scale games. Smaller/cheaper/shorter games.
3: Less AAA competition. Nintendo systems haven't been getting the biggest, latest greatest AAA titles from the large publishers, so indie games have more room to stand out.
The Xbox 360 devkits had extra USB ports for emulating DVD drives and high-speed data transfer. These kits required a fair amount of labor to put together; they were $10,000, and often hard to obtain.
I believe the Xbox One devkits are just production units with different key material (which prevents commercial titles from running, and allows developer-signed bits to run). Theoretically any Xbox One is a devkit, with the right software provisioning.
Dev kits usually have extra memory for debugging overhead and occasionally hardware for cycle specific profiling and the like.
Most release games run up to 5mb(or less) to the system memory limits so you can't turn on debugging and waiting for LTCG builds which can take 30mins+.
Modern game systems are running on top of a real big boy kernel this generation, so you don't need hardware level debugging support. An equivalent to gdbserver is enough.
The switch has a USB-C port though, which would be more than enough bandwidth for debugging. Mobile dev's have lived with USB 2.0 connections for building games just fine.
The problem is likely just that it becomes easier to install third party software if there is some kind of Dev mode inside retail units...but Nintendo's locked down hardware gets jailbroken anyways so I don't see the point in hiding it.
