discord-rpc
discord-rpc copied to clipboard
discord
Deprecation and Migration to Discord GameSDK
Hey everyone!
As you may or may not know, Discord has been working closely with Game Devs for a while to give developers a way to sell their game on Discord. Recently, we announced our open invitation to publish on Discord to everyone!.
Equally as exciting is the work that we've done to further support the tech behind games with our Discord GameSDK. It includes not only Rich Presence, an awesome thing that you all love, but also a host of other useful features for apps and games like:
- Lobbies
- Networking
- Social Graph
- Built in Discord Voice tech!
The "Come on in everyone!" game publishing announcement also marked our public release of this SDK, and we're quite proud of it. With that public release, it doesn't make a lot of sense for us to maintain two separate SDKs when one (discord-rpc) is just a subset of functionality of the other (GameSDK). So today we're deprecating this SDK in favor of the new one.
So what's it mean?
For most people, this change doesn't mean much. The big takeaway is that we won't be making any new feature additions to this SDK. Those requests should be directed to the new Game SDK, which will be our foundation on which to build.
Is my stuff gonna break?
Nah. The tech behind this SDK—connection to Discord via IPC/unix sockets and sending commands/listening for events—is how the new SDK works as well. So you should not expect your implementations to break. But, if you wanna be safe and future-proof and get cool new features, you can upgrade to the new SDK.
We've even made some of the Rich Presence functionality better, like allowing you to send invites programmatically or with our nice overlay UI.
What about feature requests?
We do not want to lose them! We've amassed a number of feature requests/enhancements in this repo over time, and we want to give those a place to be heard. We've opened up a new feedback site specific to devs and integration/SDK stuff. You can find it here. I'll be working in the next week to port all existing feature requests there and clear out the outstanding queue here.
In fact, some of the outstanding feature requests here are already addressed in the new SDK. To grab a couple:
- #202
- #203
- #94 (if launched from the Discord library)
- #71 (I believe, haven't personally tested)
TL;DR
It's good info, please read it <3 I'll pin this issue and leave it open for comments for a little while to make sure any outstanding questions are answered!
List of Links
Will this new GameSDK have a license that is GPL 2 compatible? I need it to be able to keep adding it to open source software where rich presence would be useful.
Will independent rich presence libraries still be supported or is Discord wanting to move only to GameSDK supported Rich Presence? What about this C++ library? Its practically just Rich Presence at this point and a lot of people still rely on it for not only their C++ projects, but bindings for their own Rich Presence implementation.
This specific library is deprecated, but the underlying tech this library uses (namely our RPC implementation) is not deprecated and continues to be used (by the new SDK) and supported.
So all the other Rich Presence libraries for the other languages have to either move to a custom implementation or be forced to use a "deprecated" library for the foreseeable future?
How would I contribute to this new SDK? I only see a download link for a zip archive with sources and binaries. This seems like a major step backwards to me.
Also, I can't sign in with that new place for feedback/feature requests. It just opens the sign in window, does some flashy animation and redirects me back without actually signing me in.
License: I'll get that handled.
Independent RP Libraries: As night mentioned, the underlying RPC tech isn't changing/isn't deprecated. So you're welcome to continue developing independent libraries for Rich Presence specifically, as well as wrappers around the GameSDK, if you want to as well.
Can't Sign In to Feedback: Might be that the site wasn't actually pushed live, my bad. I'll work with the folks who set up the site to figure out what's wrong there.
Is there any reason not to have the source code for this on github? This method prevents others from contributing and improving the software directly through PRs like it was possible here.
@MinnDevelopment We tried open source with this library, but we wanted a closed loop for development of the new sdk. People are required to use our binary instead of embedding source code into their games and other libraries (bypassing complexity of getting people to upgrade). additionally, we make assumptions about the sdk's version to allow for automatic upgrades where compatible. we think open source makes sense for certain things, but this is not one of them.
Link to the feedback site should be updated now. Let me know if you can log into that.
To briefly piggyback on what night said:
At the time of the release of this first SDK, the people maintaining it were...well, me. With some help at the very beginning from Chris as the big issues were ironed out, and then Ben, for when stuff was over my head (which admittedly was fairly often, lol).
The new GameSDK has an actual team of engineers behind it to fix things and add features.
Further, the discord-rpc SDK was still limited in scope as to what could be added to it. Most were bug fixes (which we happily take full ownership of now) or small QOL improvements, like specifying the Discord instance to connect to (which the new SDK actually handles). Any big "feature improvements" were limited to the extent of the RPC commands that existed in Discord and how they functioned; the underlying function of the Rich Presence implementation really couldn't be changed, in spite of the SDK itself being open source, and still would have required someone on the Discord side to work in our app to make changes. Previously, that was me bumbling around. Now, it's people that actually know what they're doing.
I still think open sourcing or at least have the code publicly available makes sense for the SDK since devs will have to have their code rely on it. It's not as easy to debug bugs with a closed sourced library compared to an open source one. It can be hard to tell if it's your code that's causing the bug or the black box.
open source
It is seemingly industry standard to have closed SDK, with all consoles and steam having some form of NDA closed library. This does exactly what sleepy said, create great confusion if it's the game or the SDK causing issues.
From our experience with Party Crashers, closed source sdks are generally poorly documented and seemingly a magic black box. Just recently we had a bug in the game that took days to resolve only to figure out it's a bug in the SDK itself.
While there are some excuses for closed source SDK on some platform, I don't really think there is any reason in this case other than to keep the code secret. I suppose one could argue maintainability is harder with many forks and unofficial ports to other languages having to be taken I to account.
Other Libraries Glad to here the underlying tech will still work. That means my library can continue. However, what about the other bindings/wrappers that use this library as their core? Do they have to update to manually implement the tech or be stuck with a depreciated library as their core?
I'd say that just because this library is deprecated doesn't mean that tomorrow everything is going to break. The underlying functionality here is, as mentioned, nearly the same as the new GameSDK (though this one is cpp and the GameSDK is rust, for what it's worth). With the GameSDK also in a good number of big, live-ops games like Paladins and Warframe, we aren't exactly keen on breaking changes 😄
It's basically a long way of saying that yes, libraries that are wrappers around the core binding here will be relying on a deprecated library as their core, but I do not foresee any immediate fear of collapse of that core.
Given that the SDK isn't under a FOSS-compatible license, this offers no forward migration path for games or tools with source under GPL licensing.
What plans do you have for if something on your end breaks the Discord RPC at some point? I appreciate that you have plans to try stop the underlying functionality from changing, but I'd be extremely impressed and surprised if you manage to succeed at that indefinitely.
GameSDK should have linux binaries, I would prefer not to have two different libraries to handle rich presence, networking and so on
From what I read from the doc, there should be some binaries available for linux but the .zip does not contains the mentioned folder
You'll also notice that there is a
runtime/folder.
@Masadow sorry about that, old documentation. We don't ship the runtime/ folder anymore. The binaries should be fine to ship on any platform? We don't currently support game launching via the Discord library on Linux, and only macOS on Canary, but the SDK should function just fine for Rich Presence.
I implemented RPC on a FOSS emulation application. Is the SDK something I can opt-in even if I'm not monetizing my application?
I figure some features may be feasible but I thought I should ask
- Can I use cloud storage even though our application is FOSS?
- Can we distribute an emulator related application on the store?
- Can we use voice chat even though our application is FOSS?
The application itself does not infringe any copyright, but it's all a legal gray area so I thought I should ask before even trying to integrate anything.
Hmmm... guess not possible
2.6 Open Source Software. Except as otherwise expressly agreed in writing, Developer shall not distribute via Discord Store, or combine any Discord materials with, open source or other software that is licensed under terms that purport to bind Discord to contractual obligations (e.g., the GNU General Public License or Lesser General Public License).
I figure I could still do lobbies/rpc and voice unless only published apps can use that. So question:
Do I have to publish my application on the store in order to use the SDK features?
@fr500 that is interesting. I'm gonna raise that with our legal council here. Thank you for pointing that out.
As far as we're concerned, no, you don't need to distribute on our store to use the SDK. That's why it's available for download freely from the docs 😄
EDIT: My lovely coworkers have schooled me on open source licenses, I now understand Clause 2.6 hah
I'm a bit confused about the SDK stub feature. What happens when there's a change that requires new headers, like a method taking different argument? Will the stub not get the newer version, or will it crash until I recompile with updated headers?
@msciotti so no solution for FOSS? https://github.com/discordapp/discord-rpc/issues/290#issuecomment-488151732
RetroArch, citra, dolphin have RPC integration, but if that gets ever removed it would be impossible to move things forward (well technically there are a few possible workarounds but none of them are ideal)
In https://discordapp.com/developers/docs/game-sdk/sdk-starter-guide, the Discord Game SDK link always refer to the 'latest' version. Do we plan to maintain versions and change logs of SDK? Its hard to know if the SDK is updated. Is it safe to assume these are stable version of SDK and ready for integration? Any open issues being tracked for the same. Any planned timelines for library deprecation or feature addition? Any link to license agreement for using the library?
I made a suggestion about licensing on the feedback website, please upvote and add your arguments there as well ^-^ Hopefully we can discuss with the Discord team so they can reconsider their decision.
@ifonefox: We make updates to the SDK to be backwards compatible. But, in the case that something does happen, we've actually moved to shipping of a "fallback" version of the SDK as of a few version ago.
So, the SDK will first try to contact the local Discord client via the stub. If that fails, we'll try against the "full" SDK that we ship in case something broke. You'll notice the the .dll files are no longer a couple hundred kilobytes, but rather a couple megs.
@fr500: I do not have a solution for FOSS, no, outside of continuing to use the existing SDK here (deprecated) or doing your own IPC (not deprecated)
@anupbelambe: For your questions
-
You can request older versions of the SDK for downloading like so: https://dl-game-sdk.discordapp.net/2.5.3/discord_game_sdk.zip — I can update the docs to have this info
-
Any large changes to the SDK will be documented and added to the Change Log that we maintain
-
These are stable versions, yes
-
We do not have outstanding open issues, just the feature requests that have been migrated to the support center linked above. If something is broken, I'm fine either being DMd on Discord, writing into [email protected], or even opening an issue here. I'd say most of the issues in this repo are integration-specific and not usually the underlying tech, so those may be re-routed to our [email protected] support queue (which I also read).
-
Library deprecation of the GameSDK? No. Also no immediately timelines for new features, other than documentation around achievements that I have to write still. It's in the SDK, just not documented.
-
License agreement would fall under our existing Developer ToS
I want to write an OSS implementation using IPC/socket directly on JVM rather than use JNI/JNA bindings for the official GameSDK
@Bluexin no need for that, this has already been done: Discord-IPC
I want to write an OSS implementation using IPC/socket directly on JVM rather than use JNI/JNA bindings for the official GameSDK
@Bluexin no need for that, this has already been done: Discord-IPC
Yeah I know, I meant it more as a "would that go against the TOS" (as I want to support more of the features that were added for the GameSDK, not just Rich Presence).
@msciotti I have a question, I assume that if the open source application is licensed under BSD or MIT license, the open source clause won't apply?
BSD/MIT are very permissive, it's not a problem for those.
On Mon, May 13, 2019, 12:52 James Moy [email protected] wrote:
@msciotti https://github.com/msciotti I have a question, I assume that if the open source application is licensed under BSD or MIT license, the open source clause won't apply?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/discordapp/discord-rpc/issues/290?email_source=notifications&email_token=AANEFUD7V4DOBURLG22NMKDPVGTEVA5CNFSM4HJHXJMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVJCDRI#issuecomment-491921861, or mute the thread https://github.com/notifications/unsubscribe-auth/AANEFUG5UYXB5K5ALQOZGN3PVGTEVANCNFSM4HJHXJMA .
@moyitpro I'm not really a legal expert, so I'm not sure I can give you accurate legal advice on which licenses are fine and which aren't. My understanding is that some OSS licenses are very very restrictive, while others are not. I'd probably seek some sort of official council from someone who knows what they're talking about to be sure 😄