Plug-and-play development environment
-
I want to develop a game and am considering collaborating with others, potentially even making it open-source.
To make this process smoother, I need to establish an easy-to-replicate development environment—one that can be set up by non-programmers (such as artists) but is also simple for me to configure so I can focus on actual development.
I’ve explored various options (Docker, Podman, Anaconda, NixOS, VMs), but the choices are overwhelming, and I’m unsure which one is best for my needs.
I’ve had partial success with a Fedora+i3wm virtual environment (VM), creating a plug-and-play experience. However, this setup requires extra space (~3GB for the OS) and includes software already installed on the host system. It also requires users to learn i3wm and possibly use the command line, which may not be ideal for everyone.
I would appreciate any advice on how to approach this effectively.
-
Why do you need i3wm? I'm not sure I understand why that's a development requirement.
-
L [email protected] shared this topic
-
Artists will probably have their own setup, software and workflow that they are comfortable with. I’d recommend 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 and devenv will probably be doable as well.
-
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 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.
-
I did it to save on space, LXDE could also be an option but with a bit more space.
-
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.
-
I have seen other similar projects where the setup is a hassle, which is why I am looking into it.
-
No, I mean: why is a window manager a requirement? You're developing a game. Your dev environment requirements should be DE/WM agnostic.
If you intend your collaborators to be using Linux, you should look into Distrobox/podman and have your containerfile ready for deployment. Or just tell people what tools they need installed.
Enforcing a particular DE/WM will make development harder for some people, and it will add unnecessary burden to your project.
-
you definitely don't want to pack an OS and WM in your dev environment
anyone who doesn't already use i3 will be slowed to a crawl until they memorize the keybinds and if they don't already use fedora will need to figure out where everything is -
What you are saying is correct, and why I am looking for a better way.
It was just the simpler for me to set up an complete image that can be used on a VM. -
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.
-
I have absolutely no clue on anything, but as a person that has always wanted to make a game I wish you Luck!
-
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.
-
I take it a step further with distrobox to provide the tooling (like the preferred version of poetry and other cli tools). That ensures people can jump in with the right versions of tools easily, and changes to tooling can be disseminated with a commit (and container build).
But I agree. Get started and solve these problems when they are problems.
-
I set up a very straightforward Godot dev environment yesterday using toolbox which is built on top of rootless Podman.
- Create a new fedora toolbox
- Enter toolbox
- Install DotNet dependencies, git, etc with dnf
- Install Godot binary from release page
- Turns out there were other dependencies I needed
- Godot wanted a Wayland compositor on the container, so I installed Weston
- Godot wanted libxrandr so I added that too
- Godot just works (tm)
The nice thing about toolbox is that it uses my native host Wayland compositor. So whatever I have running in the toolbox can be interacted normally through sway (my host WM).
You can either distribute a container image with your given toolbox configured, or just document the setup steps.
-
It’s a solved problem! Try https://containers.dev/
Artists can just clone the repo and open your project with a supported editor(like VSCode). Done. You can write a config that says what base OS, install packages, and install VSCode extensions (via VSCode workspace settings).
Many projects use this setup and it has been magical.
-
Agreed. They’re also solving problems that may not even exist, building a tech stack that needs to be maintained in addition to the game itself and adding all the baggage of supporting users who have needs that aren’t catered for with that stack (for instance a specific Windows-only tool).
The game engine should abstract most of these problems away. The rest can be solved with standards like what linter/formatter for code, art asset formats and specs, etc.
Solve problems as they arise. Time is best spent writing the game.
-
I agree; and I wanted to mention that you don't need NixOS which is a full distro. Nix the package manager can be installed on any Linux distro, on Macos, or on Windows with WSL. You can set up your reproducible environment by including a devenv config in your repo, or a Nix flake.
There is documentation available for flakes here: https://zero-to-nix.com/concepts/flakes/
-
Oh yeah, and Nix has the advantage that you don't need containers. If you want to run a graphical app in a container it might be tricky to access the window manager on the host system. Maybe that's why you were setting up i3? Yeah, containers are great and flexible, but they also have a variety of downsides so Nix is better
-
Well I, as 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.
