Game design and gameplay is part of the source. All the balancing etc. to make it a fun experience. Most of the numbers don’t show up in the UI, so they’d either have reverse engineer it or reconstruct it somehow through months of game testing.
Yeah in theory people could buy your GPL/AGPL app from you, but they could also get it legally for free from anybody else who has bought it. Guess which way will dominate.
Depends on your point of view. Legally it definitely is, because the LGPL stipulates that nobody is allowed to attach any restrictions on to the code above the things the LGPL restricts itself. This makes it impossible to combine with the App Store, because that store adds additional restrictions.
I can tell you that I wouldn’t invest my time in developing a game if there’s no chance of selling it in the first place due to the license requirements of a third party package.
The LGPL is inherently incompatible with anything on Apple’s App Store, so if there’s a chance that I might want to publish it there I can’t touch anything-GPL.
I just checked again, and apparently they finally added some documentation since I last checked. The section about the macro stuff just used to say “look at the examples”.
clap and bevy are big offenders there. It’s really hard to learn how to use them due to this.
There’s the saying that software development is one of the few crafts where the craftspeople also create the tools for themselves.
OP is talking about a different kind of skill issue than the article. The article is about skill issues in writing Rust code, while OP is about skill issues in choosing the right technology for the right task.
Not picking Rust for code that has to be prototyped quickly and iterated a lot is kinda obvious. The solution would be to use Rust for the core engine where the requirements are clear and something else (lua? Python?) for the gameplay code. Even the engine the author wants to switch to does the same with with the divide between C++ and C#.
Bevy’s ECS is tied up with Rust’s trait system, therefore it’s impossible to use a different language.
Bevy has added runtime-defined systems and components to enable scripting integration in recent updates.
I’ve looked into this. For proper integration (e.g. not as a hack with platform views that require a ton of overhead and multiple separate rendering contexts) I’d need access to the native rendering API in Godot, and the engine doesn’t expose it in any way that I could find.
What’s the error bar on that statement of yours?
I’d instantly reject such an approach. Find a better way to do things.
Rust had the same issue with tokio vs. async-std. I don’t think this was ever resolved explicitly, async-std just silently died over time.
My company is just doing a kanban board with weekly meetings to discuss the progress and what tickets will be worked on next. The major problem we ran into was when management asked “So, when is the release going to be? When are you done with that project?” about one month before we actually released. I simply had no answer at that point, because that’s not something these tickets with no estimates and no velocity tracking can provide.
The gleam name is also already taken by some OpenGL bindings on crates.io.
Bevy UI is so far off from what I need that I didn’t even bother. I started integrating Flutter instead.
Here is a short summary. The compile-time reflection project was stopped, and now nobody wants to touch that subject any more due to fear of getting the wrath of the Rust project again (the person responsible for the whole thing is still part of the leadership).
Unfortunately, it’s not guaranteed to be the same string all the time, so it’s rather useless for anything but debugging and logging.
My experience has been that good documentation is mostly something done if somebody gets paid for the work. People working on stuff in their spare time just don’t care enough to document their project.