Deprecation and Migration to Discord GameSDK

[msciotti]

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:

• [Feature Request] Allow multiple IPC connections from the same SDK instance #202
• Ability to switch between open clients of Discord #203
• [Request] Launch applications using launch options. #94 (if launched from the Discord library)
• Allow setting Rich Presence activity types via RPC #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

• Get the New GameSDK
• Rich Presence Replacement Functions
• New Place for Feedback and Feature Requests

[yourWaifu]

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.

[Lachee]

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.

[night]

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.

[Lachee]

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?

[MinnDevelopment]

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.

[MinnDevelopment]

I can't find a license for this new SDK. Is it not licensed?

[msciotti]

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.

[MinnDevelopment]

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.

[night]

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

[msciotti]

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.

[yourWaifu]

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.

[Lachee]

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?

[msciotti]

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.