You should be fine with just Godot for now. Don’t over-engineer things until you need to, or you’ll just scare away potential contributors.

If you need to test portability, try spinning up a VM or a second system and getting the project running on that new system. You can work out the issues from there.

A final thought: one method for open sourcing commercial games you may want to consider is separating the assets and engine into multiple repositories, with a restrictive (paid) license for the former. The engine can then be openly developed by owners of the game.

Of course, I’m gonna support anyone who open-sources the FULL game but it’s worth considering if you’re thinking of this as a hobby project or a commercial venture.

I think you’re really putting the cart before the course here. Start making the game and solve these problems as you need to.

I was collabing on a game with an artists (godot + git) and they just used the github gui for windows and it worked great. They just made art in their program of choice and drag and drop into the folder. They clicked push button and it worked for a game jam.

Afaik Godot is designed specifically to be portable , so unless you’re wanting to use cutting edge features of unreal or something, you can use that and let everyone else focus on their own tooling.

Only use a dev environment for things that need dev environment. Use whatever your coding team is already familiar with.

Interesting idea to take “non-programmers (such as artists)” out of their normal professional workflows (e.g. adobe creative) and putting them in yours for the sake of productivity. What hardware are we talking about? Are you running a vm? That won’t work on apple silicon. (Which creative types overwhelmingly use)

Bonus question: You “want to develop a game” and are “considering collaborating with others”? What’s the scale and where are we at with making the game? Because worrying about your team’s workflow sounds a lot like having that $10 million idea and buying a domain name before writing a line of code.

That said, I’ve done this kind of thing before. Pick something. Anything. And write scripts to automate most of it. You will never get a 100% turn key solution, and everything has a tradeoff. Solve enough of the problem and go work on your game.

You’re spending time focusing on the wrong things. Publish the code, list the dependencies to build it (preferably with a way to install them, like python’s requirements). That’s it.

Well I (a developer) collaborated with an artist (3D modeler) recently and… I did not ask them to install anything.

Instead what I did is a develop a Web drag&drop page. They’d visit it, drag&drop their model and… see if it worked (e.g. visually or running animations) as they expected. That was it.

IMHO finding the boundaries that are important, and thus how to collaborate, is more important than a unique reproducible environment when roles are quite different.

TL;DR: IMHO no, you don’t, instead find how to actually collaborate.

set up by non-programmers (such as artists) […] requires users to learn i3wm and possibly use the command line

Nix is probably the best way to get all of those things set up without shipping a whole distro, but there will be a bit of a learning curve. If you’d like something a bit easier to set up for development (still based on Nix), I’d recommend devenv.sh.

Artists will probably have their own setup, software and workflow that they are comfortable with. I’d recommend letting them use their own workflow, and just discussing the interface, so to speak: what file format(s) to use and such. I think GLTF is used for assets, but I’m definitely not an expert.

As for other devs, most required tooling (e.g. Unity or Pycharm or whatever) are one-time installs that you can list somewhere. And language libraries/dependencies are a solved problem (e.g. pipenv, cargo, yarn).

But if you really want to set this up, nix (or lix) is probably your best bet for a total devenv that is exactly reproducible, assuming that works for WSL (or no one uses windows).

Otherwise docker/podman or devenv will probably be doable as well.

Here’s my commentary on the options you listed in the image:

Anaconda: They changed the licensing so that it’s not really fully FOSS, as the repos have restrictions on them. There are also other issues like this dark pattern of a download page.

But, forgetting about the licensing or problematic company practices: The software itself is trash. Worst thing I’ve ever used. It’s sooooo slow to install packages when it’s doing the “solver” thing. You can use something faster like mamba or miniconda, but then you still have to deal with package availability being poor, as the anaconda repos don’t have everything, and much of what they have is often too old.

Docker desktop: It’s proprietary. I mean you can use it, but you seem to be interested in open source stuff. Also see caveats to podman desktop below.

Podman Desktop: Technically this will work. But podman desktop is really designed more for development of containerized applications, rather than developing in containers.

Nix: Nix doesn’t work on Windows, so you would have to require WSL or something like that.

Fedora VM: I recommend enlightenment as a desktop environment. Very small, but also modern and clean looking. You’ll have to configure it to be a bit more similar to windows, but it’s a lot more intuitive to use than i3.

There are some other caveats to your environment. “The right .Net Sdks version” — however, the best extensions for C# development are proprietary and cannot be freely used in the fully FOSS versions of vscode.

it also requires users to learn i3wm and possibly use the command line, which may not be ideal for everyone.

Yeah, don’t do this. I agree with @[email protected], work with them, rather than forcing them to work with you. Collaboration goes both ways.

Another recommendation I have is to just see how people in a similar circumstance do what you do. There are plenty of people who do software and game development on twitch, and you can just go on their streams and ask how they collaborate. One method I saw is using trello, a task management software, and artists would upload models there as deliverables. They already have their own workflow, which they probably work efficiently with. And it’s not really the job of an artist to integrate models and art into the game, that’s the programmers job.

you probably really shouldn’t do that.

Why do you need i3wm? I’m not sure I understand why that’s a development requirement.

VS Code has dev containers, which can be nice.

But honestly, this is all overboard. Not sure what language you’re working in, but this is what virtual environments are for. For instance in Python, you can use a tool called Poetry.

It really depends on what you intend to develop in, but I can say containers aren’t the way to go whatsoever.

Every gaming SDK or IDE I’m aware of has their own version of sandboxed environments. You just start a project, clone it, then let their package management tooling do the rest.

Maybe if you explain a bit more about your approach you could get more constructive answers.