It is generally advised in the Godot community to use signals as much as possible. I agree, it’s a great way to reduce coupling between components, which allows for a more pleasant experience when testing and implementing new features. However, from my experience, I’ve found that it is not always clear when it’s appropriate to use signals. But I also found a few situations when it’s 100% appropriate to use them. Here’s one of them: ...
My steam game has a leaderboard. No one is playing yet but I hope they will. As a way to promote community for the game I thought it would be cool to get leaderboard updates in official discord community for the game. Here’s how I did it. For this method to work you need to have access to Steamworks Admin page for the game. TLDR Create a Discord Webhook offical doc Get a Publisher key with General key permissions for Steam Web API official doc, scroll to the very end make sure to create a Publisher Key, not a User key if you are unsure if your key works, you can test it with this Get your AppID for your Steam game the best place is steamworks admin page for your game Use ISteamLeaderboards interface of the Steam Web API with the Publisher key official docs specifically, you need methods: GetLeaderboardsForGame to get the Steam internal leaderboardid of your leaderboard GetLeaderboardEntries to the leaderboard entries you can test requests by using Steam Web API reference by xPaw. For hosting, I chose GitLab CI scheduled pipeline, because of its generous free tier. ...
I’ve been doing Steam integration with GodotSteam and made a tricky mistake. It’s not an issue with GodotSteam in particular, but a pattern that is fairly common in GDScript. So, I thought I’d share. Mistake GodotSteam API looks sort of like this (pseudocode): class_name Steam signal leaderboard_find_result(handle: int, found: int) func findLeaderboard(lb_name: String) -> void: ... You call findLeaderboard, which is a long I/O bound operation, so you need to connect to leaderboard_find_result to get the result. ...