pull down to refresh

Hey everyone,
I’m @rblb, a developer.
You might recognize me from my work in the bitcoin and nostr space, or maybe from my time as a core maintainer of jMonkeyEngine. But for most of you, this might be our first time crossing paths, so hello, nice to meet you.
Let me show you what I’ve been working on:

I'm excited to drop the first milestone (that I call v0.0) of something I've been building for a while: Nostr Game Engine.

What is Nostr Game Engine?

Nostr Game Engine is built on top of the modular and proven jMonkeyEngine.
What makes it different? I'm gradually swapping out the internals with Nostr-based modules to create a reference engine purpose-built for decentralized games.
This first release delivers these key capabilities:

Peer-to-Peer Networking

Forget centralized game servers. Nostr Game Engine gives you real P2P multiplayer, using WebRTC for data streaming and Nostr relays for coordination.
Want to dig deeper? This is a draft NIP that is a revised version of this other draft NIP, that details how the signaling works.
Now, WebRTC is already peer-to-peer, but its signaling phase typically relies on specialized central servers
/Not your signaling servers, not your p2p connection!/
By coupling WebRTC with Nostr, we take signaling decentralized too by relying on a network of dumb public relays that are oblivious to what encrypted data we send to them and are easily replaceable.
(see the documentation for more info)

Nostr Authentication & Gamertags

NGE has a fully managed Nostr Auth flow, with support for NIP-49 encrypted local nsecs and NIP-46 remote signers.
It also fully handles metadata, including external identities: your profile picture, display name, and other details can carry over between games, and even from other Nostr clients and communities (nostr’s Steam, maybe?).
This release is also introducing Gamertags: persistent gaming handles tied to your Nostr pubkey. They work like Xbox Gamertags or the old Discord handle, but they’re decentralized and follow you across any game that supports them (check this draft nip for more info).

Match Making

While matchmaking is planned for a later milestone on the roadmap, I’ve started implementing it early to help with testing RTC connections.
In this release, there are already the APIs to create lobbies that are discoverable and optionally password-protected. Players can search and filter for lobbies using both client-side and relay-side filtering, depending on what the relay supports, so it kinda Just Works™.
Right now, you can’t see how many players are in a lobby, and the feature is still a bit rough around the edges, but it's a solid start, and more improvements are coming as we move further along the roadmap.
The cool part? You don’t even need to know Nostr is running under the hood. The engine exposes simple APIs like createLobby, findLobbies, and connectToLobby, the developer can call them when needed, and the engine handles all the relay querying and data stitching behind the scenes.
(see the documentation for more info).

A new Nostr Client Library

To power all of this, I built a new Nostr client library from scratch, designed for performance, asynchronicity, and memory efficiency. It’s lean, fast, and built to be the foundation for everything that comes next.

Cross-Platform and language of choice

The entire codebase is written mostly in Java, and it builds natively for Linux, macOS, and Windows. Support for Android, iOS, and Web Browsers is on the roadmap.

Why Now?

This project was made possible thanks to funding from OpenSats, but I held off on announcing or hyping it right away. I wanted something real to show. That extra time gave me the space to not only write the code, but also put together an Almost Complete™ documentation, an app template, and a tech demo (more on that later).
So now, you can get a real feel for the engine, see what it does, play around with it, and maybe even start experimenting with your own ideas.

Roadmap

This is just the beginning. There is a full roadmap on the website.
Upcoming milestones include ads, deeper identity features, and tools that make decentralized game development as smooth as possible.

Sea of Nostriches

This is the demo I built for this initial release.
You start alone in an open ocean with a boat, nothing much at first.
But as soon as another player joins (another peer), your boat begins sending data directly to theirs via peer-to-peer communication. You’ll see this visualized as a stream of numbers moving between boats in game..
If you have a profile picture set, it’ll automatically appear on your boat’s sail, and you’ll see others’ profile pictures on theirs.
That’s the core of it.
It is not a real game, as there is nothing really to do, no lag compensation, no score etc… but it is a decent reference, and what I would consider an “integration test” at this point.
There’s a lot more going on behind the scenes, like how the ocean is simulated or how rendering is handled, but that’s beyond the scope of this post. You can check out the full source code on GitHub, along with native builds for all supported platforms and a portable JAR.

That’s all for now! If you have any questions, feel free to drop them in the comments. I’ll do my best to reply. Check out the website at ngengine.org and browse the docs at ngengine.org/docs if you want to dig deeper.
Hope you enjoy what I’ve built so far.
78 sats \ 1 reply \ @seashell 11h
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.
reply
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
I'm too dumb to follow most of that, but "nostr's Steam" makes sense to me.
Awesome!
reply
Holy cow this looks so cool!! Awesome work!!
This is aimed to real time multiplayer games?
reply
Thank you! The main feature in this release is p2p networking, which is great for real-time multiplayer games. However, the engine will have features that will benefit single-player games as well.
These include in-game Nostr-based advertising, shared leaderboards, verifying game ownership, and even syncing game saves across devices. All of which could be interesting for single-player developers too.
reply
If it even serves you, ages ago I programmed an original 2D board game in python. Use as you please if you find it interesting:
reply
21 sats \ 1 reply \ @k00b 20h
Man, this looks so cool. I wish it ran in a browser lol. Whatever happened to java applets?
reply
Thanks! Java applets are dead, but this is going to be transpiled to javascript with teavm in ~1.5 months (just the time to get some more nostr stuff on the codebase first)
Support for Android, iOS, and Web Browsers is on the roadmap.
( I've already ported the original jMonkeyEngine ages ago. )
reply