I organize Fedijams.
Like this one https://itch.io/jam/fedijam-5
These are foss jams and they try to use fediverse and Matrix for promotion and coordination, but they still have one proprietary tool in the loop: itch.io, a game store.

This is a problem for jams not only by being an ideological incoherency: it is practical too. People seem to be uncomfortable/shy to even hit the join button there (it requires an account), often opting in to just join our [matrix chat] (https://matrix.to/#/#fedijam:m.wfr.moe). And other people who see the low count are less interested as a result.

So, i thought, that for federated game developers, at least for jammers, something much better needed, safer to use and adaptable for specific needs and culture.

A Federated Gamestore

What is the bare usable minimum?

  • Ability to upload games.
  • Ability to host jams (event scheduling, submitting games and rating)
  • No federation. Yes, for FediJams even just a self-hostable gamestore would be useful.

But just that will be very poor and unappealing.

Self-respecting minimum:

  • Decorating game pages
  • Decorating jam pages
  • Not being spartan

The last one is very important for games and gamestores. The concept of game is about joy and having a good relaxed time.

Also, by looking at non-spartan Misskey, i have noticed much more mainstream people. On federated foss network.

Basic federated configuration:

  • Jam federation: between servers, with Mobilizon, and with Masto/Pleroma/Misskey
  • Federated game and jam comments
  • Federated game search

QoL:

  • Search by license
  • Jam tagging
  • Explore better jam interest gauges that just ‘joins’. federation might help with that.

Life:

  • Payments?
  • Donation integration?

Making this happen

Some days ago i started a fork of Game Jolt game store. https://notabug.org/Houkime/gj-fedifork-frontend

Upstream Game Jolt (MIT license) has a ton tracking built in and i also temporary curbed realtime communication/streams that will be the hardest thing to support (after potential payments?) and will need a lot of redesign anyway.

Using Game Jolt frontend as a base provides a lot of visual polish, page editing and anti-spartancy out of the box, and those things seem to be the most difficult and most limiting to get for foss projects.

But Game Jolt does not provide the server, so this one i need to write myself (I am looking at peertube as a reference/template). The frontend does provide though database models _

  • smallcirclesM
    3·
    3 years ago

    Wonderful initiative. I saw you are stripping all kindsa tracking stuff. They are using Google Firebase, for which I’ve seen a number of good self-hosted alternatives pass by (but I haven’t tracked them, so forgot the names). Do you intend to re-license the codebase? AGPL might be better suited for a community-driven project.

    Some brainstorming…

    I am not familiar with Gamejams. What is the value of the game being uploaded to the server? Or do you mean the game info / presentation only? There’s the Murmurations protocol I am having an eye on for some time. It would lend itself very well to be federated. See Federating the Murmurations protocol.

    In theory Murmurations (the idea of it at least) can be used here as well. It turns collecting and maintenance of lists upside down. With it someone who has developed a game and want to submit to a gamejam, would host a Profile of their entry on their own environment, and register it with their own Gamejam server, from where it federates to all other instances connected to it. This profile would include locations where you can obtain the game. This also means that that person stays responsible for it, and not the Gamejam server host (think uploading a game with a trojan in it).

    The Gamejam server could be only an information exchange / sync / storage platform, back-end only, and - through its API’s - have multiple different front-ends be attached to it (one you are already working on now) that independently evolve. Another app that follows this concept is GoToSocial. On a different note @deadsuperhero@lemmy.ml is brainstorming on a project to investigate different UI components to render from ActivityPub message formats, and this is an interesting concept.

    In this thread a whole bunch of possible integrations with other apps are mentioned, like Peertube and Mobilizon. But these are 1-to-1 very app-specific integration. Unfortunately this is the current reality of facilitating interop on fedi right now. It will lead to ever more incompatible implementations and increasing complexity that will hurt the fediverse in the long run. The Gamejam concept would benefit if it was easy to integrate components of it anywhere, and not too tightly coupled to one specific UI ‘interpretation’.

    Just some random 2cts for now. Very cool project!

    PS. What I described aligns with From silo-first to task-oriented federated app design I wrote some time ago.

    • Houkime@fapsi.beOP
      3·
      3 years ago

      Firebase here was used to store user client settings.
      I disabled this (It is using defaults) and also deleted this from package deps.

      The value of the game being stored on the server is that games are usually big (100+ mb) and for example git forges tend to have strict limits on file size. Unlike with peertube though, the headcount of games is way smaller than the count of videos, so largish uploads at game stores are totally ok, and also torrenting might be unnecessary, at least at first.

      It is also used to count downloads. This sort of harmless analytics i plan to reenable in the future. Views and downloads. Maybe browser plays.
      It is everything i use on itch, and it should be enough for gamedevs to roughly measure interest. It will also be used if there will be payments eventually, or at least download tokens that you purchase from the dev manually.
      The scheme with manual download tokens can be wider than just monetary payments. It can also be about promotion or even code contributions (not neccessariy to the same game! A dev can just say: Contribute to Godot in a nontrivial way and i will give you a token).
      Or just manual handout of the game to people the dev knows/decides to give access. Like with follow requests on masto.
      I believe that sort of schemes could be especially popular with LGBTQA+ communitites, just as locked accounts are.

      I do however think that it might be benefitial to separate the services of storage and jamming, if only just to allow parallel evolution. It can be done on protocol level so that for example gamejolt like servers can federate with more lightweight jam servers.