Free Godot engine port for Nintendo Switch

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 already found two GitHub repos with Godot ports, and this RAWRLAB announcement confirms that it will be doable on a technical level.

However, I reckon that we do not qualify for authorized Nintendo Switch developer. What would be the easiest way to get the game running on just our Switch?

I already ordered a Mig Switch and a dumper[1], but I'm not sure if this is the best way to go.

[1] https://migswitch.store/

Nintendo really wanted to encourage indie gaming on the Switch, so any individual can register to be an authorized developer: https://developer.nintendo.com/.

I saw that initially and was encouraged, but my further research suggests that you need to buy a development kit about which I could find virtually no info. I can only assume that it is expensive.

It looks like a Switch dev kit is only ~$450 from Googling. I believe dev kits in the past were far much expensive.

"only"

If it's to dev a game with your kid, that pricey. Pricier than the console itself.

Pricier than to dev for android or iphone, or any laptop. Or the steam deck for that matter.

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

You’re kidding right?

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

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

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

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

Nintendo doesn't owe you a cheap way to deploy your custom binaries to devices.

Buy a Steam Deck if you want that. Build it for Web GL or Android. Plenty of options exist.

I'm not sure what OP actually wants here. Even if you can get your game running on your own Switch, it's not easy to get it up on the store.

What they actually want is a cheap way to develop games with their kid and possibly share them over sneakernet with her friends.

Nintendo obviously doesn’t owe them that, and it doesn’t seem to be supported. But, this is a good place to cast around for ideas.

A Switch is simply not the right device.

You can punish a Web GL build of the game to Itch.io and everyone could try it straight from their phones.

We don't owe Nintendo to let them sell their junk.

Then buy a different product.

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.

Nintendo doesn't owe you a cheap way to deploy your custom binaries to devices.

Why not? Why should I not be allowed to run whatever I want on a device I supposedly own?

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?

Mostly agreed, but it could also easily be $10k.

This is the insanity I don't understand.

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.

Thank US 1983 crash for that.

Gatekeeping is a way to avoid a minium level of quality, instead of a dumpster copy cat trash that inudates all the stores where there is no control.

Want to learn how to do consoles?

Get a toy handeld using ESP32 or Arduino.

PC gaming had tons of shovelware since the beginning and even got both good propietary and libre software games with great quality.

So did the Game Boy, which the NIntendo seal of quality was almost given for free because lots of games were junk even under the GBC era.

Exactly because anyone can do it.

Then explain some "games" for the Game Boy Color where the quality was very subpar.

You said it yourself, Nintendo platform bouncers let too many spoil the party.

Here is the thing, we aren't entitled to anything in life.

Don't like the way consoles work? Don't buy them.

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?

Start a petition to see how far you will go, good luck.

There's quite notoriously no minimum level of _quality_ required to publish on the Switch store.

Here are three identical low-quality Switch games from three different publishers:

https://www.nintendo.com/us/store/products/word-chef-switch/

https://www.nintendo.com/us/store/products/chef-word-ardee-s...

https://www.nintendo.com/us/store/products/eat-your-letters-...

And here's the Unity asset that these games use almost verbatim:

https://assetstore.unity.com/packages/templates/packs/word-s...

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.

Just because some garbage ends up on the store, doesn't mean all the garbage gets through like on the PC and Android.

Even club bouncers occasionally let the wrong folks get in.

OP's kid has plenty of other options to play with game development.

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.

Developing for iOS devices is $99 a year (plus store commission) for literally anyone.

Don't forget having to buy a MacOS device in this equation.

I bought an XBox, too.

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.

Yeah that's pretty prohibitive for most people who couldn't spare $450 for a switch dev kit

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.

It's a little more complicated than that.

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.

You're starting at the wrong end. There is no need for there to be a separate "dev console".

It's because they want(ed) to keep a higher standard of quality on their store and keep homebrewers and cheaters away.

I believe you're right, but the first part didn't work. The Switch eShop has an incredible amount of shovelware.

Hence the want(ed).

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.

[3] https://www.cs.ucdavis.edu/~rogaway/classes/188/materials/da...

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

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.

It’s not going to be crazy but you should expect to spend like a $1000 total for everything and have a real company set up

It's not that easy, unfortunately - I'm a registered developer (for the Wii U) and to be 'enabled' for Switch development, you need to jump through a bunch of hoops including describing your previous experience with games development and so on.

The barrier for Wii U was significantly lower thanks to the 'Nintendo Web Framework', a web tech SDK that let you build games without needing to use tooling like Unity or mess around with the more complicated SDKs Nintendo provide. You didn't need prior games dev experience to get registered for that.

That said - maybe they've relaxed the criteria a bit now to give first time game devs a chance to get published on Switch.

and to be 'enabled' for Switch development, you need to jump through a bunch of hoops including describing your previous experience with games development and so on.

I don't think they're that strict, there's a lot of garbage on the Switch store.

The strictness isn't there to keep garbage off the console store. That was just Nintendo revisionism. It's there because they need to know who to sue into a crater if you use developer mode to play pirated games.

I'm not sure you can use developer mode to play pirate games but it's not out of reach I suppose. Seems like a lot of work.

So, on most systems nowadays, retail software is encrypted and signed with entirely different PKI from developer applications. You would have to obtain cracked retail software first, then resign it with your own keys. This is how you run pirated iOS apps now, which is only possible because Apple hands out developer keys like candy. It'd at least be theoretically possible to do the same thing with a console devkit and decrypted games.

This is also narrowly considering only the example of someone trying to pirate new releases for that given system. More broadly, the console manufacturers have class solidarity[0], and don't want you doing anything that might be a copyright violation - even if you aren't hurting them or their developers specifically. You could port over an emulator and steal older games, you could modify new games (even ones you own), or you could make fan games. They want absolutely none of that on their hardware, and the only way to guarantee that is to make sure everyone who touches a devkit is wearing contractual handcuffs.

[0] Vaguely Marxist term for "these people are in the same social situation, therefore their interests are aligned"

They're still that strict. I attempted to get authorized several months ago and Nintendo did not even bother to respond to a developer with a few phone game and app releases.

Their store is full of very nearly junk releases. How do they distinguish between a lot of experience, and a lot of experience with junk?

It’s extremely hard. I’ve tried to get my released games into the Switch and am rejected because I don’t have a team with console launch experience. Nintendo asks for team member resumes etc.

Of course at the same time they have tons of junk in the store. It turns out the trick is to just use a publisher.

I'm not sure the Mig Switch will allow you to play homebrew, it is designed to replicate the (apparently reverse-engineered) security protocol of game cards signed by Nintendo. The Github repos you've seen previously are probably your best bet, they're designed for homebrew development, but to launch these you'd need to mod your Switch: with an unpatched original model (could easily be verified on https://ismyswitchpatched.com/) it's as easy as connecting two pins with a paperclip and injecting a USB payload with your PC, with patched later models this requires a modchip soldered onto the board.

Even with that though, home-brew games are almost nonexistent on the Switch, or extremely minimal. Having the ability to launch a game with a modded Switch, doesn't mean you have access to the SDK, or the documentation. Without those things, you really can't write any useful programs. It's like gaining access to the cockpit of a plane, and having no manual or labels on what all the buttons do.

If you truly want to develop a Switch game, you need the SDK, and dev hardware is basically necessary as well. That's only coming from a deal with Nintendo.

Having the ability to launch a game with a modded Switch, doesn't mean you have access to the SDK, or the documentation.

The very same websites and forums and Discord servers where the people who come up with jailbreaks for the Switch hang out, can also point you to leaked copies of SDKs, and ways to use these with a jailbroken switch and/or an emulator like Yuzu. (After all, while most published console homebrew — including jailbreaks — use ground-up rewrites of support libraries, it's a lot easier to tinker on Proof-of-Concepts for exploit chains using the official SDK.)

and dev hardware is basically necessary as well. That's only coming from a deal with Nintendo.

Funny enough, you can find all sorts of dev hardware for old consoles on eBay... and yes, that's despite all such kits being closed-lifecycle systems that are supposed to be returned to the OEM when no longer used. (I think the main way these make it out into the market, is through the company that owns them going bankrupt and getting its assets liquidated.)

Modern console devkits don't boot unless they have an Internet connection through the manufacturer's VPN, so buying devkits on eBay is useless now. They started doing this with the Xbox One.

The reason why they did this is because of leakers. The Xbox 360's devkits connected to a separate Xbox Live network called PartnerNet, and anyone who wanted to test Xbox Live functionality - e.g. buying games or DLC - needed to actually upload their game to PartnerNet. This meant that everyone with a devkit got full access to a lot of prerelease games.

There were rings of people with devkits leaking games for gamer clout. The way they got access to the hardware was interesting. Microsoft actually didn't let liquidators touch the consoles[0], but they still needed to dispose of them. The electronics recyclers Microsoft hired didn't do a good job of this, so there was a cottage industry of people taking debug fused CPUs off destroyed motherboards and swapping them onto retail boards. This would give you something identical to a low-spec devkit that lets you run unsigned code and connect to PartnerNet, but doesn't have any of the crazier debug capabilities useful for development.

[0] Notably, the state of Rhode Island tried liquidating the devkits of the Kingdoms of Amalur developers and got stopped by Microsoft

Interesting! Has anyone gone to the effort to jailbreak the devkits + reimplement open versions of any network services the devkit depends on?

No, you're better off jailbreaking retail units.

That being said, most retail jailbreaks also let you jailbreak development consoles anyway. Development and retail hardware is very close to one another, they differ purely in what debug interfaces are available and what DRM gets enforced.

Even with that though, home-brew games are almost nonexistent on the Switch, or extremely minimal.

One major reason for that is that Nintendo aggressively permabans Switch devices that appear to be modded, preventing them from ever being used online.

This usually won’t happen if you don’t pirate anything, cheat or do anything that looks like either of those, but there’s always a risk

It's just a worse Steam Deck at that point.

Homebrew exists on other consoles with this like the PS4 or PS3. There are zero online games worth playing on switch.

You can run full ubuntu on it, so I guess people don't see much need for "homebrew". You can just run any game that compiles for arm linux on it.

devkitPro (libnx) has a complete OpenGL implementation with solid SDL2 port. I have ported my game engine to it with ease. There are even homebrew Godot ports for Switch that have been going on for years now. There's absolutely no trouble with writing proper homebrew for the Switch, no deals with Nintendo necessary.

How does the Mig Switch site not say at all what the product is? I clicked around for two minutes and still have no clue what it is or does.

It is a flashcard. It lets you load copies of games onto a SD card and the Switch will read them as official cartridges. The site mentions that its only for backups of your own purchased games, but most people buy them for piracy.

That's very interesting, thanks, I didn't realize you could load downloaded games onto a Switch like that. I imagined they have some sort of hardware verification.

They do, this is a new and exciting product, likely with an FPGA built in to bypass those hardware locks.

Overall this is very interesting. The game switching mechanism seems a bit fiddly though and I hope there will be a version with a button. I wouldn't be surprised though if the whole operation will be shut down completely by Nintendo so it might not be a bad idea to buy one. The same thing happened with the DragonInjector (small payload runner for jailbroken switches that fits in the cartridge slot).

Well one of it's main uses is playing pirated nintendo switch games, which they're not going to advertise.

Sure, but I guess we all know what "backups" is code for. I just didn't realize they managed to bypass the protections for the Switch.

Law enforcement knows what backups is code for, too

The thing they call for when they see a black person?

A product description is available if you click the “View full details” link to the bottom right of the Buy button, which leads to https://migswitch.store/products/mig-switch-pre-order. I agree that that information should be more prominent.

Its a flashcart

I'd recommend canceling your Mig Switch order.

First and foremost, it financially supports some very sketchy players in the commercial piracy (under)world.

Secondly, it won't let you play homebrew games - only officially signed nintendo software.

Thirdly, you'll have to keep your console offline forever, if you plan to use it - you can bet Nintendo will start revoking cart certificates and banning consoles at the first opportunity (each genuine cartridge is uniquely identifiable).

We have completely free solutions to both """backups""" and homebrew. Your best bet is to find a cheap model with an unpatched bootrom, and your second best bet is to install an rp2040-based glitching modchip (or find someone to install it for you, if you're not comfortable with microsoldering).

What online switch game is worth playing? I'm sure the mig will be decrypted, and they will just fake the signature for the homebrew games. I think that's how some of the older homebrew worked. The scene is pretty dead since smartphones exist though.

I agree he should just get an old one but aside from maybe not liking the mig guys I don't see a problem with the product. The amount of blood from mining in Africa for my minerals probably isn't too moral either.

just fake the signature

That's not how cryptography works.

Can you explain how it works? I read a bit here. https://wololo.net/2024/01/10/it-appears-team-xecuter-are-ba... it seems you can use different game certs to make it launch.

Each physical cart has a unique certificate, signed by a private key held by Nintendo. That certificate is verified locally by the console, against a public key in the firmware. Without CFW, you have no way to bypass that signature verification.

In short, the flashcart works by making a full clone of the cart, cert and all. The console doesn't know it's not talking to an original game. That is, until Nintendo's servers notice multiple consoles playing the "same" cartridge at the same time.

If you really are only making and playing backups of your own games then you'd probably be fine, but I don't think anyone really buys these products with that use case in mind.

Thank you for your explanation. I thought homebrew would be possible if you have a legit game, have homebrew then just use the cert to play it and make the game console think it's a game. I think if it like a GameShark, you load it with a cert then you switch the game.

Everything is signed, there's a chain of trust.

The unique certificate is mainly used to verify that a cart is authorized to be played online, the game files themselves are signed in their entirety and a console not running CFW will not accept any modified files.

Buying a Switch in the first place supports some very sketchy players.

The console itself is practically a loss leader, it's buying the games that's sketchy :P

To clarify my overall stance, I am:

Broadly anti-nintendo (good games, sketchy company), extremely pro- modding and homebrew, mostly pro-piracy, but firmly against the commercialization of piracy.

Making things available for free is good, taking things just so you can profit from them yourself is bad - and that's how I see MigSwitch et al.

I honestly don't get why console makers get a boner at the thought of disallowing third party software.

What do they gain out of this?

With proper security protocols you can sandbox your application well enough that hackers shouldn't be able to get to the OS.

And if they do find an exploit, the vendor can always force an OS upgrade, and prevent downgrades with hardware fuses, with new games requiring the latest OS.

It's not like console vendors aren't doing all this right now.

Making piracy more difficult, primarily.

I think that is right, but I also think that quality control is very important to console manufacturers, particularly Nintendo. You don't think about it so much because the consoles haven't changed that much in market position in years.

There is lore that bad quality software destroyed the 2600. Battles SEGA and Nintendo, SEGA and Sony, Sony and MSFT really depended a lot on the quality of titles and the users experience. So they tend to want to control the experience more then say Google or Apple do on the phone. You can have shitty apps on a phone, but its a much bigger problem for a console.

It's largely the same reasons Apple doesn't want alternative app stores on their phones

Royalties.

Quality Control.

Brand Alignment (historically a big deal for Nintendo).

Scheduling input.

Security by obscurity.

If you want a device that does everything buy it. I don't care if my Roku doesn't do something all arm devices can do even though it can. I didn't buy a PS4 to install Ubuntu I want to pop a game in.

Tragedy of the commons. By making the barrier to entry high, it means that only significantly capitalized businesses with significant assets to wager and lose can actually publish anything. It means that there's (less) app spam, because not every couch publisher can type "ChatGPT, make me a game with the default Unity assets."

Unrelated but I’m kind of terrified what the mig is going to do to the market. Crazy piece of tech but the signed carts getting cloned are going to get real interesting real fast.

Your best bet would be to buy an unpatched Switch from eBay (https://www.ebay.com/itm/144952360896, etc), make or purchase an RCM jig, and dive into the homebrew scene. GbaTemp is a good place to start.

Outside of buying an official dev kit, I think that may be your only option.

If you're dealing with a Nintendo Switch that has the RCM exploit, that is probably the easiest path to getting unsigned code. I think Mig Switch is probably only useful for commercial game backups and piracy.

I have only used the RCM exploit to boot Linux, but I believe you can also use it to boot custom firmware like Atmosphere, and presumably that is the path to which you could see your own games running in Horizon.

I wouldn't recommend using the mig unless you're willing to risk a console ban from all online services (if you care about that).

Just email Nintendo. They sometimes make exceptions for interesting indie developers and/or hobbyists. And the dev kits are affordable.

The migswitch will not allow you to run unsigned code, only clones of official cartridges. Get an old “unpatched” v1 switch or newer with a rp2040 modchip.

Others have commented on homebrew, but there are a couple "game engines" available for the Switch that don't require modding. Nintendo released their own, Game Maker Garage, which uses a block-based coding environment. There are also two I know of that use a more traditional programming language: SmileBASIC and Fuze.

Both are similar to PICO-8 or other "fantasy consoles" where you get a full environment that runs on-device, with a code editor, tools for editing sprites, tile maps, music, and sounds, and a library of stock assets. Fuze also has a cheap "player" app so your kid's friends wouldn't need to buy the full app to play anything she makes. I've only poked around them a bit, but they seem like pretty capable environments that might be a good option for a kid that's interested in programming. The obvious limitation is that you're locked in to that platform - as far as I can tell there's no way to run your games on PC.

I know "asymptotically close to zero" about game development and the like, so if someone who works in this space could answer this I'd be appreciative: what, if anything, would make you use Unity or Unreal instead of Godot for making a game today?

This isn't meant as a passive aggressive question to push some kind of open source narrative, but a genuine curiosity. Since I know basically nothing about the industry, I'm curious to what something like Unity or Unreal still offers over an engine that has no licensing fees.

Unity so much more polished

Unity has Timeline (and Cinemachine)

Unity has Entity Component which is superior for many coders to Godot’s node system

Unity has better 3D

Unity has large bank of answered questions

Unity exports to WebGL

Unity Asset Store Assets are high quality, abundant and cost effective

and Cinemachine

Phantom Camera does most of that in Godot.

Unity exports to WebGL

Godot also does that, albeit without C# support until the next major version.

Godot WebGL is not production ready. It-kinda-works is as good as it gets.

Godot webgl will not run on MacOS, defeating the whole point of WebGL/HTML5

“Godot 4's HTML5 exports currently cannot run on macOS and iOS due to upstream bugs with SharedArrayBuffer and WebGL 2.0”

https://docs.godotengine.org/en/stable/tutorials/export/expo...

Not sure that macos 8s the whole point of webgl/html5.

The market share for Mac gamers must be very, very low. Like under 1%-low?

Those numbers are for desktop game sales, not people who might want to play your game in their browser.

Being unable to load up a browser game on macOS is a pretty big deal when the main upside of a browser compile target is portability and accessibility.

"Godot 4's HTML5 exports currently cannot run on macOS and iOS due to upstream bugs with SharedArrayBuffer and WebGL 2.0"

I have read this line of the documentation a dozen times and I still don't understand what they mean by it. An HTML5 game is supposed to be run in a browser, are they saying that web GL 2.0 games won't run on a Mac even in a chromium browser?

Or are they saying that the export process to create the HTML5 game won't run on a Mac?

The web export is very very bad currently. I know there is a PR where that is getting worked on, but currently it's basically recommended to use Godot 3.6 if you want to web export. It outright does not work for safari (and Im not sure if safari is the issue in this case, or at least not anymore. Webgl2 has been fully supported since v15 ?)

This is the reason that I still haven't switched over to Godot and I continue to develop games using phaser JS.

Forcing users to physically install a game onto their computer is simply too much friction for 99.9% of your prospective audience. Lack of robust HTML5 support is a dealbreaker.

Entity Component which is superior for many coders

In what way?

Many ways. When you have a reference to something it is easy to add,query, change elements to that something

Even unrelated things can be added this way (RigidBody, Raycasters) whereas Godot needs separate parallel node trees to accomplish the same thing

Indie gamedev company co-founder here: 14 people team, 2 games released + next in progress and signed with publisher. There are few big reasons why you can't just go and use Godot.

Publishers. Basically 3 years ago when we made our first game together using Godot it was main reason why we were rejected by some publishers. Now situation can be slightly different, but many publishers still have in-house pipeline that only work for Unity and Unreal: QA, localization and console porting.

Asset Stores. Majority of modern games are not built from scratch and selection of ready-to-use components and assets available commercially would be like 1000x for two major commercial engines.

Hiring. It's take years and several commercial projects of experience to actually become effective at using specific game engine. There are just far less Godot experts arounds especially those with experience of making commercial game while working in team.

These reasons can sound like inertia, but it took decades for Unreal and Unity to conquer their market share and build their moat. I myself big open source and Linux nerd, but sadly it's will take another decade for Godot to make sensible dent in this market.

PS: We released first game on Godot and our following projects are built on Unity.

Unity was already massive by its 5-7th year. It had tons and tons of released games at that stage. Not sure exactly why that hasn't happened with Godot but i guess it might still happen, just a bit more slowly.

Biggest reason is that there weren't any decent competitors around as Unity built momentum. At the time it was Unity, a (difficult-to-work-with, difficult-to-gain-access-to, expensive) proprietary engine, or something vastly less feature-filled like Game Maker.

Nice answer. I have to say both the games on your Profile look great, and I am definitely going to try one tonight.

Do you recommend I start with Dwarven Skykeep or Vengence of Mr. Peppermint if I'm playing on a Steam Deck?

I tested both on Steam Deck and VOMP certainly works better on the platform since Beat 'Em Up just have easier controls and we supported Xbox gamepad anyway.

For Dwarven Skykeep controls include both keyboard and mouse and while playable from touchpads it's far from perfect. Though it's the one made in Godot and it took us 3+ years to build. :-)

Sounds really unfortunate. I also know little about this process, what do the publishers do that we cannot do ourselves? I guess they have pre existing deals with the major console makers that allows them to send things to market with little friction? Maybe that's why some indie devs just target PC, they lock themselves out of the console market but also don't have to deal with publishers?

First and most important publishers provide funding. To give an example here is a work you need to build a small game and you can imagine how much it costs:

- 1 project manager / year.

- 1 game designer / year.

- 1-2 programmer / year.

- 2-3 months month of sound design / music.

- 3-5 artists / year.

Even if you have a great multi-skill team you need at least 5-6 people for a 6-9-12 months and it's would be very much skeleton crew.

There are cases where team of 1-3 people working part-time without funding can build a great game, but it's require both sticking to specific genres and greater use of ready-to-use assets which means it must be 3D. Game that small indie company will build in 6 month will take 3-6 years with a team working part-time.

Indie devs who self publishing only target PC because commercial porting sertvices cost starting from $10,000-15,000 per platform and it's gonna be way more expensive if game wasnt optimized for gamepad and big screens from beginning. And it's just impractical to port it yourself because it will take many months to pass certifications since know-how for proprietary platforms is not available on stack overflow.

I've done game jams with both Godot and Unity.

Mainly the plug-ins, particularly third party plug-ins for unity are better.

One of them being cinemachine.

Another example would be a tool call technique collider creator that let's you paint collider primitives. That tool alone saved about 300 hours of work.

For many developers the Cinemachine tool is very useful as well.

The other feature is the ability to edit game objects while the game is running in editor mode for debugging. This is the sole major feature Godot currently lacks compared to unreal and Unity imo

Beyond that Unity has a better overall design IMO encouraging users towards composition over inheritance and NOT encouraging use of some one shot interpreted scripting language (GDscript)

Does this justify the 100x greater size of Unity as an organization over Godot? Probably not

This is exactly the feedback I was interested in...thanks!

I think these kinds of criticisms are necessary for open source stuff to become competitive with proprietary offerings; it feels like Blender, for example, has taken these criticisms pretty seriously and as a result it's started to become competitive with proprietary tools (at least in the "prosumer" and lighter professional spaces).

I'm sure they're already doing this, but Godot should probably keep a list of all these bits of feedback and start fundraising to build these features.

The Godot leads basically discussed this during the last conference that they are definitely not in the right zone to take over significant developer share for Unreal or Unity, they hope in new versions they can inch closer and closer.

The other feature is the ability to edit game objects while the game is running in editor mode for debugging.

+1 to this. Having switched to trying Godot Vs unity, this was the biggest "missing feature" that made godot harder to work with Vs unity. (I am no pro, not even indie, just a hobbyist)

In unity you can pause that game and view and/or modify game object's variables/properties/etc in real time. In Godot it feels like it just compiles and runs a binary that is disconnected from the editor. Yes you can debug the code, but the "live" integration with the visual editor is very useful when prototyping and trying out ideas as it lets you move things around and change variables, which you can't really do with debugging

When's the last time you tried it? This feature has been in Godot for as long as I care to remember, I use it daily.

cinemachine

Check out Phantom Camera: https://github.com/ramokz/phantom-camera

A few years ago I started messing with Unity and for the most part it was a decent engine with many platforms you can target which is a huge plus. Their whole licensing issue of late made me think though, do I really want to put years of my life into building a game when the owner of the engine can make changes which negatively impact my project?

Now, this could happen with any engine that you don't own but Epic uses their engine to create games themselves so they have an interest in further development which also benefits the users of the engine.

Godot is a newer kid on the block but has gained a lot of interest, especially after the Unity stunt. Now that it can target a Nintendo Switch there is even more reason to choose this engine as coding for game consoles can be pretty tricky as they usually have a lot of restrictions and tests they have to pass before you can launch on the platform.

Unreal and Unity offer maturity and vast knowledge available on the web for both if you want to learn the engine. Unreal has a visual scripting language which some love, both engines have storefronts where you can buy plugins, code, objects, all sorts of things to help make your game.

But does it target switch? Or does a company offer porting to switch with potential issues?

Whatever toolset most of the team are experienced and productive in, and support basically.

The navigation and path planning in godot are pretty primitive.

I am also not from the industry but here are some godot downsides from what I understand:

- script performances are worst than unreal or unity

- no asset market place

- 3d features are not up to par with other engines (level of details, shadows, etc)

For a classic 2d game it seems to have no significant downside. For a resource intensive 3d game it will depend.

I have over ten years experience with Unreal, so the cost of switching engines would be very high, and must offer something irresistible in return.

Regarding your second question: Unreal effectively has no licensing fee for most developers. The engine is free, you get access to the full source code, and you pay a 5% royalty only after you have made $1 million gross revenue.

Unity and Unreal still have more brand recognition, I'm sure there are project managers and creative managers that hadn't heard of Godot yet (though that is diminishing, I'm sure).

More importantly, there is institutionalized knowledge and established tooling in place at a lot of dev studios. The expertise in one engine takes at least a year or more to acquire before you can really make the engine purr. But it also affects the whole toolchain, not just the part inside the IDE -- assets created elsewhere (models, animations, audio) typically go through some massaging to be compatible in Unity or Unreal, or the particulars of the scene/project and this often done through some automation, that automation would likely have to be rewritten for a Godot workflow, or even if it didn't, that's certainly what a PM or other decision maker would anticipate.

There's also the asset store full of plugins, or in-house developed plugins, which extend the engine and would also likely need at least some part of it rewritten or replaced.

My opinion as a gamedev who doesn't work with engines like this:

-Unity and Unreal both offer better performance guarantees and more featureful runtimes than Godot

-Both represent much more mature ecosystems, with tooling that's again, more powerful than Godot

-Both have more robust communities and larger talent pools

All of this said, I'd be more likely to use Godot for a quick personal project than either Unity or Unreal. But then I'd be more likely to choose Raylib over any of these options to begin with. Other people's choices might be influenced by the above, or they might choose Unity/Unreal out of familiarity, or possibly even something as simple as marketing hype/market perception. I'm not really sure the current state of Godot, but last I toyed around with it, I got the impression of something that was in-between Gamemaker and Unity and that dominates my perception of it today.

Compared to Godot, as a hobby/volunteer game dev on some projects spanning a decade or more: I know Unity already, I enjoy it and have no compelling reason to leave, and it's much more mature in features, optimization, etc.

Efficiency - if you really need it. Unreal, gives you source, so you technically have everything you need to customize and optimize for the console you're targeting.

You're taking the problem in the wrong order, it's more why would I use Godot which is vastly inferior to unreal and unity.

Now what is inferior, well performance is bad, they have their own scripting language which no serious dev would want to use, they have c# integration but it's not on part. Assets, tooling is also inferior, you can't make console game with Godot etc...

Networking wise Godot has not much either.

That's the difference between an open source engine with not much investment and 100's $ put into unreal and unity.

This is great news! Too bad there's no C# support as of yet. But it's definitely a step in the right direction. Plus, not all projects need the performance boost of C#. Seems like Godot is about to grab a bit more market share from Unity.

In what way? The website says there is C# support. What facet are you describing needs it?

Curious, because would also like to use C#, and website says it does, you say it doesn't. I'm wondering what is up.

The linked page says the following:

No C# or GDNative/GDExtension: Only GDScript is supported. Native extensions are not supported, but you can try to convert them into internal modules.

Right from site https://godotengine.org/features/#script

""Leverage your C# experience to feel right at home If you're an experienced C# user, Godot offers you first-class support for the .NET platform. Power your game with familiar libraries and give them performance boost, while still benefiting from close engine integration.

Note: .NET support is provided as a dedicated engine executable. C# support is available for desktop and mobile platforms as of Godot 4.2. Web support should be added in the future, but until then, Godot 3 remains a supported option.""

He's talking about the Switch port library. It didn't support C# yet. But also on the wider topic Godot still struggles with making C# a first class citizen compared to its home baked script language. They're improving things but it's not great yet.

Got it. Thank You.

This likely doesn't apply to the Switch version due to platform restrictions/technical issues yet to be resolved.

The website says this: https://arc.net/l/quote/btugrszz

https://godotengine.org/features/#script

C# is fully supported, you just install godot mono

Even outside of the Nintendo switch, C# is only partially supported. If you want to develop web games in Godot 4 you can't use C#.

From the page:

No C# or GDNative/GDExtension: Only GDScript is supported. Native extensions are not supported, but you can try to convert them into internal modules.

I thought Godot was already being used in Switch games for the past couple years; for example, Sonic Colors used Godot for the engine. What differentiates this release? Did the sonic team make their own port or something?

In the PC-to-console world, there is no open solution. Everyone either builds their own ports, or (more likely) pays a porting company to do the work for them, who in turn have built there own solution. Console developer kits are proprietary, no one is allowed to share the API or source code.

This seems to be unique in that, if you get a License from Nintendo, you're allowed to access this companies kit for free.

Which then is MIT licensed - so why can't that then be further shared?

You aren’t prohibited under the license, but you are prohibited under the contract you agreed to, to get that code.

For example, imagine a company hired you to write a library they want to later release as GPL. They still might have rules that you can’t release that library except under certain conditions.

The real purpose of the MIT license is not free sharing with the world in this case - it’s so that developers don’t feel legal risk by using this port and building it into their games.

You aren’t prohibited under the license, but you are prohibited under the contract you agreed to, to get that code.

This doesn't make sense to me. MIT is a license to share and modify code. If another license can supersede that and remove rights granted by the actual license, then what prevents any company from releasing their code under MIT and then adding a shrinkwrap EULA that prevents looking at the code or modifying it? The license wouldn't mean anything.

imagine a company hired you to write a library they want to later release as GPL. They still might have rules that you can’t release that library except under certain conditions.

Before it's released as GPL, sure. But once it's actually released as GPL, that company can't prevent you from looking at the code or modifying it or redistributing it. At best, they can sever their relationship with you over doing so, but they can't legally challenge you doing so.

If that wasn't the case, nothing would prevent a company from taking 3rd-party GPL code, building on top of it, releasing the product as GPL, but then adding additional contractual requirements to get access to their product that prevented anyone from looking at or sharing that code. The GPL wouldn't have any power or enforceability.

Companies do circumvent the GPL a lot and they get called out on it when they don't allow customers to get copies of the source code or to share it online. I've never heard anyone seriously suggest that a valid defense would be for them to say, "okay, yes we're using GPL code but to buy the product you have to sign a contract and that contract legally prevents you from sharing the code." Those restrictions would themselves be a GPL violation.

what prevents any company from releasing their code under MIT and then adding a shrinkwrap EULA that prevents looking at the code or modifying it? The license wouldn't mean anything.

This has been an intentional feature of MIT/BSD licenses all along. Tons of proprietary products are built on MIT/BSD code.

Do you have free speech? Yes, it's your constitutional right.

But then you become a lawyer and you get some clients. Do you have the freedom to say whatever you want about your client's case, in public? No, you don't. You have given up your right to exercise free speech on those specific issues.

Another example. You have free speech to criticize McDonalds. You can mock them all you like. But let's say, you sign a contract to become a PR Spokesman for them. You then mock them publicly, on their official Twitter account. Can you be sued? Yes you can, and your constitutional right will not defend you.

Contracts are not licenses. Contracts can give licenses, licenses cannot give contracts. In this case, while you are receiving an MIT-licensed work, you are under contract that you will not share this information with anyone. Contracts always supersede licenses. If you do give that information to anyone in violation of your contract, while the license itself means that the creator of the Godot port will not sue you, Nintendo may sue you for the breach because you are under contract with them.

If that wasn't the case, nothing would prevent a company from taking 3rd-party GPL code, building on top of it, releasing the product as GPL, but then adding additional contractual requirements to get access to their product that prevented anyone from looking at or sharing that code.

Congratulations, that's actually the law right now at a certain level, and what the furor over Red Hat Enterprise Linux was about. Red Hat decided to release open-source code under a contract that prohibits distribution. The initial response was to have companies break that contract, but try to remain anonymous, as the receivers of that GPL code would be theoretically safe. This was later deemed too risky, unworkable, and antagonizing; which is why Alma Linux and others have given up on that approach, and just aim for general bug-for-bug compatibility from scratch.

So, it's not really MIT then - as it's MIT + something else.

It's interesting that they did not keep this a paid product, and use that as a lever:

1. to either get more customers

2. or to get Nintendo to remove the terms forbidding the open source release of software built on their platform

I am guessing that 1. will happen anyway, and 2. isn't needed since they have found a middle ground with Nintendo hosting details on their developer portal.

The fact that Godot requires/required a third party studio to port your game to consoles is a major turnoff and one of the things preventing developers jumping on the Godot train. From a solo dev point of view, too scary and expensive; from an indie company's point of view it's an unwanted extra expense and a potential point of failure that you can't control.

This opens things up considerably, despite the Nintendo walled garden.

No open source project can do it without third party support, the NDAs/etc required for getting access to the SDKs to build against those platforms prohibits it.

"Official" paid console ports are coming very soon (Q1 2024) from W4 Games, the company run by Godot's core developers.

https://w4games.com/products/

I'd assume for solo devs porting to multiple platforms is harder without external help.

What does 2. mean exactly? That I am not allowed to publish the source code of my Switch game as open source? What if my Switch port shared code (for example all the GDScript) with other ports. Does Nintendo also forbid me to publish this as open source? Can you use open source assets in a Switch game?

I'm not a licensed Nintendo developer but off of my knowledge from the Wii U era...

The Godot game engine cannot include any of the Nintendo Switch SDK nor can your game include any of the Nintendo Switch SDK or APIs unless you are a registered Nintendo developer and have signed their NDA. You cannot share any of Nintendos proprietary code or information.

So you could share your source code for a Switch game, minus any code or SDKs specific to the Switch.

Thanks!

How can they restrict access to authorized developers but also use the MIT license? Can't any authorized developer simply post the code on the internet?

Basically to use code they provide under MIT you also need to couple it with a proprietary SDK from Nintendo. If you post any proprietary bits on internet Nintendo will eat you alive.

But presumably the port touches the proprietary bits. So either A) that interface is not allowed to be distributed under the MIT license and they have a problem with Nintendo or B) the interface is fine to publish under MIT so why not make it more available?

It's comparable to how open source code can also be patent-encumbered. It's MIT licensed but Nintendo's NDA still applies. The license can't supersede that.

I feel like the license definitely can supersede that - you obviously wouldn't be GPL compliant if you required everyone who got access to your code to sign an NDA, for example.

Nintendo's NDA would only apply to people that signed the NDA. If some third party acquired the code without signing the NDA, the NDA shouldn't apply to them.

You answered your own question.

Does Nintendo take a 50% cut if you publish on their eShop?

It's most likely around 30% which seems to be the norm for stores like this

Also, physical retail distribution is likely around the same 30% ballpark.

For a console game you'd have to pay a 10-20% title fee and then the retailer also takes 30-40%.

And is why Apple chose 30% when they launched the app store; it was already an acceptable charge, and could be justified with storage/bandwidth costs and the suite of tools/services built for it.

That doesn't seem to line up in my books, but we'll see how the next few years go while the 30% commission standard still has a target on its back.

Epic’s store is 12%. Tim Sweeney tweeted that Epic take 5% as profit and the rest are costs[1].

Puts the other stores’ 30% in context, though Xbox/Playstation/Nintendo do significantly more QA than Epic.

[1] https://twitter.com/TimSweeneyEpic/status/112044179501033881...

Unsurprisingly, no plugins. Just plain-old GDScript, but embedding a faster scripting solution into the C++ codebase is not too hard for serious work.

Why unsurprisingly? I'm not familiar with console ecosystems.

The engine has an interpreter for Godot script so if you port it you can already run the games. Native code is it's own porting problem, it should be easy for a developer but game developers in particular that knows an engine may not be familiar with writing native code - they may have been using a plugin they found on the internet and now they will have to port that native code too by themselves.

I'll be curious if once the AOT c# hooks are added (hopefully with 4.3) if that will be able to work or not.

How does that work with the MIT license?

I presume they signed a rather restrictive proprieatary license and/or an NDA to get access to nintendos sdks and tool (as is common on other consoles).

Then one person breaking the NDA would make the Switch Godotport (and therefore some of Nintendos property (method names /usage )) legally available to anybody else (they didn't sign an NDA after all and it's probably not a copyright violation unless it includes actual code/binary).

I am not a lawyer so I'm probably very wrong.

MIT allows that. LGPL would in theory but you would need to release the potential changes you did to the game engine. GPL woudn't in any way.

But if they give me the source under the MIT license then I am free to redistribute it.

So while they would be in their right to make a proprietary port it seems like they wouldn't be able to legally release it under MIT. (Or at least not the whole thing, as code that touches Nintendo's API would need more restrictions)

My understanding: it is possible to license under a different license any additions or modifications they made. So the original code can remain MIT, but their changes (API integrations, etc) will be under a proprietary license (note: this would not be possible with GPL for example, but MIT is not like that).

What these people do is super cool. How can one learn to be in a team that does things like this ?

Couple of ways I can think of.

1. Build it and they will come 2. Talk to coworkers about a cool idea you had, gather the interested and start leading that project

1. Build it and they will come

This is absolutely true. Make sure you have a Discord or some social means of connecting with folks.

Best bet is probably to start by making a game. One option is to start by building a simple game using an existing engine, and eventually get deeper and deeper into the libraries you're using until you decide to contribute back to that engine, or create your own. Alternatively you could just start by making something incredibly simple, a Pong or NES Mario clone, and then work your way up through the generations to something more modern. The first approach is probably easier, as you'd have lots of tutorials from the community around the modern engine.

My Switch is hacked. Can I still use this to make unsigned Godot games and run them on my Switch?

Not without a Nintendo SDK license agreement and signing their NDA.

On the other hand, there’s a nice homebrew port you could certainly use that’s been around for years:

https://github.com/Stary2001/godot

What was the status quo before this?

You find a company who does Godot ports and pay them, with zero visibility into the underlying tech

License: The source code is distributed under the MIT License, offering broad usage and modification rights.

I might be missing something, but how did they manage to swing this? I thought proprietary NDAs around the Switch's API were the biggest holdups preventing Switch support from being added to Godot itself.

I would have assumed this would be free but would require signing some kind of source-available license that forced you to still respect the NDAs.

It's not vanilla MIT but some kind of MIT + NDA.

So to clarify, a free game engine is being made available for free, if I have paid and/or been approved to be a qualified developer?

At least words still mean something

Console version is using proprietary SDK and they can only provide you source code if you signed NDA with Nintendo. That's it.

There are a few companies to choose from here: https://github.com/godotengine/godot-docs/blob/master/tutori...

Currently, the only console Godot officially supports is Steam Deck (through the official Linux export templates).

This line makes me so happy that the Steam Deck is doing well. I hope they can show that by making it easier for developers and open source projects they will get more and better games. I'm sure it isn't a huge difference, but if over time an ecosystem can be built it would be very powerful.

Very cool project, but if they want this to matter for commercial indie devs, it needs to have C# support. It's not so much about performance, it's more about working with a marketable-skill language, ease of coming over from Unity / Monogame, and expertise level of developer community.

If you want to make games together with your kids there is also Fuze4 for Switch.

https://www.fuze.co.uk/nintendo-switch.html

I'm intrigued by Godot popping up in Switch games - Sonic Colors being a case in point. What's newsworthy about this particular use? Did Sonic Team do a custom port with Godot?

Ignorant question: I don't understand why this type of thing is necessary. IIUC there is nothing illegal about looking at leaked SDK docs and using emulators to contribute a Switch build target for Godot. Then game developers who want to develop Switch games could buy a devkit and build their games for switch, just like how I can build an APK for Android in Unity and load it onto my phone. Is the only thing stopping open source game engines from doing this a lack of time/funding/expertise/interest?

I am interested in Godot, but seeing these projects makes me more nervous than not. I always wonder

- How seamless is it

- How screwed am I if it doesn't work

- Would the headache/risk of dealing with Unity be less than the potential catastrophe of not getting a working switch version