Tighter integration of custom levels

[InfoTeddy]

Right now, to play a custom level, you must manually download it and drag it to the levels folder. This is inconvenient.

There are two things we could add to make custom levels more convenient to download.

1. As some players have suggested, add Steam Workshop support.
2. Add our own download integration with remote level repositories, defaulting to the VSIX levels database.

With Steam Workshop:

• Con: Vendor lock-in. I personally want a way to download all the level files from the Workshop just to avoid being totally locked in to Valve's ecosystem. While Valve long has a reputation of being benevolent, they did recently just DMCA a Team Fortress fan mod, so... they're not actually that great.
• Con: Other users (GOG, Itch, Humble Store, etc.) will not be able to use the Steam Workshop. This is especially true for Make & Play, as the entire point of Make & Play is to provide users with access to custom levels without having to buy the game.

With a level downloader:

• Pro: Anyone can use the downloader and they don't need to specifically buy the game on Steam.
• Con: I mentioned the idea to @flibitijibibo and he said putting us in cURL territory puts us in "infinite security maintenance" territory, and that is scary to do.

Some other things we could add:

• Dragging and dropping a level file on the game window to automatically copy it to the levels folder.
• Integration with right-click context menus and/or file associations.
• A URL handler for level downloads.

Thoughts?

[flibitijibibo]

A quick stopgap measure would be to add support for dropfile events, so users can drop the downloaded file directly onto the game window and we can copy it to the levels folder ourselves.

[InfoTeddy]

A quick stopgap measure would be to add support for dropfile events, so users can drop the downloaded file directly onto the game window and we can copy it to the levels folder ourselves.

That'd be good to have too. Reminds me of right-click context menu integration (which was proposed in #967) and/or file extension integration (although that wouldn't work with .zips).

[Daaaav]

Con: I mentioned the idea to @flibitijibibo and he said putting us in cURL territory puts us in "infinite security maintenance" territory, and that is scary to do.

I don't think we have to ship our own cURL with the game, we could use system-provided functionality:

• The system libcurl on Linux (cURL is one of the few libraries that's priding themselves on keeping their ABI stable, and has done so for decades, so we could just dlopen it right?)
• WinINet on Windows
• NSURLSession on macOS

I have personal experience with this - Ved has wrappers for WinINet, NSURLSession and wget (haven't gotten around to replacing wget with libcurl yet). The downside of course is that this introduces OS-specific code. But it's not that extreme, if we just need one or two wrapper functions like https_request(url) that returns the contents, and could be isolated into its own files. Maybe there are even libraries that do this exact thing - provide an API for HTTPS access that calls the respective OS's native APIs without shipping crypto. Or maybe it's an idea for SDL.

A quick stopgap measure would be to add support for dropfile events, so users can drop the downloaded file directly onto the game window and we can copy it to the levels folder ourselves.

This would also be a really cool thing to have. Maybe for sharing a level with others, there could also be a "share" hotkey which opens and highlights the level file in a file explorer for you or something?

[Daaaav]

NSURLSession on macOS

Actually, now that I think about it, doesn't macOS ship libcurl too? So that'd mean we may be able to use the system libcurl on both Linux and macOS, and then only still need to worry about WinINet.

[leo60228]

Once we move to using the C++ implementation on mobile, we'd still need to have an NSURLSession backend for iOS. Additionally, I'm not sure that Apple guarantees ABI stability for their downstream libcurl.

[darkhog]

I think mod.io should be considered. Despite the name, it's basically an independent Workshop reimplementation and can be used for any stuff Workshop is normally used. 

The con is that any UI that allows upload/download of the content needs to be coded by hand (they do have bindings for all the popular game engines, however it's not really applicable here as this game uses a custom engine).

Among the notable games that use mod.io for level sharing are

• Super Dungeon Maker (a legally distinct Zelda Maker)
• Prodeus (a boomer shooter)
• Baba is You (you probably heard about this one, though not sure if it is using mod.io as a backend or if Hempuli rolled his own server)
• Probably more I either don't remember now or don't know about.

[NyakoFox]

If we were to use something external, I think it should be vsix.dev. We have full control over what goes on there, and that's important if it'll be considered for in-game, where everyone would be able to see levels.

[darkhog]

If the issue is moderation, you can moderate mod.io items. I know Super Dungeon Maker is rather heavily moderated after people started uploading some questionable stuff. Plus not having it on your own servers absolves you of any responsibility if something bad is found and not removed in time, it's mod.io's problem now. Also, it will require huge amount of space to worry about, just ask romhacking.net how it went for them.

[InfoTeddy]

If the issue is moderation, you can moderate mod.io items.

The issue is not moderation. I am concerned about vendor lock-in. Is there an official supported way for us (admins of the repository) to download all the items?

Plus not having it on your own servers absolves you of any responsibility if something bad is found and not removed in time, it's mod.io's problem now.

This is not really compelling unless you are arguing from a legal perspective. And even then, if we host it in the United States then Section 230 should shield us from such liability.

Also, it will require huge amount of space to worry about, just ask romhacking.net how it went for them.

I was under the impression that Romhacking.net had much bigger issues than storage space. Disk space is really cheap anyway.

[darkhog]

See mod.io docs for any info, but my impression is that as an admin you can download entire mod.io repo or even use your own servers: https://docs.mod.io/

[rylarolls]

Speaking as an outsider but from what I see there's not really any pros to using mod.io over a site owned and ran by the people in the community. There are however plenty of cons and risks that can be avoided by simply taking it into your own hands from the beginning.

[darkhog]

The pros are that you don't have to actually write any server-side code dealing with handling uploads, authentication, etc., only working on the client-side of things. Also mod.io has a C++ SDK so you may not even need to write code that doesn't specifically deal with how the game handles levels that have been downloaded. Also don't get NIH syndrome. No need to reinvent the wheel.

[NyakoFox]

we have vsix.dev, i've already written the server-side code for uploads, authentication, etc. i can easily write a client as well. what you're asking for is not something we'd add -- we already have our own system. no need to reinvent the wheel.

[InfoTeddy]

Also don't get NIH syndrome. No need to reinvent the wheel.

This is not NIH. We only use existing solutions if they are a good fit for us. If they aren't, then it's better for us to create our own. For example, we use C-HashMap instead of writing our own hashmap code, but we removed the use of UTF8-CPP because it had several problems for us and replaced it with our own UTF-8 implementation.

Same applies here. If we reject mod.io, it is not due to NIH.