Won't anyone think of the giant multinational corporations instead of the kids learning to program for once.

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.

> This is a game console, not a PC.

Game consoles are arbitrarily restricted PCs.

> 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.

you dont need any of that shite to run your own game on the Steam deck

> 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.

You're comparing apples to oranges.

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.

A distinction that _they_ created to begin with.

"Expensive dev kits made sense for devs 20 years ago, but today they are just a way to lock the ecosystem. "