Free Godot engine port for Nintendo Switch
rawrlab.com
rawrlab.com
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.
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.
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.)
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
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.
One major reason for that is that Nintendo aggressively permabans Switch devices that appear to be modded, preventing them from ever being used online.
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.
Don't forget having to buy a MacOS device in this equation.
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.
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.
Here is the thing, we aren't entitled to anything in life.
Don't like the way consoles work? Don't buy them.
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?
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.
Even club bouncers occasionally let the wrong folks get in.
OP's kid has plenty of other options to play with game development.
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.
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.
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.
It's been more than a decade since I worked on a console game, but I think at the time that cost us $750.
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.
$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.
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.
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.
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.
Game consoles are arbitrarily restricted PCs.
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.
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.
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.)
> 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.
A distinction that _they_ created to begin with.
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.
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).
I wouldn't, I don't. The game is a PC game.
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.
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.
You can punish a Web GL build of the game to Itch.io and everyone could try it straight from their phones.
Why not? Why should I not be allowed to run whatever I want on a device I supposedly own?
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.
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.
I don't think they're that strict, there's a lot of garbage on the Switch store.
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"
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 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.
Outside of buying an official dev kit, I think that may be your only option.
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.
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.
Quality Control.
Brand Alignment (historically a big deal for Nintendo).
Scheduling input.
Security by obscurity.
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).
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.
That's not how cryptography works.
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.
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.
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.
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.
- 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.
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
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.
Check out Phantom Camera: https://github.com/ramokz/phantom-camera
+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
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.
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.
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.
- 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 sure it's possible to get $100,000 of budget for a new game as team of 5 people to release it within 6-12 moinths. Even without much of track record it's doable if you have cool prototype. But I pretty certain no one will ever give money to yet unknown solo developer to release the same game in 2-3 years.
Yet modern tools become better and better every year and even for $100-500 you can buy enough of assets to build something that look good enough in 3D. There are just certain genres and art styles that just require larger team.
When you do pixel art you cant just buy bunch of art packs and expect them to work together. And for anything high-quality you'll be creating all the art from scratch for every project.
Of course I not talking about very basic 8-bit stuff, but about something that is actually looks good and well animated.
Do you recommend I start with Dwarven Skykeep or Vengence of Mr. Peppermint if I'm playing on a Steam Deck?
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. :-)
-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.
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.
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
In what way?
Even unrelated things can be added this way (RigidBody, Raycasters) whereas Godot needs separate parallel node trees to accomplish the same thing
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 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...
The market share for Mac gamers must be very, very low. Like under 1%-low?
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.
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?
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.
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.
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.
This opens things up considerably, despite the Nintendo walled garden.
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.
Curious, because would also like to use C#, and website says it does, you say it doesn't. I'm wondering what is up.
""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.""
No C# or GDNative/GDExtension: Only GDScript is supported. Native extensions are not supported, but you can try to convert them into internal modules.
""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.""
> No C# or GDNative/GDExtension: Only GDScript is supported. Native extensions are not supported, but you can try to convert them into internal modules.
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
This is absolutely true. Make sure you have a Discord or some social means of connecting with folks.
- 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
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.
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.
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)
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.
Okay, that's... not MIT then? I don't understand, you can't just call things MIT if they're not actually MIT and don't have the same license terms. Is the page just lying about what the license is?
"I'm giving away a product for free, but it's the special kind of free where it's free and you have to give me 20 dollars to get it."
This was annoying enough when Mongo released source available code and called it Open Source, but have we graduated to releasing full-on proprietary code that doesn't even hit common thresholds of source available licenses and we're just calling it Open Source anyway?
On the other hand, there’s a nice homebrew port you could certainly use that’s been around for years:
This seems to be unique in that, if you get a License from Nintendo, you're allowed to access this companies kit for free.
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.
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.
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.
> 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.
This is not how copyright law works, we should not be analogizing copyright and the 1st amendment.
> 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.
I think this is an oversimplification of how that kind of liability would work, but more importantly, once again, 1st Amendment rights and license agreements are not the same thing, this should not be used as a comparison.
----
> Congratulations, that's actually the law right now at a certain level, and what the furor over Red Hat Enterprise Linux was about.
No, using this analogy makes me less confident that you know what you're talking about. Red Hat Enterprise Linux could sever relationships with a client, it could even potentially maybe bring charges over a client circumventing controls to access that code in the future, but it could not bring legal cause against people for distributing the code.
This is not me theorizing on this point, multiple people/orgs decided to keep basing their products on RHEL code and distributing that code and Red Hat didn't have or try to make a legal claim against them. The only thing RHEL could do was say "okay, because of that contract violation, we don't want you as a customer anymore."
> 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.
I think this is a gross mischaracterization of what these orgs did. The full extent of legal risk that I heard anyone in these organizations at all worry about was circumvention of the contract to access new versions of the code after Red Hat had banned them as a customer. I'm not aware of anyone who was scared that Red Hat could sue them over distributing GPL code they already had.
And even there, most of the concern I heard was not over lawsuits but over the practical, everyday unreliability of getting access to new versions of RHEL when their accounts could be closed at any time. When Red Hat was called out as violating the GPL, their entire defense was that they were not putting a restriction on what people could do with the code, they were only adding terms around what you could do while still remaining a customer.
If Red Hat had claimed that they were imposing a restriction that violated the GPL, they would have been opening up themselves to lawsuits, because Red Hat doesn't own Linux and their usage of Linux is bound by them respecting the GPL license under which the code is provided to them -- and the GPL bars them from imposing that restriction. Red Hat does not have the legal permission to impose additional restrictions on the GPL, their usage of Linux code is subject to them respecting the terms of the license they agreed to. So under no circumstances would Red Hat ever claim that they were imposing a restriction on the redistribution of source code of RHEL, the company has been extremely adamant that they are not doing that.
Is your claim here that Red Hat has violated the GPL? Red Hat is claiming that they haven't violated the GPL and that they are not interfering with GPL rights. If they are putting a legal barrier in front of redistribution of GPL-licensed kernel code, then great, I hope that kernel devs sue them -- because Red Hat definitely does not have permission to do that with code that they don't own.
This has been an intentional feature of MIT/BSD licenses all along. Tons of proprietary products are built on MIT/BSD code.
You can build a proprietary product on top of MIT/BSD code. You can not revoke someone else's license. You CAN put MIT code in a proprietary product and not share it. But you can NOT tell someone else that they are not legally allowed to share code that they have been given under an MIT/BSD license. The MIT license is permission to share the code.
Nothing would prevent this project from building a proprietary product with MIT/BSD code in it and not sharing the code or sharing it under a different license. But if they say, "here's the code it's being given to you under an MIT license" -- then I don't see how they can add on top of that "subject to this NDA". If they give you the code MIT licensed, it's MIT licensed. If they give you the code with a bunch of other licensing restrictions, then they're not giving you an MIT license, they're giving you some other weird hybrid license that is not Open Source.
We don't have a licensing mechanism that I'm aware of for allowing companies to say, "here's a legal document outlining the terms of this license, and also pretend that these terms aren't binding."
At least words still mean something
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.
Puts the other stores’ 30% in context, though Xbox/Playstation/Nintendo do significantly more QA than Epic.
[1] https://twitter.com/TimSweeneyEpic/status/112044179501033881...