Hi Olivia! Thanks for letting me play along with this tutorial. It's looking really great. There are so few practical and yet beginner friendly ECS/project tutorials out there. I think this is really going to help a lot of people get started. Really great job.
This PR includes mostly trailing white space removals (my IDE removes trailing white space on save) and a couple of fixes to typos I noticed.
I also recommend using tree for printing directory listings. I think there was actually a typo in one of the listings that made it seem like main.rs belonged in/was being moved to resources. The --dirsfirst option is nice for sorting the output like an IDE would.
I added one note where code would run but with warnings that'd get fixed up later, and I expanded a couple code blocks to reference new use statements that were needed to make the code run, or to include nearby/related changes to an impl.
Two other general thoughts:
Maybe consider using Prettier on the markdown files? It applies some conventions in order to hopefully avoid quibbling about syntax/formatting (I don't think I'm alone in having my IDE format on save).
Maybe name the code folders after the chapter to which they're related (e.g. chapter 2, section 4's code is in code/rust-sokoban-07 … why not code/rust-sokoban-02-04)? This'd make for easy mapping from chapter to example in the case that I've cloned the repo and am running the book locally and mapping to the examples (getting the example's "index" from the #include blocks is fine, but I think it'd be cool to "just see" the relationship).
These two are more preference, formatting, repo organization, and not really related to the content itself … which I'll reiterate, is great!
I think I saw someone else ask for an expanded explainer on lifetimes, and I'd second that … it seems like maybe digging into why impl<'a> System<'a> for RenderingSystem<'a> { needs that third lifetime ref, but impl<'a> System<'a> for InputSystem { doesn't would be an interesting way of approaching that super confusing subject?
Other things that would be cool to learn about:
Performance? Input seems laggy to me, but maybe it's just because I'm running the debug build?
More complex graphics stuff?
Procgen'd maps?
Resolution independence, scaling, centering, etc?
Sound!
Okay, I think that's it from me … thanks again, and great work, can't wait to see what's next!
@mysterycommand thank you so much for your thorough review and for your awesome feedback and this PR! PR looks amazing 🚀
tree for printing directories is amazing, looks so much better and will definitely be more consistent with how it looks in the IDE, great idea!
prettier for md formatting sounds great, I'll create an issue to track, I agree we should try to automate as much as possible all this kind of stuff, it will allow people to contribute easier and less hiccups or nitpicks in PRs
folder naming is a good idea, I think it would help if it matched the sections. the only downside I can see is that if sections move around they will need renaming, but I don't think that would happen too often. also writing this I am thinking it might be a good idea to always have the link to the code at the top and bottom of each section for easy navigation.
lifetimes - this is a big one, I need to find a natural way to slide this in which I haven't yet, any ideas are much appreciated! maybe I'll start by dropping a link in one of the existing sections like: see this weird 'a stuff, read a bit about lifetimes here, and then later have a more thorough explanation
performance - yeah I think the lag is a bug, either in my code or ggez
more complex graphics - did you have anything specific in mind? I am planning a chapter about different coloured boxes, not sure if that fits the bill? or are you referring to having nicer assets? these were done quite fast tbh and more towards dev art 😂
procgen maps - YES! this is something I was thinking about as well, I think it would be really nice.
resolution independence - I think this is definitely a problem that people (and I) have/had, I am not sure what the state of the art approach for this is, do you have any ideas from what you've seen before?
sounds - YES! also on my mental list, I think it would also be really fun 😄
Hi Olivia! Thanks for letting me play along with this tutorial. It's looking really great. There are so few practical and yet beginner friendly ECS/project tutorials out there. I think this is really going to help a lot of people get started. Really great job.
This PR includes mostly trailing white space removals (my IDE removes trailing white space on save) and a couple of fixes to typos I noticed.
I also recommend using
tree
for printing directory listings. I think there was actually a typo in one of the listings that made it seem likemain.rs
belonged in/was being moved toresources
. The--dirsfirst
option is nice for sorting the output like an IDE would.I added one note where code would run but with warnings that'd get fixed up later, and I expanded a couple code blocks to reference new
use
statements that were needed to make the code run, or to include nearby/related changes to animpl
.Two other general thoughts:
Maybe consider using Prettier on the markdown files? It applies some conventions in order to hopefully avoid quibbling about syntax/formatting (I don't think I'm alone in having my IDE format on save).
Maybe name the code folders after the chapter to which they're related (e.g. chapter 2, section 4's code is in
code/rust-sokoban-07
… why notcode/rust-sokoban-02-04
)? This'd make for easy mapping from chapter to example in the case that I've cloned the repo and am running the book locally and mapping to the examples (getting the example's "index" from the#include
blocks is fine, but I think it'd be cool to "just see" the relationship).These two are more preference, formatting, repo organization, and not really related to the content itself … which I'll reiterate, is great!
I think I saw someone else ask for an expanded explainer on lifetimes, and I'd second that … it seems like maybe digging into why
impl<'a> System<'a> for RenderingSystem<'a> {
needs that third lifetime ref, butimpl<'a> System<'a> for InputSystem {
doesn't would be an interesting way of approaching that super confusing subject?Other things that would be cool to learn about:
Okay, I think that's it from me … thanks again, and great work, can't wait to see what's next!