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.

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.

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 was actually not aware of the RFC or those other crates. Ambassador and portrait seem kindof similar in their overall approach to how they accomplish things, though portrait appears to be solving a very different problem. My crate allows for forwarding based on conversions and not just delegation to members, which appears to be new (and this turns out to be important for my use-case.). It doesn’t have anything for dealing with code that isn’t in traits, but I wasn’t intending to solve that problem.

I absolutely see why it would be nice to put delegation in at the language level. Most libraries aren’t going to want to annotate their trait definitions just for this (std included), and having the compiler take care of things solves not only that, but also the annotation data format version issues that come with using proc-macros to do it.

It’s a bit weird, though, because my conversion forwarding is actually strictly more powerful than delegation in some ways (but a little less flexible - mixing them grants the best of both techniques). Conversion forwarding allows for traits like FromIterator to be forwarded automatically for wrappers on containers, for example. You can’t do that with delegates. It feels to me like you’d want both if you added either one of them in. The issue with trying to put something like conversion forwarding in is that the compiler either needs to know about the conversion traits (From, Into, AsRef, and AsRefMut)(As I write this, I realize I may have made a mistake in my crate… can guess what it is?) or it would need to be told how to do the conversions, complete with all additional generic parameters and trait bounds that would be required in the trait implementation. That’s either violating some important abstraction boundaries in the language tools, or just extremely verbose.