$450 for a dev kit is a steal compared to older console generations, which were thousands of dollars per device.
Also, I think it is completely fair for Nintendo to think: If you won’t spare even $450 for a dev kit, there’s no way we want your game.
By the way, consider what a Switch regularly costs: $299. You are paying Nintendo only $150 for the privilege of sending you a custom, low-run, modified device that is different in both software and hardware, combined with (likely) an account representative for business and technical questions. That’s kind of cheap.
No kid is going to learn how to program in Assembly and C++, when interfacing with a custom microkernel, custom graphics API, and all of the technical requirements Nintendo demands (i.e. you must have a launch screen, loading times cannot be longer than X, read speeds cannot peak higher than Y), while cross-compiling your game and all dependencies to ARM, and precompiling all shaders ahead of time, for the Tegra X1, into your game. That's what developing for the Switch literally entails. Develop your game first and then you might get there.
This is a game console, not a PC. Developing games, for better or worse, whether it should be this way or not, is an extreme privilege. Sony basically never allows individual developers to register in any capacity. Xbox does, but if you want to actually publish a game, you're going to be in for a hard time.
It has around a 1Ghz cpu, you have no idea if their little homebrew games will stress that or need all the assembly tuning.
Kids have programmed games for their calculators. This is like “throw it together to show off your friends,” it doesn’t need to meet Nintendo’s UI standards.
> This is like “throw it together to show off your friends,” it doesn’t need to meet Nintendo’s UI standards.
In that case, unless it goes on the eShop (thus meeting Nintendo's standards), every single one of her friends will also need a devkit to be able to run it; as retail units can't decrypt devkit-encrypted games, nor vice versa.
Might as well get a Steam Deck before convincing Nintendo to send over 10 devkits for children.
> Won't anyone think of the giant multinational corporations instead of the kids learning to program for once.
It's not a binary choice. Kids can learn to program in 1000 different ways. Getting social Brownie points for pointing out someone else isn't being incredibly generous is pretty poor behaviour, I think.
Kids can learn to program in 1000 different ways, but will they?
The biggest motivation is to show-off your creation and if all your friends play on the Switch and your game isn't there, it might as well not exist at all.
I learned programming on a Commodore 64, because I wanted to make my own games. Back at that time the playing field was fairly level as evidenced by the fact that a couple of the prominent game developers were almost kids themselves.
> My 12 year old and I made a little game in Godot and it turned out pretty playable.
> I think in her peer group the second most popular device after the iPhone is the Switch. It would be incredibly cool if we could get our game to run there.
I don’t think buying her friends Steam Decks is a very scalable solution for this sort of thing.
The Steam Deck is, fundamentally, a PC. PC software is written to run using "some" of a PC's resources, because PCs have a bunch of extra resource "headroom" for running userland software plus a bunch of other junk on them at the same time. You can run a game in debug mode, within an IDE, within Windows, on a Steam Deck. And maybe also OBS to stream yourself doing that!
The Switch — and all other game consoles ever made thusfar — are embedded systems: systems designed to run software in such a way that the software can make use of 99% or more of the system's hardware resources (because, per the unit economics of such systems, that's the only way to make the system's low per-unit BOM, translate to good perf for the software.)
Also, unlike with PCs, embedded systems can give a developer performance guarantees — a number of CPU cores, amount of RAM, etc. that will always be 100% dedicated to running your software, with even hardware interrupts being offloaded somewhere else. And the platform will be extremely uniform, with all retail units having (at least) those same numbers. (Though there may eventually be a revision of the hardware that bumps the guaranteed resources up for software that opts into that — see e.g. how the Gameboy Color runs Gameboy games, or the "New" 3DS, etc.) So, unlike with a PC, when writing embedded software, you can and should write it to use "all the resources" — to "wastefully" spend memory caching whatever you can, run background logic to pre-compute things, etc., so that your software can get the best realtime runtime perf. It's not like anything else is running. Take the Unix idea of a process being nice(1), and invert it.
This means two things:
1. when a game is running on a retail device — if you've developed it following best practices — then there's no extra room for anything else to be running. Your software, by design, hogs everything. The OS shrinks down to just running on one e-core of one accessory CPU (and on older consoles, gets terminated altogether, with the user software instead being expected to keep the hardware going using an exokernel library provided as part of the SDK.) There's no room to run an IDE or debugger. So retail devices fundamentally can't be used to develop games in such a way that they "mirror production" — to have the room to develop your game on such a device, you'd have to somehow build your game to use half the RAM and CPU it usually uses — but only sometimes. Which is likely impossible, for most software architectures; but even if it were possible, you'd no longer be mirroring production.
2. even with a devkit — essentially these days just the same hardware but with double the RAM to fit a debug build of the game (both for the debug symbols, and so that it doesn't need to take two hours to LTO the executable each time you rebuild like it does for building retail) — you still need a host PC, because you want development to mirror production at least somewhat closely, and that means that you can't be spending half the CPU budget on a userland debugger + telemetry. Instead, devkit hardware has a hardware debugger + telemetry, that feed one side of a USB-serial connection to a host PC, where the other side is a special IDE that knows how to talk to such a setup.
None of this is unique to game consoles, mind you. You do the same thing to develop for an Arduino, or a wireless router, or a smart watch, or your car's infotainment system. "Tethered hardware devkits that externalize the development environment so the embedded software can expand to fill the device" are just how embedded systems engineering works.
---
And yes, embedded-systems hardware ecosystems also often involve "QA" or "tester" units, that are basically retail units that either allow you to run [the ecosystem's specific, often proprietary] media containing unsigned code; or at least, allow you to install a specific signing key and then run media containing code signed by that key.
So you could, in theory, do your development by building for QA units.
(That is, you could, if you thought that printf debugging with two-hour iterations is the be-all and end-all of development cadence.)
Homebrew embedded-systems tinkering communities tend to ignore such systems, though, mostly due to the requirement of burning the media. Even when the media isn't proprietary, it's still often something like a surface-mount eMMC flash chip, where the embedded-systems vendor expects you to be able to program that and put it on your QA board (and will, of course, point you to their hardware support partner who will sell you a programmer for it.) While there are many hardware hackers among Homebrew people doing fun reverse-engineering attacks, there are few true Electronics Engineers in the homebrew scene who have these sorts of Shenzhen-parts-store-looking industrial test-equipment labs in their basements. The average homebrewer doesn't even own an oscilloscope. :)
It's just easier to either work with true dev kits (where all you need is to "convince" the thing that you're authorized to feed it software over the serial tether); and/or to reverse-engineer and exploit your way into a retail unit, such that you can then feed it software through some channel that is attainable for the average dev (usually, these days, that means getting the system to launch software from an SD card that was supposed to just be there to store state data.)
> You are paying Nintendo only $150 for the privilege of sending you a custom, low-run, modified device that is different in both software and hardware, combined with (likely) an account representative for business and technical questions.
It's well known game consoles aren't the place to run custom code. If you can figure it out, power to you, but it's simply not a supported use case of the product.
Make the game available on the Switch store for like $5. 450/5 ~= 100, so after 100 purchases you've made back the money.
Sure, you'd have to spend extra time to polish stuff, and that would probably not be super easy, but afterwards you have a fully published game the daughter and all her friends could install.
This might not be feasible. If you are making a game for yourself and your kid, you might not be using assets (art, sound, etc.) that you could distribute/sell in your game.
I made a game for my daughters 3rd birthday, recorded some Blipi and Coco Melon songs off youtube that I put in the game. I would not have the right to sell the game without securing rights to the songs (unless I want a lawsuit on my hands).
How would you distribute that over the Switch in the first place to the daughter and/or friends if you don't have the licenses to the assets you're using?
Developing for desktop systems is essentially free.
Developing for iOS devices is $99 a year (plus store commission) for literally anyone.
Developing for consoles? Oh, you have to be a business entity, you have to pass approval process, you have to buy a dev kit, you have to... And then also pay a commission.
Develop on a Hackintosh (either bare metal or VM, there's more than enough guides for both), build using Github Actions, and that's it. If you want to stay fully legit, rent a Mac instance from AWS or the myriad "Mac-as-a-Service" companies and be done with it.
> Here is the thing, we aren't entitled to anything in life.
Are you sure about that? I'm entitled to a lot of things if my country's laws are anything to go by, for some reasonable definition of entitlement. I could be entitled to running my own software on a Switch if lawmakers say so. The EU already forced Apple, so what's another platform?
If Nintendo wanted to gatekeep on quality, publishers wouldn't be able to publish Unity assets directly to the shop, much less multiple publishers shipping the same asset.
If OP's kid buys a Unity asset and publishes it directly to the eShop, she'll have done the same amount of work as these publishers and produced the same quality of app. She can't because of Nintendo's developer program, not because Nintendo would disqualify it as poor quality.
> If OP's kid buys a Unity asset and publishes it directly to the eShop
I think the root case of the "kids can't write games for their peers" isn't Nintendo or anyone else.
Both Apple and Switch are praised by the parents for their restricted platforms. You can give a kid both of them and be sure that that kid wouldn't install age-inappropriate apps or games.
Self-made stuff needs to be moderated heavily or kids will share pornographic games (i mean they are kids. Who haven't tried to play at least one "age-inappropriate" game by the age of sixteen?).
In my humble opinion, Nintendo just don't want to do too much moderation, so they added hoops after hoops to jump through, until the amount of low-effort apps decreased enough for moderators to do their job thoroughly for every app.
> I think in her peer group the second most popular device after the iPhone is the Switch.
I would say that the inability of sharing anything self-made is why apple and switch are popular choice to buy for your kid. No need to talk about safety measures, if you lock them in a system.
So, IMHO, the conflict isn't between kid devs and nintendo, its between kid devs and their peers parents.
Also you have to pay to get your game rated by the ESRB (at least if it's physical. Maybe not required to pay money for digital games from what I'm seeing with a Google search? Although we had digital games we still got ESRB rated).
It's been more than a decade since I worked on a console game, but I think at the time that cost us $750.
Xbox One/Series has Dev Mode, but that's only for UWP apps which have severe resource restrictions. If you want to use the Dedicated partition you need a devkit.
The reasons why consoles lock down developer access so hard is because those interfaces are also very useful for piracy. On iOS, because you can get access to developer tools, you can use AltStore to sign arbitrary binaries with your own dev key[0]. Apple may have said "sideloading is a cybercriminal's best friend", but what they meant is "you're all going to steal iOS apps if we let the general public install software without DRM"[1].
The old Microsoft "Darknet" paper[3] built up a sort of theory of piracy, which I still find useful to invoke here. In the paper, they break the piracy ecosystem down into five pieces:
1. Rippers, who pirate new works and make them available
2/5. Seeders, who transmit new works across the network[4]
3. Players that are capable of rendering creative works
4. Indexes that provide information as to where pirated works can be found
To stop piracy, you need to block at least one of these steps. For a variety of reasons, legal action against any of these actors is difficult. Players and indexes are identifiable, meaning we can sue them, but they have legitimate, non-pirate-y uses. Rippers and seeders are hard to conclusively identify, making them impossible to sue. Of course, when people using the power of the state cannot identify criminals, they revert to collective punishment - or in this case, technical restrictions. You can't DRM the seeders or the indexes, but you can encrypt the media, which gives legal leverage over player vendors: either make your player enforce our licensing terms or do not play our media.
But there's still a problem: players can still play unprotected media. Rippers will just strip the DRM and release unprotected data that will play anywhere. This is why the RIAA fought tooth-and-nail to ban DRM-free DAT and MP3 players, and only settled for legal restrictions on DRM removal. Console manufacturers have the advantage that each new console is it's own medium - they can just make players that only play DRM-encumbered work, and then nobody can pirate anything, even if rippers strip the DRM. Hell, even if people jailbreak the players - you control the supply of players, so you can ensure whatever updates you use to 'prevent tampering' are installed before the user even gets to the console. And this is far cheaper than working on new obfuscations that some socially maladjusted loner will break in a few days.
[0] At least, if you trust Riley Testut with your iCloud account password.
[1] In general, people who want to enforce copyright rarely, if ever, come out and say it. The public is generally unsympathetic to copyright owners. It's easier to conflate security of their work from copying with security of your data.
[4] In the original Darknet paper, this was broken down into 'transmission' and 'caching'. This division makes sense for the FTP topsite scene, but not BitTorrent trackers.
A chunk of it is copy protection. Dev devices can necessarily run software not signed by the manufacturer, which means copy protection can be bypassed using PC-like methods and loaded to a dev device. Thus, they want to make sure the dev device is not the device that most consumers purchase.
I think it's a poor tradeoff for such a locked down environment, and anti-educational at that. Obviously console manufacturers have a different opinion on the matter.
Dev devices are typically physically different - containing debug lines and connections that are not present in retail. The Switch itself has 2 different types of dev console: One that looks very much like retail, and another that is about 4x as thick and has every port under the sun.
Secondly, these consoles are physically fused differently. Instead of having retail encryption keys burned into the SoC, they have custom keys issued to the developer installed. This means dev consoles cannot run retail software for lack of a key to decrypt it - but they will decrypt, and run, anything the developer signs.
Both of these things are physical modifications, ultimately. Dev consoles, thus, do not come off the same production line as retail; but are customized and modified devices with their own manufacturing process. That's not cheap.
Sure, the Xbox does get away with the retail console having a "Dev Mode." That's a testament to the Xbox's security having gone 12 years without a crack. Making physically different retail and developer consoles is a much safer solution for anyone who isn't Xbox.
