We are quite aware of the importance of incorporating. There are some open questions about the appropriate jurisdiction, since we have people from all over the world in our group. We are not looking for private funding. This is effectively a hobby project until it is able to make money.

The initial plan is to make a game and probably give it away for free, for the purposes of getting our act together and proving that we can actually produce any kind of value at all. There’s no real point in spending the time/money/effort to incorporate if we can’t actually do anything.

After we prove that the group can function (which will be evident probably before the first game is even finished), we can actually go through the process of incorporation. We can also make some decisions about our licensing and monetization strategies. This is ultimately a group that is looking to make games for the fun of it, with profit being only a secondary goal.

I’m more curious about the choice for Rust-Bevy. I agree that Godot has a number of problems (am making a solo game there), but can you name some of those that got in the way more than they should? Also, with options like fyrox (rust), libgdx (java), monogame (c#), as well as more “full” engines like stride or armory, why exactly bevy?

The #1 issue with Godot is probably that it effectively cannot do multiplayer games, because the physics engine cannot support lag compensation. You wouldn’t need this for something like a multiplayer card game, but for anything where precise timing or physics gets involved, you want lag compensation or your netcode is going to feel bad.

The big issue with most other game engines (including Godot) is really one of performance - in particular, the way that they handle multi-threading. They basically don’t, and this is a problem if you want to do anything with significant simulation elements or or physics rollback (as in lag compensation). Godot attempts to do multi-threading a bit, but it does so very poorly - it’s clear that the devs don’t really know what they’re doing. Modern computers are multi-core machines and they have been for over a decade now. We gotta stop pretending that we can get away with single-threading for games.

Bevy uses an async programming framework in its very core, so everything is multi-threaded if it can be. Combine this with a good ECS implementation and Bevy’s performance should absolutely shred compared to what pretty much any other engine can do (at least when it comes to CPU-bound things - they’re still working on the renderer, but it’s getting to be pretty good).

I have to admit, I did not find Stride when I went looking for multi-threaded/async game engines. I’ll give it a close look.

Regarding the art, what kind of 2D and 3D art is expected? UI, characters, backgrounds, sketches? Cutesy, post-apoc, some other style? Low, medium, high poly 3D objects? Rigging and animation?

We need various art things in various styles, so basically everything you just said. The artist we currently have can do all those things, but they’re only one person. We don’t need every artist to be omni-capable, though. If someone only has a subset of those skills it’s fine.

Lastly, I suppose this will be all work from home, how many hours a week would you expect people to have for this? How would foreign workers fit in, legally speaking? Adding to the latter, how would you deal with significant timezone differences in case of needed virtual meetings?

We already have people from around the world. Most of us have either school or a job, so this is something we’re all just working on in our spare time. Legally, this is a hobby project until we can actually do enough to justify incorporation. When we incorporate, we’ll just be an entity that happens to have employees internationally. We won’t likely care to impose much in the way of hours requirements until we incorporate and start thinking about paying people, but having a few hours a week (around 10?) would be good to start with. Significant timezone differences haven’t been a huge issue for meetings? We are mostly in the US and Europe so far. Things would probably get tricky if someone from Asia joined, but we do have asynchronous methods of communication, and we can schedule meetings for subsets of the team if we need to.

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!