It's coming together.
It's coming together.
When will the docs improve? I look at the release notes and ideally every one of those features would have several pages of docs. I understand that's a lot of work, and maybe things will have to stabilize before we get full docs?
What's missing is tutorial type documentation, but individual features are generally documented.
This meme needs to die. I've seen "10 layer abstraction heavy" code base only once
The code was simulating hardware/firmware behaviour when the real impl. was not available, and when the real impl. was delivered, then it was called instead.
So that was quite reasonable why they went with this like that.
Normal apps are mostly MVC-like where controller receives HTTP request (like 5 LoC?),
moves it to some handler which performs business logic / calls db and the returned stuff is either HTML or JSON.
That's your average web app.
I've seen a codebase where half the features were implemented by inheriting the controller class and adding some behaviour and then that wqs wrapped in another layer adding more behavior. It had about 5-6 layers of that. I guess it's not 10 layers, but it was still extremely shitty code that was very not fun to deal with.
* Start with a blank `main` file and proceed linearly down the page, executing as I go.
* Gradually pull out visually awkward chunks of code and put them into functions with no arguments at the top of the file.
* If I need to parameterize them, add those parameters as needed - don't guess at what I might want to change later.
* Embrace duplication - don't unnecessary add loops or abstractions.
* Once the file is ~500 LOC or becomes too dense, start to refactor a bit. Perhaps introduce some loops or some global variables.
* At all times, ensure the script is idempotent - just highlighting the entire page and spamming run should "do what I want" without causing trouble.
* Once the script is started to take shape, it can be time to bring some OO into it - perhaps there is an object or set of objects I want to pass around, I can make a class for that. Perhaps I can start to think about how to make the functionality more "generalized" and accessible to others via a package.
This is literally the only way I've ever found to be productive with green field development. If my first LOC has the word "class" or "def" in it - I am absolutely going to ripping my hair out 12 hours later, guaranteed.
Maybe it depends on your perspective, or maybe it is simply personal preference, but I find rust pleasant and quick to prototype in.
I fail to understand what point you tried to make. There are already plenty of Make implementations for Windows. If you think that installing a third party tool like Task is ok, I don't see how doing the same with a Make implementation would exclude it as a valid alternative.
Oh and if you care about "deep level details" then i can still say fyrox has better internals. I know people who have given bevy many more chances than me and each time ran into a brick wall when writing an actual game.
It's completely expected that it doesn't click for everyone, but I don't get why you are framing it as if hitting a brick wall is the only experience that people have when making games with bevy. Plenty of people just don't like the ECS model. That doesn't mean that bevy is bad. It's just not for them. We are lucky enough that there's a great alternative in the rust gamedev ecosystem like Fyrox for those people. It doesn't have to be a competition.