I love that you're tackling rewriting this. I also like how you're rewriting it. It was something that kinda bugged me about the code before, but it was more like "I wouldn't do it that way" than anything else. I think it's great that you're picking this back up and showing/teaching how and why to rewrite code.
I loved the first videos going step by step through the design decisions as you make them. Here it just feels like you're telling us afterwards. It's like seeing an open source library that's well written. It's great but really difficult to learn how they came to that from a mature repo. Honestly a new series starting over with this design in the same step-by-step style would be very popular imo.
Since this was my first UA-cam series, I learned a lot of lessons. It's very difficult to make videos on a project that isn't planned out to completion, because a lot of the code gets rewritten along the way and makes it difficult to follow. A lot more planning was put into the Minecraft series to avoid that issue. But I do get your point about seeing the design decisions along the way and how that would be valuable and interesting. I will keep that in mind if I do another series like this! Thanks for the feedback!
@@dangreenheck yeah but to me there are a thousand youtube series about some well planned project that gets sped through. What I liked about this one is the pace, and these design changes are super interesting but I don't get how you came to them or what drove those decisions. That said, I don't know what works for the algorithm, so just my pov, but you do what you think is best
I might try one "live coding" style video where I complete a small project from start to finish and talk through my process, do debugging in real-time, etc. and see how that is received. Once again, appreciate the honest feedback!
Seems like you're getting close to a reactive component metaphor like Vue or React use with your code and view logic being close together. While I know reactivity is less common in games, you might want to look into Vue or Solid's reactivity libraries (just the reactivity, no web-specific stuff). This can let you, say, make a Window component that is nested inside a Building component several times, allowing you to turn on lights in the windows (for a night cycle) via props on the building. And to avoid prop drilling so that everything just knows about the day/night cycle, you could use a provider/inject pattern so that anything that should be reactive to day/night can just inject it. This was more an exercise of me saying this idea out loud than any expectation that you'd use that approach, but I'm curious what people think.
Hey, this project is going along great, started following around episode 6 and this is going really well, and I have a few questions 1. what code editor are you using? (I'm assuming its VSCode but still want to know) 2. how do you get that smooth scrolling and cursor movement 3. how do you have that blurry background for your IDE (if it is VSCode)
Thanks! 1. Yes, it is VSCode 2. Go into the Settings and search for 'smooth'. You'll see a few options for controlling the caret and scrolling. I also have "Cursor Blinking" set to "smooth" and Cursor Style set to "block". 3. I use an extension called "Vibrancy Continued". VSCode will complain about the installation being corrupt but it works just fine.
Interesting that you are going back to a former project with the experience you acquired while building it (although, the full rewrite is not always advisable for business projects). Since you'll be leaning on harder in the OOP way, have you given a thought on implementing the good ol' MVC pattern? Because there's a chance our data-visual classes might need to pull a big pile of dependencies...
I agree, rewriting is usually not the way to go :) I didn't expect this project to get the interest it did, so in hindsight I would have spent a bit more time planning it out. The pattern I initially had could be considered MVC at a high level, where the City class was the model, the SceneManager class handled the view, and the Game class acted as a controller and handles the user interaction. I moved away from this approach because the separation created unnecessary complexity for what I was trying to achieve. In real-world projects, I tend to focus less on using a particular architecture (unless it is dictated by the framework) and focus more on design by composition and creating testable code. If you want to discuss more, happy to continue the conversation in the Discord! (link in vid description)
@@dangreenheck You definetely have the experience from building this project the first time to back your new approach, although I'm not so sure you'll end up with much less complexity. I guess I'll wait and see how it turns out. I wish you the best on this second try. :)
@@dangreenheck Great video. I'm curious about this current design pattern. Is it model-view-presenter? It seems like the choice is a lot better than the previous one for the project you're working on. Keep up the great work!!!
Do you have experience writing three .js with react? It seems to me that React greatly overloads the user's device, even with a small amount of 3D code.
Have you ever had to rewrite a large portion of a project you worked on? How did it go?
I love that you're tackling rewriting this. I also like how you're rewriting it. It was something that kinda bugged me about the code before, but it was more like "I wouldn't do it that way" than anything else. I think it's great that you're picking this back up and showing/teaching how and why to rewrite code.
Awesome video. Looking forward to your progress!
I appreciate this video! Well done, looking forward to more
Thanks!
You rock man! Thank you so much!
I loved the first videos going step by step through the design decisions as you make them. Here it just feels like you're telling us afterwards. It's like seeing an open source library that's well written. It's great but really difficult to learn how they came to that from a mature repo.
Honestly a new series starting over with this design in the same step-by-step style would be very popular imo.
Since this was my first UA-cam series, I learned a lot of lessons. It's very difficult to make videos on a project that isn't planned out to completion, because a lot of the code gets rewritten along the way and makes it difficult to follow. A lot more planning was put into the Minecraft series to avoid that issue. But I do get your point about seeing the design decisions along the way and how that would be valuable and interesting. I will keep that in mind if I do another series like this! Thanks for the feedback!
@@dangreenheck yeah but to me there are a thousand youtube series about some well planned project that gets sped through. What I liked about this one is the pace, and these design changes are super interesting but I don't get how you came to them or what drove those decisions.
That said, I don't know what works for the algorithm, so just my pov, but you do what you think is best
I might try one "live coding" style video where I complete a small project from start to finish and talk through my process, do debugging in real-time, etc. and see how that is received. Once again, appreciate the honest feedback!
Seems like you're getting close to a reactive component metaphor like Vue or React use with your code and view logic being close together. While I know reactivity is less common in games, you might want to look into Vue or Solid's reactivity libraries (just the reactivity, no web-specific stuff). This can let you, say, make a Window component that is nested inside a Building component several times, allowing you to turn on lights in the windows (for a night cycle) via props on the building. And to avoid prop drilling so that everything just knows about the day/night cycle, you could use a provider/inject pattern so that anything that should be reactive to day/night can just inject it.
This was more an exercise of me saying this idea out loud than any expectation that you'd use that approach, but I'm curious what people think.
Don't you think that if you write similar code in React, this game will blow up the user's device?
Just finished hacking your code for left hand side driving. Very good project.
Hey, this project is going along great, started following around episode 6 and this is going really well, and I have a few questions
1. what code editor are you using? (I'm assuming its VSCode but still want to know)
2. how do you get that smooth scrolling and cursor movement
3. how do you have that blurry background for your IDE (if it is VSCode)
Thanks!
1. Yes, it is VSCode
2. Go into the Settings and search for 'smooth'. You'll see a few options for controlling the caret and scrolling. I also have "Cursor Blinking" set to "smooth" and Cursor Style set to "block".
3. I use an extension called "Vibrancy Continued". VSCode will complain about the installation being corrupt but it works just fine.
Interesting that you are going back to a former project with the experience you acquired while building it (although, the full rewrite is not always advisable for business projects). Since you'll be leaning on harder in the OOP way, have you given a thought on implementing the good ol' MVC pattern? Because there's a chance our data-visual classes might need to pull a big pile of dependencies...
I agree, rewriting is usually not the way to go :) I didn't expect this project to get the interest it did, so in hindsight I would have spent a bit more time planning it out.
The pattern I initially had could be considered MVC at a high level, where the City class was the model, the SceneManager class handled the view, and the Game class acted as a controller and handles the user interaction. I moved away from this approach because the separation created unnecessary complexity for what I was trying to achieve.
In real-world projects, I tend to focus less on using a particular architecture (unless it is dictated by the framework) and focus more on design by composition and creating testable code.
If you want to discuss more, happy to continue the conversation in the Discord! (link in vid description)
@@dangreenheck You definetely have the experience from building this project the first time to back your new approach, although I'm not so sure you'll end up with much less complexity. I guess I'll wait and see how it turns out. I wish you the best on this second try. :)
@@dangreenheck Great video. I'm curious about this current design pattern. Is it model-view-presenter? It seems like the choice is a lot better than the previous one for the project you're working on. Keep up the great work!!!
Do you have experience writing three .js with react? It seems to me that React greatly overloads the user's device, even with a small amount of 3D code.
It shouldn’t. There’s no overhead with react-three-fiber over Three.js.
Do you plan to upload Minecraft part 6?
Yes I will be finishing out the remaining parts (6-9). Part 6 should be released beginning of February.