pull down to refresh
78 sats \ 1 reply \ @seashell 13 Jun \ on: Nostr Game Engine v0.0 - Released nostr
Nice work on the WebRTC + Nostr combo. Cutting out middleman signaling servers is smart. How does it handle relay outages or flaky connections? Any backup or fallback plans? Once this sees more real usage, what’s the plan for anti-cheat ? Especially for leaderboards or any persistent data tied to pubkeys.
Demo runs smooth. I’ll jump into Sea of Nostriches soon. Really refreshing to see something real shipped instead of hype.
Cutting out middleman signaling servers is smart. How does it handle relay outages or flaky connections? Any backup or fallback plans?
It can use multiple signaling relays simultaneously. Since signaling packets are very small, it's safe to include a large list of public relays in the game.
As long as both players have at least one reachable relay in common, they can initiate the RTC connection. After that, traffic goes peer-to-peer and is handled by WebRTC, which generally does a good job managing flaky or changing network conditions.
The developer can also make the relay list configurable in the game settings, so players on a LAN, for example, can specify a local relay.
Aside from that, depending on the type of game, it might need a lag compensation algorithm (e.g., to extrapolate delayed position updates). This is game-specific and something that's typically required in any multiplayer game with a high packet rate, even in client-server architectures, because networks are just not so reliable in general.
Once this sees more real usage, what’s the plan for anti-cheat ? Especially for leaderboards or any persistent data tied to pubkeys.
This is further ahead in the roadmap, but it's likely to include a reputation-based anti-cheat system.
The engine will support tying game activity to a public key (that could be a random anonymous key) and casting votes using game-specific logic. These votes will influence the reputation of the associated public key.
It will be possible to filter results, connections, and other elements based on these votes, weighted by the reputation of the pubkeys who cast them. This would allow features like leaderboards or matchmaking restricted to players with a certain reputation threshold.
There may also be integration with signing mechanisms and TPMs as part of the DRM milestone, though I’ll need to research that further.
Of course, nothing prevents a developer from implementing any anti-cheat measures within their game.
However, I want to avoid including in the engine codebase any solutions that:
- Are intrusive or interfere with the operating system (e.g., kernel-level anti-cheats)
- Compromise player privacy by requiring real identities or linking activity to a main public key
- Make the engine difficult to port across different platforms
reply