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.

Edit: An example of things to setup:

  • The right .Net Sdks version
  • Git
  • Git LFS
  • Format Checks
  • VScode (+ extensions)
  • Godot (+ extensions)
  • catloaf@lemm.eeEnglish
    221·
    2 months ago

    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.

    • heartbreaker@lemmy.worldOP
      5·
      2 months ago

      I have seen other similar projects where the setup is a hassle, which is why I am looking into it.

      (changing requirements, custom scripts, extension)

    • fartsparkles@lemmy.world
      3·
      2 months ago

      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.

  • linuxoveruser@lemmy.ml
    15·
    2 months ago

    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.

    • hallettj@leminal.spaceEnglish
      41·
      2 months ago

      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 ;)

    • hallettj@leminal.spaceEnglish
      31·
      2 months ago

      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/

  • unlawfulbooger@lemmy.blahaj.zone
    15·
    2 months ago

    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.

      • Telorand@reddthat.com
        15·
        2 months ago

        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.

        • heartbreaker@lemmy.worldOP
          3·
          2 months ago

          What you are saying is correct, and why I am looking for a better way.
          It was just simpler for me to set up a complete image that can be used on a VM.

  • Dr. Wesker@lemmy.sdf.orgEnglish
    6·
    2 months ago

    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.

    • Botzo@lemmy.world
      2·
      2 months ago

      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.

  • dangling_cat@lemmy.blahaj.zone
    5·
    2 months ago

    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.

  • utopiah@lemmy.ml
    4·
    2 months ago

    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

  • just_another_person@lemmy.world
    51·
    2 months ago

    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.

  • Horse {they/them}@lemmygrad.mlEnglish
    4·
    2 months ago

    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, plus some people just really hate using the keyboard for 90% of navigating, and if they don’t already use fedora will need to figure out where everything is

  • OneCardboardBox@lemmy.sdf.orgEnglish
    2·
    2 months ago

    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 few Wayland libs on the container, so I installed Weston (maybe overkill)
    • Godot wanted libxrandr so I added that too
    • Godot just works ™

    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.