Add Package Collections for Content Curation

[Montandalar]

Problem

Users may often want to download a set of related content e.g. different trains for advtrains, different vehicles by APercy, a few different mobs to populate their world with etc. Users also benefit by curators creating good sets of compatible mods.

The existing approach for content curation consists of either creating another "game" that is based on Minetest Game, or a modpack. Both have a large maintenance burden. The game or modpack author has to update every mod individually and restructure modpack directories to avoid nested modpacks. Game authors must also update the mods that are a part of their base game. Even a modpack that just wanted to bundle advtrains with basic_trains would have to restructure those two modpacks to avoid nesting before distributing them on ContentDB. Those mods also don't logically belong in a modpack - people just want to install them together sometimes, for instance "Blockhead's Favourite Trains" is not a good modpack idea, but it is a good collection idea. Also, if there was also a texture pack that the curator wanted users to use, they would have to ask people to separately install that, because it can't go inside the modpack. It would be better to have a way for a user to ask for collections of packages to be installed at once.

ContentDB does have functionality to automatically install dependencies, but this doesn't make it easy to install several content packs for one base mod, just like trains, vehicles or mobs as previously mentioned.

Solutions

The Steam Workshop allows users to create "collections", which identifies multiple Workshop items to all be downloaded (subscribed to) at once. These are popular for distributing mods along with their dependencies, which ContentDB handles another way. But another outcome of this system is that content curators can create a set of curated content to be used together. Also, unsubscribing from a collection removes any of its dependencies that aren't individually subscribed to.

To help content curators create and to help players follow recommendations more easily, ContentDB should allow signed-in users to create Collections. Collections will designate versions of packages to be installed together. There should also be a system to notify Collection maintainers that there are updates to mods in their collection.

When browsing the Collections section, users can see all packages in a collection and their versions, plus the usual images, textual description, ratings, comment threads and versions that are attached to any other package. When installing in-game, the Minetest client should offer to download all of the packages automatically, and warn if there is a version difference on any version of any of the packages installed as compared to the one in the collection. Note how the language is content-type agnostic: Mods, Games and Texture Packs could all be part of collections.

The Steam Workshop mandates updates; often Garry's Mod, for instance, will automatically update all versions of all content as soon as you open the game, or even before it, depending on Steam update settings. ContentDB's collection system should probably not force updates, as many people manually manage their mods in Minetest. However, Collections should be shown in the in-game ContentDB browser as Collections, and users should be able to update their version of the collection.

Users should be able to remove Collections. This will remove any mod that was only installed because of its inclusion in a collection, but leave manually installed packages alone. This will necessitate tracking much like other package managers of what is manually installed and what is only installed as a dependency; ContentDB has a file in each mod directory for purposes like this I think?

Alternatives

Continue to only accept modpacks and games on ContentDB, and push the burden of maintenance and marketing back onto curators/modpack authors, as well as leave the overall discoverability of content on ContentDB at its current, but lower, value.' This would be more viable if the engine were to support nested modpacks.

Additional context

This change would affect both this repository and minetest/minetest.

Collections could include any packages at all from ContentDB. For instance, "Minetest Game Jam 2021" could be a collection as well. Some combinations of packages wouldn't make sense: "Soothing 32" together with "Snake 3D" wouldn't make sense together; but I think it is up to the Collection author to make sure their Collection makes sense. Also, some collections would just be "my stuff" type collections, for instance for a person to be able to install their favourite content on any device with only a few steps. That's okay - the rating system will make better collections show up over those types of collections anyway.

[Montandalar]

Modpack nesting now works fine as of 5.5, so that part of the rationale is somewhat obsolete. However, I think the point still stands that making a ContentDB collection should be easier for both curators and end users than a modpack.

[rubenwardy]

This is on my roadmap to be implemented soon. It'll be a web only feature to begin with but adding supporting in the client would be done eventually. I don't think I'll implement this as a type of modpack or a new type of package as the data is completely different

Here are some more examples of things that can be collections:

• Spotlight and featured packages
• Game jams
• user curation (users will be able to make their own collections. This can be used for curators link on steam. Users will be able to add their own descriptions per package, and order them)
• User favourites (eventually, I'll automatically create a favourite list for each user and add a favourite button. But this won't be in the MVP)

I'll be able to remove the existing gamejam and featured tags, and remove the protected tags feature

[rubenwardy]

I'd like users to be able to use collections to make guides as well, using markdown content. So I'd like there to be a way of customising how the page displays. There's two ways I can think to do this

1. Block-based method

The user could add either package or markdown blocks to the page. Package blocks display as a card to the package. Markdown blocks display as HTML elements from the markdown. The description of the package card can be customised using markdown as well

Collection table:

• Title
• Name (used in url)
• Author
• Short description (plaintext)

CollectionItem table:

• Collection
• Package (nullable)
• Markdown content (nullable)
• Order (Int)

2. Freeform method

The collection table could contain markdown content. The markdown content could have some way of referencing packages in the list, ie: @author/name, to show in the content as a card. You'd have a list of packages and a single markdown description. Not sure whether you'd be able to order the list of packages or whether the order would just be in the markdown description.

This would be much more freeform, but would mean you can't programmatically find out what text relates to what package. This only matters if you want to show snippets from collections on packages, like Steam's curator system, but we have reviews for this.

Extending markdown is quite painful.

Was thinking like this, the cards will be the packages mentioned by @author/name

Collection table:

• Title
• Name (used in url)
• Author
• Short description (plaintext)
• Markdown content (nullable)

CollectionPackage table:

• Collection
• Package

3. Plain list method

Users can add packages to the list and order them. Users can add a short description per package.

[rubenwardy]

I suppose I could start with option 3 and then add option 2 at a later point. As long as we definitely don't want option 1 (which I think I've soured on)