Comment by MarceColl | Hacker News Reader

Comment by MarceColl | Hacker News Reader

I've been building a board game community on ATProto. The idea revolves in trying to build the feeling of local clubs but online, instead of "PLAY NOW" being on the landing page (although you can play now if you want) it's organized around clubs. I also wanted to move away from one game oriented community. I play Go and Chess and I would love clubs to be for mixed games. You can create leagues, or tournaments, etc.

As an extension of that I've been building a small language to build games (with a nice time traveling debugger and automatic replays) inspired by Elm. Go and Chess are both built on top of this and you could fork them and modify the rules. Want to code a new Chess variant? Go ahead! Want to code a whole new game you want to try? Go ahead!

What I'm very excited with ATProto is that because all games are broadcast on it and each shares a core system of turn-based replays (and review system with branching) software can be built on top to do AI analysis, or a replay view. The idea that my application can be extended without me adding an API is very exciting and very much in the direction I want to take the system (community is the core tenet).

How do you prevent a player from manipulating game state outside of the app view?

There is a subgroup in the Atmo working on games, have you found them yet?

I have a referee server handling that. I haven't! I don't even know what Atmo is, tbh.

"Atmosphere" (atmo) is the self-given name for the broader developer community around atprotocol

https://discourse.atmosphere.community/ has game specific discussions to help you find the people to connect with.

There's a variety of different attestation strategies folks have cooked up! For example this crate has some tools, https://tangled.org/ngerakines.me/atproto-crates/tree/main/c...

So far they are mostly trusted authority rather than peer systems. But, since each player owns their own PDS state, one could perhaps just hash the previous state they are working off of. That can at least detect if a game is consistent/agreed to by both sides, allow one player to detect the other's tampering.

Publish the moves, not the game state?

This would imply the game state is stored in a centralized app view, at which point the general atproto ethos that you can move your data if an app becomes bad is up to the app.

I believe the viable solution in a rich permission system is one where the user cannot directly modify a record (as defined by a permission schema for a specific app/type) and can only call methods.

You can easily reproduce a chess board from the moves if you can implement chess.

Most games are not perfect information games. How would you implement poker?

Reply on news.ycombinator.com