Ideas for building a federated Roblox alternative

The requests (RedLib links):

https://farside.link/redlib/r/fediverse/comments/143j1j8/is_there_a_3d_metaverse_of_the_fediverse/

https://farside.link/redlib/r/opensourcegames/comments/rdub3p/comment/ho43ld1 (link to comment)

Fediverse games in general

The discussion:

https://lemmy.ml/post/87083

The requests (RedLib links):

https://farside.link/redlib/r/fediverse/comments/iad25v/any_good_federated_gaming_platforms/

https://farside.link/redlib/r/gamedev/comments/12e7fum/game_on_fediverse/

The rejected Minetest suggestion:

https://github.com/minetest/minetest/issues/7993

A blog

https://kevinhoffman.blog/post/fediverse_gaming/

  • h3ndrik@feddit.deEnglish
    16·
    5 months ago

    Hmmh. Why ActivityPub? I mean I suppose it’s alright as a standard for some turn based or slow trading game. But it’s neither very efficient nor suited for realtime. And having long (and descriptive) JSON messages, queues, … is baked in per design.

    And it’s not even interesting to a Mastodon user if player x sold y latinum to player z. So for lots of game logic we don’t need messages in a common format that’s federated to Mastodon, Lemmy, Peertube etc.

    I think a nice and not too complicated coding challenge would be to design a world that spans multiple servers. Players could roam a world, go through some door or portal and the client seamlessly connects to the next server. So that part of the world (the other server instance) is behind that portal. That’d make sense from an in-game perspective and won’t be that hard to implement. Basically it’s just like any other game, just that the client auto-connects to servers with some internal logic and not just in the start menu. And ideally authentication would be federated. The new server could ask the player’s home instance to authenticate them on entering the new instance.

    • hankskyjames777@kbin.runOP
      2·
      5 months ago

      alright as a standard for some turn based or slow trading game neither very efficient nor suited for realtime

      only in itself, it can be “temporarily solved” using an extension (like what Forgejo has for relations to Git, e.g. commits) for realtime, it could be something like how godot implements P2P multiplayer (over ICE/TURN/STUN) for federation between servers

      • h3ndrik@feddit.deEnglish
        3·
        4 months ago

        I’m not sure if ActivityPub allows for an extension like that. And I mean if you open up a separate direct channel via TURN… It’ll be incompatible with something like Mastodon anyways, so I then don’t see a good reason for why to bother with the additional overhead of AP in the first place. I mean you could then just send the status updates in some efficient binary representation as data packets directly do the other players. So why use ActivityPub that needs to encode that in some JSON, send it to your home instance, which handles it, puts it in the outbox, sends HTTP POST requests to the inboxes of your teammates where it then needs to be retrieved by them… In my eyes it’s just a very complicated and inefficient way of transferring the data and I really don’t see any benefits at all.

        So instead of extending AP and wrapping the game state updates into AP messages, I’d just send them out directly and skip AP altogether. That probably reduces the program code needed to be written from like 20 pages to 2 and makes the data arrive nearly instantly.

        I suppose I could imagine ActivityPub being part of other things in a game, though. Just not the core mechanics… For example it could do the account system. Or achievements or some collectibles which can then be commented and liked by other players.

        • NataliaTheDrowned2@kbin.run
          3·
          4 months ago

          The TURN channel could be used ONLY for live multiplayer interactions (and everything else that needs dynamic state updates), while everything else (e.g. game data, achievements, avatar data, other static things) would be in AP