We are Ludo Ex Machina. We are a group of aspiring game developers with leftist political beliefs; we are mostly anarchists or anarchist-adjacent. Ultimately, we’d like to incorporate as a worker-owned cooperative.

Since forming, we’ve written a code of conduct and established some barebones internal moderation procedures. We’ve set up some services on one of our member’s personal servers for the group, and we could set up more/different services if we decide we need to. Currently, some of our members are putting together a single player space racing game in Godot.

While we already have a lot of relevant and complimentary skills in the group, we find that there are a few gaps that could stand to be filled.

  • We need 2D and 3D artists. We have one artist, but their time is split between this and another project, and they will have to disappear for a while after they are done with school.

  • We need at least one developer with project management/software development process experience. The one developer we have who currently has this experience in a collaborative context has been too busy to help us with this. We have one other developer who is familiar with software development process, but they have primarily done solo development work previously.

  • We would like to recruit a couple of developers who are comfortable with engine-level development, preferably in Rust. The game engine situation is kind of bad for indie devs right now. Unity and Unreal come with licensing agreements that large corporations can change whenever they want (and Unity has recently made clear that the enshittification has begun in earnest). Godot has technical problems all the way down to the core and a hostile contributor environment. Bevy is technically and culturally the right thing, but it is young and under-developed. Ultimately, we would like to invest in Bevy as our long-term engine pick for game development, but to do that effectively, we’d like to have a development team which is capable of working around the engine’s immaturity.

  • We could use an experienced creative writer. Although various members of our group do have some creative writing skills, none of us have experience working on any large creative writing projects. Some of us have expressed an interest in doing some sociological storytelling in our games, so experience with this style of writing would be a plus.

Feel free to comment if you have any additional questions. Anyone who is interested should send me a DM.

  • Codex
    1•5 months ago

    I’m also very curious on time-comittment and technology choices.

    I do find this proposal interesting; I’ve been considering how to grow more cooperatives and this would be a nice first-hand case study. But between extracting value from the capitalist system for my own survival (aka, day job) and my solo gamedev work I don’t have tons of free time.

    My game is in Rust, not using an engine, but I’ve looked at and tinkered a little with Bevy and Godot. One huge thing you might not expect is that compile time in Rust can be limiting for iteration speed. It isn’t a problem with my little roguelike, but for bigger games you’re going to want data-driven designs and visual editors so iterating on game play is faster. Compiled code you’ll end up saving for critical engine pieces. Bevy is getting there on this, but Godot has first-class editor support and plug-ins for things like 3d tools and level designers (quake levels can be used as a native godot format). All that tooling support is what will really accelerate development and help with polishing and actually releasing the game. Investing heavily in a developing ecosystem like Bevy is fun and exciting but you will spend a lot more of your dev time working on engine things and building tools. That can be time well spent up front if you plan to do a lot with those tools long term, but with an experimental business/social structure you may find that also navigating a lot of technical challenges is going to make things too unstable and chaotic.

    I might do a first game in godot or whatever is easiest to collaborate with, then see where the team’s strength and interests lie before trying to scale out to a more ambitious project.

    I can definitely see why you’re looking for someone with PM experience, and find that an interesting challenge as well. A typical business IT today works under either a “waterfall” organizational pattern like the Software Development Lifecycle (SDLC) where you do a lot of upfront planning and focused development; or else they use some model of Agile, which are focused on small teams and fast iterations of the complete SDLC in miniature.

    For a cooperative game dev team, you have models like Valve’s Cabal to look at, but not a lot of details. Also, they don’t release a lot of games, so without Steam’s infinite money cheat, it’s hard to say how effective that model is for a new team.

    I would probably start by implementing something based on Kanban, which I admit I have a bit of a golden hammer problem with. But you treat each phase of dev as a silo (Engine, AI, Physics, Art, Testing, Design, Multiplayer/Networking, and so on). Features are defined as tickets, then broken down into work units needed to finish. Work units are distributed to silos, workers in those silos pull tickets to work and move them to the next silo when finished.

    There would also need to be a way to distribute and collect information asynchronously. Agile usually functions by using lots of meetings to make up for bad communication. With a distributed autonomous collective, something like a Matrix chatroom and a wiki probably become the backbones of communication. You see the ticket system communicates the state of features and how “done” the game is, but you need higher level tools to build out the roadmap, build consensus on the high level roadmap, prioritize features, and coordinate assignment of work to silos.

    Ah anyway, sorry, rambling! But yeah, obviously this idea has given me a lot to think about!

    • @ZistackOP
      2•5 months ago

      I’ll refer you to my other reply to answer the bits about technical choices for the most part. The extra expense on dev time is a big part of why we are looking for additional developers. We probably wouldn’t strictly need them if we were dealing with a mature engine (though I would appreciate at least one more skilled developer on the team anyways, as right now I am the only active senior dev).

      I might do a first game in godot or whatever is easiest to collaborate with, then see where the team’s strength and interests lie before trying to scale out to a more ambitious project.

      We’ve done a lot to figure out strengths and weaknesses, and a big part of this recruitment push is to cover some identified weaknesses. We’re not dead-set on any particular engine or project at this moment (though probably we’ll try to make sure that the space racer gets finished). It’s just that our evaluation of the situation turned up Bevy as being the likely best-fit engine for our future project ideas.

      I am the dev who is familiar with software process, but in a solo context. A big part of what we need really is the skills to wrangle other people. We’ve got a couple of juniors on board who aren’t super good about communicating what they’re doing/thinking. I know what a good process and useful documentation would look like, but I don’t know the best way to go about guiding everybody else into the process.

      We have a Zulip instance set up for our asynchronous communication backbone (and it does really well for this), but it isn’t getting near enough use because most of the team doesn’t really understand what the process is supposed to look like.

      We’ve also got a Forgejo instance set up, which can do the Kanban process you’re describing (and probably other things as well with creative use of the issue system). Forgejo also supports wikis in a way similar to GitHub.