Again an amazing video, thanks! Wanted to pinpoint also as well as responsiveness for mobile devices, maybe it would be great to have a minimap (?). Just food for thought just in case you do an extra section at the end, there are also only few videos about doing minimaps with threejs and none with a game like this
Thank for this, Dan! I'm a somewhat experienced dev, on paper at least, but I have much to learn from your pragmatic, positive, and structured approach to an explorative, greenfield project like this. I'll echo one of the other comments and say your channel numbers could easily've been 10x as high. Not that it matters all too much, it's still a gem to those who do find the videos. Much looking forward to the next videos. Cheers from Scandinavia
Good question. I discussed this in the original recording but cut it out because it was way too confusing and poorly worded. I was questioning whether the Player should really maintain its own references to both the camera and the terrain. Passing them in the constructor and creating class variables to store the references is sloppy because if we ever need to recreate the camera or terrain, the Player is going to be hanging on to the old references and will need to be updated. I usually ask myself “Does it make sense for this class know about this other class?” and if my intuition tells me no, that probably means I architected things incorrectly. For now I’m not too concerned about these things; I’m focused on getting a minimal working example of the game. Later on when the game is more fleshed out I can refactor the messy bits of code into separate classes.
@@dangreenheck Great point. Is the camera part of the player? No. Is the player part of the camera? No. But it has a target that can point to it, but not necessary at a player and not necessarily in its constructor. Then the view/screen needs a reference to a camera to render (that way you can have multiple cameras). If the player needs to interact with the world would that logic be inside the player or be in a player agent that is part of the world and says what a player can and cannot do? Or would just making a scene container and putting all instances in there and having that being the only circular reference so a player can ask the scene container for a world reference so it doesn't hang on to anything other than the scene it's inserted in? I mean, the object calling it's "onEnterFrame" callback / main loop would be the one to be referenced... then everything is a node and you have a node hierarchy and any node has a reference to scene, parent and optionally a target. I miss Macromedia Flash™
Again an amazing video, thanks! Wanted to pinpoint also as well as responsiveness for mobile devices, maybe it would be great to have a minimap (?). Just food for thought just in case you do an extra section at the end, there are also only few videos about doing minimaps with threejs and none with a game like this
Si creo que sería muy importante, colocarle un control para 📱 ya que todo mundo lo usa hoy en día... Algo así como coastal Word
holy crap only 4.5k subs?????? I thought this was a channel with more than a million
Spread the word! 😁
Thank for this, Dan! I'm a somewhat experienced dev, on paper at least, but I have much to learn from your pragmatic, positive, and structured approach to an explorative, greenfield project like this.
I'll echo one of the other comments and say your channel numbers could easily've been 10x as high. Not that it matters all too much, it's still a gem to those who do find the videos.
Much looking forward to the next videos. Cheers from Scandinavia
Thank you for your kind comment! This made my day!
Ваши видео просто находка, спасибо вам за ваш проделанный труд.
Thank you!
good job man 🎉 I've just love this series
good luck once i tried to create rpgs with three js but scale of project become too big, hope u will get as far as u can!
The best
At around 20:32 you say "There's nothin' like writing sloppy code" Can you explain why that code is sloppy?
Good question. I discussed this in the original recording but cut it out because it was way too confusing and poorly worded.
I was questioning whether the Player should really maintain its own references to both the camera and the terrain. Passing them in the constructor and creating class variables to store the references is sloppy because if we ever need to recreate the camera or terrain, the Player is going to be hanging on to the old references and will need to be updated.
I usually ask myself “Does it make sense for this class know about this other class?” and if my intuition tells me no, that probably means I architected things incorrectly.
For now I’m not too concerned about these things; I’m focused on getting a minimal working example of the game. Later on when the game is more fleshed out I can refactor the messy bits of code into separate classes.
@@dangreenheck Great point. Is the camera part of the player? No. Is the player part of the camera? No. But it has a target that can point to it, but not necessary at a player and not necessarily in its constructor. Then the view/screen needs a reference to a camera to render (that way you can have multiple cameras).
If the player needs to interact with the world would that logic be inside the player or be in a player agent that is part of the world and says what a player can and cannot do? Or would just making a scene container and putting all instances in there and having that being the only circular reference so a player can ask the scene container for a world reference so it doesn't hang on to anything other than the scene it's inserted in? I mean, the object calling it's "onEnterFrame" callback / main loop would be the one to be referenced... then everything is a node and you have a node hierarchy and any node has a reference to scene, parent and optionally a target.
I miss Macromedia Flash™