[HN Gopher] Free Godot engine port for Nintendo Switch
___________________________________________________________________
Free Godot engine port for Nintendo Switch
Author : ekianjo
Score : 360 points
Date : 2024-01-23 11:26 UTC (11 hours ago)
(HTM) web link (www.rawrlab.com)
(TXT) w3m dump (www.rawrlab.com)
| fwsgonzo wrote:
| Unsurprisingly, no plugins. Just plain-old GDScript, but
| embedding a faster scripting solution into the C++ codebase is
| not too hard for serious work.
| andybak wrote:
| Why unsurprisingly? I'm not familiar with console ecosystems.
| a1o wrote:
| 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.
| runevault wrote:
| 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.
| TheRoque wrote:
| What these people do is super cool. How can one learn to be in a
| team that does things like this ?
| Grimblewald wrote:
| 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
| echelon wrote:
| > 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.
| delecti wrote:
| 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.
| tussa wrote:
| Does Nintendo take a 50% cut if you publish on their eShop?
| utf_8x wrote:
| It's most likely around 30% which seems to be the norm for
| stores like this
| miohtama wrote:
| Also, physical retail distribution is likely around the same
| 30% ballpark.
| prophesi wrote:
| 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.
| wmf wrote:
| For a console game you'd have to pay a 10-20% title fee and
| then the retailer also takes 30-40%.
| teamonkey wrote:
| 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/112044179501033
| 881...
| a1o wrote:
| There are a few companies to choose from here:
| https://github.com/godotengine/godot-docs/blob/master/tutori...
| kevincox wrote:
| > 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.
| weinzierl wrote:
| 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/
| falker wrote:
| 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.
| lastgeniusua wrote:
| 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.
| gjsman-1000 wrote:
| 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.
| traverseda wrote:
| 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.
| derefr wrote:
| > 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.)
| kmeisthax wrote:
| 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
| derefr wrote:
| Interesting! Has anyone gone to the effort to jailbreak
| the devkits + reimplement open versions of any network
| services the devkit depends on?
| kmeisthax wrote:
| 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.
| JoshTriplett wrote:
| > 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.
| circuit10 wrote:
| 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
| jimmaswell wrote:
| It's just a worse Steam Deck at that point.
| graphe wrote:
| Homebrew exists on other consoles with this like the PS4
| or PS3. There are zero online games worth playing on
| switch.
| seba_dos1 wrote:
| 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.
| realslimjd wrote:
| Nintendo really wanted to encourage indie gaming on the Switch,
| so any individual can register to be an authorized developer:
| https://developer.nintendo.com/.
| weinzierl wrote:
| 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.
| coffeebeqn wrote:
| 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
| nogridbag wrote:
| It looks like a Switch dev kit is only ~$450 from Googling.
| I believe dev kits in the past were far much expensive.
| troupo wrote:
| 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.
| 3836293648 wrote:
| It's because they want(ed) to keep a higher standard of
| quality on their store and keep homebrewers and cheaters
| away.
| mh- wrote:
| I believe you're right, but the first part didn't work.
| The Switch eShop has an _incredible_ amount of
| shovelware.
| ammar2 wrote:
| > 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.
| troupo wrote:
| I bought an XBox, too.
| helboi4 wrote:
| Yeah that's pretty prohibitive for most people who
| couldn't spare $450 for a switch dev kit
| mschuster91 wrote:
| 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.
| pjmlp wrote:
| 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.
| anthk wrote:
| 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.
| pjmlp wrote:
| Exactly because anyone can do it.
| anthk wrote:
| Then explain some "games" for the Game Boy Color where
| the quality was very subpar.
| pjmlp wrote:
| 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.
| dvdkon wrote:
| > 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?
| pjmlp wrote:
| Start a petition to see how far you will go, good luck.
| amalcon wrote:
| 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.
| gjsman-1000 wrote:
| 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.
| kmeisthax wrote:
| 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/mater
| ials/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.
| cableshaft wrote:
| 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.
| BiteCode_dev wrote:
| "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.
| gjsman-1000 wrote:
| 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.
| bjtitus wrote:
| Won't anyone think of the giant multinational
| corporations instead of the kids learning to program for
| once.
| gjsman-1000 wrote:
| 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.
| bee_rider wrote:
| 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.
| gjsman-1000 wrote:
| > 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.
| robertlagrant wrote:
| > 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.
| weinzierl wrote:
| 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.
| BiteCode_dev wrote:
| "Expensive dev kits made sense for devs 20 years ago, but
| today they are just a way to lock the ecosystem. "
| ekianjo wrote:
| you dont need any of that shite to run your own game on
| the Steam deck
| derefr wrote:
| 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.)
| bee_rider wrote:
| > 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.
| diggan wrote:
| 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.
| hitpointdrew wrote:
| 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).
| diggan wrote:
| 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?
| 999900000999 wrote:
| 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.
| bee_rider wrote:
| 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.
| 999900000999 wrote:
| 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.
| bakugo wrote:
| > 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?
| nonethewiser wrote:
| Mostly agreed, but it could also easily be $10k.
| revjx wrote:
| 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.
| gs17 wrote:
| >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.
| kmeisthax wrote:
| 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.
| djmips wrote:
| 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.
| kmeisthax wrote:
| 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"
| araes wrote:
| 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.
| GlickWick wrote:
| 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.
| stavros wrote:
| 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.
| weberer wrote:
| 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.
| stavros wrote:
| 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.
| traverseda wrote:
| They do, this is a new and exciting product, likely with
| an FPGA built in to bypass those hardware locks.
| sureglymop wrote:
| 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).
| traverseda wrote:
| Well one of it's main uses is playing pirated nintendo switch
| games, which they're not going to advertise.
| stavros wrote:
| 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.
| Retr0id wrote:
| Law enforcement knows what backups is code for, too
| stavros wrote:
| The thing they call for when they see a black person?
| cptaj wrote:
| Its a flashcart
| roryokane wrote:
| 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.
| jchw wrote:
| 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.
| fxtentacle wrote:
| Just email Nintendo. They sometimes make exceptions for
| interesting indie developers and/or hobbyists. And the dev kits
| are affordable.
| gundamdoubleO wrote:
| 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).
| joenot443 wrote:
| 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.
| torginus wrote:
| 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.
| djur wrote:
| Making piracy more difficult, primarily.
| georgeecollins wrote:
| 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.
| ranger207 wrote:
| It's largely the same reasons Apple doesn't want alternative
| app stores on their phones
| ook wrote:
| Royalties.
|
| Quality Control.
|
| Brand Alignment (historically a big deal for Nintendo).
|
| Scheduling input.
|
| Security by obscurity.
| araes wrote:
| 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."
| graphe wrote:
| 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.
| Retr0id wrote:
| 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).
| graphe wrote:
| 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.
| Retr0id wrote:
| > just fake the signature
|
| That's not how cryptography works.
| graphe wrote:
| 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.
| Retr0id wrote:
| 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.
| graphe wrote:
| 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.
| Retr0id wrote:
| Everything is signed, there's a chain of trust.
| bakugo wrote:
| 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.
| punkybr3wster wrote:
| 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.
| weberer wrote:
| My Switch is hacked. Can I still use this to make unsigned Godot
| games and run them on my Switch?
| thejsa wrote:
| 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
| Aissen wrote:
| 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.
| teamonkey wrote:
| 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.
| LelouBil wrote:
| I'd assume for solo devs porting to multiple platforms is
| harder without external help.
| TillE wrote:
| "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/
| runevault wrote:
| 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.
| weinzierl wrote:
| 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?
| crysin wrote:
| 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.
| weinzierl wrote:
| Thanks!
| drzaiusx11 wrote:
| 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?
| koromak wrote:
| 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.
| ukd1 wrote:
| Which then is MIT licensed - so why can't that then be
| further shared?
| gjsman-1000 wrote:
| 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.
| danShumway wrote:
| > 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.
| gjsman-1000 wrote:
| 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.
| wmf wrote:
| _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.
| ukd1 wrote:
| So, it's not really MIT then - as it's MIT + something
| else.
| ufo wrote:
| What was the status quo before this?
| koromak wrote:
| You find a company who does Godot ports and pay them, with zero
| visibility into the underlying tech
| magic_hamster wrote:
| 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.
| FrustratedMonky wrote:
| 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.
| mattsan wrote:
| The website says this: https://arc.net/l/quote/btugrszz
| FrustratedMonky wrote:
| 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.""
| tslater2006 wrote:
| 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.
| FrustratedMonky wrote:
| 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.""
| johnnyjeans wrote:
| This likely doesn't apply to the Switch version due to
| platform restrictions/technical issues yet to be
| resolved.
| strich wrote:
| 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.
| FrustratedMonky wrote:
| Got it. Thank You.
| lionkor wrote:
| C# is fully supported, you just install godot mono
| sandyarmstrong wrote:
| 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.
| wly_cdgr wrote:
| 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.
| Vespasian wrote:
| 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.
| anthk wrote:
| 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.
| kevincox wrote:
| 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)
| vladms wrote:
| 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).
| Capricorn2481 wrote:
| 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
| tombert wrote:
| 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.
| sbergot wrote:
| 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.
| LarsDu88 wrote:
| 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
| tombert wrote:
| 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.
| prox wrote:
| 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.
| gs17 wrote:
| >cinemachine
|
| Check out Phantom Camera: https://github.com/ramokz/phantom-
| camera
| mattlondon wrote:
| > 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
| sli wrote:
| 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.
| pfist wrote:
| 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.
| beardedmoose wrote:
| 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.
| SXX wrote:
| 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.
| cevn wrote:
| 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?
| mardifoufs wrote:
| 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.
| wk_end wrote:
| 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.
| ghostbrainalpha wrote:
| 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?
| johnnyjeans wrote:
| 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.
| xgkickt wrote:
| Whatever toolset most of the team are experienced and
| productive in, and support basically.
| kevindamm wrote:
| 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.
| tezza wrote:
| 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
| djur wrote:
| > Entity Component which is superior for many coders
|
| In what way?
| tezza wrote:
| 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
| gs17 wrote:
| >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.
| tezza wrote:
| 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/exp
| o...
| mattlondon wrote:
| 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?
| hombre_fatal wrote:
| 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.
| mardifoufs wrote:
| 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 ?)
| djmips wrote:
| 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.
| jimmaswell wrote:
| 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.
| Thaxll wrote:
| 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.
| tubs wrote:
| The navigation and path planning in godot are pretty primitive.
| b33j0r wrote:
| 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
| SXX wrote:
| Console version is using proprietary SDK and they can only
| provide you source code if you signed NDA with Nintendo. That's
| it.
| s17n wrote:
| 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?
| fl0id wrote:
| You answered your own question.
| SXX wrote:
| 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.
| kevincox wrote:
| 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?
| TillE wrote:
| 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.
| s17n wrote:
| 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.
| Ghufran007 wrote:
| 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?
| ChadNauseam wrote:
| 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?
| danShumway wrote:
| > 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.
| wmf wrote:
| It's not vanilla MIT but some kind of MIT + NDA.
| fifilura wrote:
| If you want to make games together with your kids there is also
| Fuze4 for Switch.
|
| https://www.fuze.co.uk/nintendo-switch.html
___________________________________________________________________
(page generated 2024-01-23 23:01 UTC)