A suggestion I have is to either split the making of a system (for example post processing) in multiple videos. Otherwise, you could start with 0 code, explain what you will do, what's going on in your head, how you've planned it out, and do somewhat half live-coding, half coding off camera. Skip the obvious/"chore" stuff and just do a brief explanation on them, etc. I personally don't like just looking at the difs, I'd much prefer to see your thoughts and your planning before you actually implement something, and kind of imagine how I would implement that, and then see how you do it, either step by step or even skipping a chunk of code ahead each time
In my case weekly code rundowns would actually be more useful, because the code structure, the concepts and so on are the problems in my private engine, not the implementation.
I'm completely fine with you showing only diffs and explaining what's going on, as you did it experimentally in one of primary episodes. (and if ppl just realize what a mammoth project it is , they'll be fine with that too)
Thanks for your brilliant series, it's helped me a lot in terms of learning good design principles for abstraction. Could you maybe try to keep your intros a bit shorter though? Your explanations are really good while you're coding and I feel that you could rather speak us through it as we code with a quick overview beforehand rather than long explanations that don't necessarily add much value. But anyways, take it or leave it, it's your series after all! I really appreciate your series!
I am personally fine with code diffs over live coding. I've been following along with this series on my own as I'm sure many others are doing. If you explain what the code does that is, I think, sufficient.
I would just record what you are doing while you are writing the code for an episode. Don't worry about pausing it when you have to get up and do something (like going to the bathroom, eating etc...). You don't even have to explain general concepts (like what data structure you are using or why you picked it, or how OpenGL works). People who would want to watch stuff like that, already know that stuff. Just so long as we get the general concept of what you are working on, it's fine. And don't worry if this pre-recording turns out to be 10 hours long. We don't care. Then take this pre-recording and post it to patreon. Then you can make a nice little summary video on youtube, and everything will be nice and clean on youtube. But people like me that want to see the actual code written, we can still get access to it, if we really want to.
Working with diffs is good, doing live coding is good or both. And something else. I have to say it. Those Hazel::Ref and Hazel::Scope are hitting a nerve. Why alias std::shared_ptr and std::unique_ptr and write wrapper constexprs for std::make_shared and std::make_unique? I know the STL guys are defining ugly API names with underscores and lowercase and with abbreviations, but still I think it's better to not alias those things. Also when I've read Hazel::Ref I had something else in mind, but a std::shared_ptr was not it. The series looks amazing and I'm learning a lot. also I like the concept of ImGUI!
I'm not a huge fan of Hazel::Ref and Hazel::Scope either (especially since those names do not suggest pointer types, and Hazel::Scope doesn't restrict the thing's lifetime to the scope (e.g. you could std::move it to a different scope)). Anyway, the reason for doing it is that if later down the track you decide that you want to use something other than std::shared_ptr / std::unique_ptr underneath, then the Hazel::Ref/Scope typedefs save you from a massive refactoring task. But then, why not apply the same argument to, say, the glm types - in case later down the track you decide you want to use a different math library? I'm guessing The Cherno thinks there is a reasonable chance that he will want to change the underlying pointer types, and zero chance he will want to change the math library.
I would love a live coding streaming. you could releasing a patch note every week to summarize all of the pull requests and that kind of small changes. and focus the game engine episodes for adding new features or anything major change another thing you could try is to split the game engine series into sub playlists so you can do your maintenance episodes in a different playlist than the one you are actually developing.
Just do live coding. Bisqwit hella does live coding like a boss. And he does it live on UA-cam. Yeah I keep getting the GitHub notifications on Gmail. Lol. Keep up the great work.
Discord isn't really a good solution for curating Hazel inspired projects... Nobody is going to read through the whole backlog of messages to find projects and if some of the projects get pinned then inevitably there will be some that don't.
you can always just write out the code for things you already covered in previous videos and simply address new aspects on a new video live.. just my opinion..
Since you are writing / coding the entire thing anyhow just live record and post the entire video to a second channel. Then as @Runaan stated give an overview of the weeks progress and implementation.
Sorry to be pushy, but could you please go through your Patreon messages and give me GitHub access to the dev branch? I signed up for the $25/mo tier and am much more interested in 3d than 2d.
I think you explain things excellently as you code. So talking as you coding and recording it works well and could save time too
A suggestion I have is to either split the making of a system (for example post processing) in multiple videos. Otherwise, you could start with 0 code, explain what you will do, what's going on in your head, how you've planned it out, and do somewhat half live-coding, half coding off camera. Skip the obvious/"chore" stuff and just do a brief explanation on them, etc. I personally don't like just looking at the difs, I'd much prefer to see your thoughts and your planning before you actually implement something, and kind of imagine how I would implement that, and then see how you do it, either step by step or even skipping a chunk of code ahead each time
Yah using the OpenGl series would be a good idea.
Bringing OpenGL series videos back would be great idea. Especially since GE series is gonna be at rendering chapter for quite a while.
thanks!
9:30
Cherno: doing his thing
Windows: Your device needs to restart outside work hours
In my case weekly code rundowns would actually be more useful, because the code structure, the concepts and so on are the problems in my private engine, not the implementation.
Where's BORK and Rapidfire though?
I'm completely fine with you showing only diffs and explaining what's going on, as you did it experimentally in one of primary episodes. (and if ppl just realize what a mammoth project it is , they'll be fine with that too)
Thanks for your brilliant series, it's helped me a lot in terms of learning good design principles for abstraction. Could you maybe try to keep your intros a bit shorter though? Your explanations are really good while you're coding and I feel that you could rather speak us through it as we code with a quick overview beforehand rather than long explanations that don't necessarily add much value. But anyways, take it or leave it, it's your series after all! I really appreciate your series!
I am personally fine with code diffs over live coding. I've been following along with this series on my own as I'm sure many others are doing. If you explain what the code does that is, I think, sufficient.
I saw that > 49 sandbox 2D
Nice to know that this is episode 49 on this series.
(to clarify, the intro is episode 0, come on common sense.)
I would just record what you are doing while you are writing the code for an episode. Don't worry about pausing it when you have to get up and do something (like going to the bathroom, eating etc...). You don't even have to explain general concepts (like what data structure you are using or why you picked it, or how OpenGL works). People who would want to watch stuff like that, already know that stuff. Just so long as we get the general concept of what you are working on, it's fine. And don't worry if this pre-recording turns out to be 10 hours long. We don't care.
Then take this pre-recording and post it to patreon. Then you can make a nice little summary video on youtube, and everything will be nice and clean on youtube. But people like me that want to see the actual code written, we can still get access to it, if we really want to.
Working with diffs is good, doing live coding is good or both.
And something else. I have to say it.
Those Hazel::Ref and Hazel::Scope are hitting a nerve. Why alias std::shared_ptr and std::unique_ptr and write wrapper constexprs for std::make_shared and std::make_unique?
I know the STL guys are defining ugly API names with underscores and lowercase and with abbreviations, but still I think it's better to not alias those things.
Also when I've read Hazel::Ref I had something else in mind, but a std::shared_ptr was not it.
The series looks amazing and I'm learning a lot. also I like the concept of ImGUI!
I'm not a huge fan of Hazel::Ref and Hazel::Scope either (especially since those names do not suggest pointer types, and Hazel::Scope doesn't restrict the thing's lifetime to the scope (e.g. you could std::move it to a different scope)).
Anyway, the reason for doing it is that if later down the track you decide that you want to use something other than std::shared_ptr / std::unique_ptr underneath, then the Hazel::Ref/Scope typedefs save you from a massive refactoring task.
But then, why not apply the same argument to, say, the glm types - in case later down the track you decide you want to use a different math library?
I'm guessing The Cherno thinks there is a reasonable chance that he will want to change the underlying pointer types, and zero chance he will want to change the math library.
Alright, I just watched Maker's muse 3D printing video and you both kinda look alike for some reason
Roses are red
Violets are blue
And the Cherno is...
The best teacher ever!!
Roses are red
Violets ain't blue
Your poem doesn't rhyme
lmao, yeet
@@stathisstathopoulos9007 aha I knooow xD I tried ok??!
I would love a live coding streaming.
you could releasing a patch note every week to summarize all of the pull requests and that kind of small changes.
and focus the game engine episodes for adding new features or anything major change
another thing you could try is to split the game engine series into sub playlists so you can do your maintenance episodes in a different playlist than the one you are actually developing.
are you on the rush? you forgot to take off your jacket. lol
Also, I don't know why you stopped putting the github link in your video descriptions, but I think you should start putting it there again.
Just do live coding. Bisqwit hella does live coding like a boss. And he does it live on UA-cam. Yeah I keep getting the GitHub notifications on Gmail. Lol. Keep up the great work.
Bisqwit doesn't do live coding. He only narrates a playback of him copying the contents of the program.
@@__jan I've seen him live. Lol.
@@omegawii oh you mean his livestreams. i thought you meant his videos
Discord isn't really a good solution for curating Hazel inspired projects... Nobody is going to read through the whole backlog of messages to find projects and if some of the projects get pinned then inevitably there will be some that don't.
you can always just write out the code for things you already covered in previous videos and simply address new aspects on a new video live.. just my opinion..
No views? That's a lie.
How about live streaming?
im actually doing a 2d engine, but not for gaming...
for your car or what
ArgZ 4 ur mom
Since you are writing / coding the entire thing anyhow just live record and post the entire video to a second channel. Then as @Runaan stated give an overview of the weeks progress and implementation.
49 Sandbox2D
Sorry to be pushy, but could you please go through your Patreon messages and give me GitHub access to the dev branch? I signed up for the $25/mo tier and am much more interested in 3d than 2d.