I love this project so much. It's awesome. I often modify the code or try different things and see what happens. Since I'm very curious, I also like to search more information on topics that are mentioned but not explored in detail (yet).
Casey is amazing. I hope I'll be able to be as helpful as he is, and pass on the love for computers and programming.
PS: Microsoft never ceases to amaze me. Look at the screenshot I made of this dialog from Windows 10 preview. It basically says: You can turn off the 'real-time protection' which slows down your computer to a halt when playing games, but it doesn't matter anyway, because we'll turn it on again, whether you like it or not." Not to mention the fact that the apostrophe doesn't render correctly in one of their own windows (it's a preview/beta, but still). :P
Casey is amazing. I hope I'll be able to be as helpful as he is, and pass on the love for computers and programming.
PS: Microsoft never ceases to amaze me. Look at the screenshot I made of this dialog from Windows 10 preview. It basically says: You can turn off the 'real-time protection' which slows down your computer to a halt when playing games, but it doesn't matter anyway, because we'll turn it on again, whether you like it or not." Not to mention the fact that the apostrophe doesn't render correctly in one of their own windows (it's a preview/beta, but still). :P
Edited by elle
on
In previous version you could add excluded files or folders which won't be scanned. I typically add my source checkout/work folder, so it doesn't slow down compilation/debugging speeds. Not sure if Win10 version has same option, but it could have it.
I am following along with the YouTube archives and coding everything myself along with Casey. I have been programming in Java (which forces OOP in a lot of ways) for 6 years. This has been an incredible resource on jump starting low level C programming.
I often pause the streams and try to implement things myself, and then compare them to what Casey does.
The hardest part of following the streams for me is usually when it comes to architectural changes. Casey does a great job of explaining technical things, but I think when he is doing a lot of major architecture stuff it's hard to fully understand where he is going with them until most of the changes are made.
One example of this is when he adds the simulation region code. I pretty much had to blindly copy what he was doing until it was close to done, and then I could see what he had in mind.
I often pause the streams and try to implement things myself, and then compare them to what Casey does.
The hardest part of following the streams for me is usually when it comes to architectural changes. Casey does a great job of explaining technical things, but I think when he is doing a lot of major architecture stuff it's hard to fully understand where he is going with them until most of the changes are made.
One example of this is when he adds the simulation region code. I pretty much had to blindly copy what he was doing until it was close to done, and then I could see what he had in mind.
Nephyst
One example of this is when he adds the simulation region code. I pretty much had to blindly copy what he was doing until it was close to done, and then I could see what he had in mind.
Just to elaborate on this, that's actually what architectural work is all about. You generally can't know where it's going ahead of time because it is too complicated. That is usually what "high minded" programming methodologies get wrong. The devil is very much in the details. So the best methods of architectural work tend to be in pushing towards a potential area you think is interesting, and seeing what happens. It is rarely about knowing exactly where it needs to go and then moving it there, if that makes sense.
So you really want to try to learn that driving process - how to think about things you might want to achieve and then push in some directions and see what gives. That kind of architectural driving is a very important part of the programming process for large-scale programming!
- Casey
The exploratory and compression style makes sense to me and the process of how you re-architecture the code makes sense to me. I can see how you take the pain points that come up and try to restructure the code base to try and remove them.
The architecture changes tend to start by breaking a lot of things, and then going through systematically rebuilding a new architecture on top of it.
The issue I am having I think is that you have a vision in your head on how the code is going to flow during that re-architecture process and I have a hard time seeing exactly what that vision is until most of the pieces are in place. It makes it a little difficult for me to understand how the functions fit into the bigger picture and exactly what each function is trying to accomplish.
To expand on the simulation region example: I was following along with the changes that added the BeginSim() and EndSim() calls, but I really didn't understand how they fit into the rest of the code base until you actually called them from UpdateAndRender. It made it difficult for me to understand the details of what the functions were supposed to be doing until I could go back and walk through the whole flow.
In these cases, I tend to just follow what you are doing until I am at a place where I can walk through the code and see the how the pieces all fit. It might just be one of those things where I need to spend a couple of years experimenting with this style.
So I guess I'd like to ask... At the point where you start the re-architecture process, do you have a pretty good idea of how the code is going to flow when that process is done? Or are you just sort of making most of it up as you go?
The architecture changes tend to start by breaking a lot of things, and then going through systematically rebuilding a new architecture on top of it.
The issue I am having I think is that you have a vision in your head on how the code is going to flow during that re-architecture process and I have a hard time seeing exactly what that vision is until most of the pieces are in place. It makes it a little difficult for me to understand how the functions fit into the bigger picture and exactly what each function is trying to accomplish.
To expand on the simulation region example: I was following along with the changes that added the BeginSim() and EndSim() calls, but I really didn't understand how they fit into the rest of the code base until you actually called them from UpdateAndRender. It made it difficult for me to understand the details of what the functions were supposed to be doing until I could go back and walk through the whole flow.
In these cases, I tend to just follow what you are doing until I am at a place where I can walk through the code and see the how the pieces all fit. It might just be one of those things where I need to spend a couple of years experimenting with this style.
So I guess I'd like to ask... At the point where you start the re-architecture process, do you have a pretty good idea of how the code is going to flow when that process is done? Or are you just sort of making most of it up as you go?
Nephyst
So I guess I'd like to ask... At the point where you start the re-architecture process, do you have a pretty good idea of how the code is going to flow when that process is done? Or are you just sort of making most of it up as you go?
Well, two things:
1) There isn't a discrete "re-architecture process". The code is always moving, and the goal is to keep it moving toward a good design rather than towards a bad design. What you are calling a "re-architecture process" is really just what happens when the move you want to make at a particular time happens to require a discontinuous change.
2) Sometimes I do and sometimes I don't have a specific vision for what I want things to do in the end. As you can see from the sim region part of the stream specifically, if I had known at the outset exactly how I wanted all that stuff to work, I wouldn't have had the tile map part and all that stuff first, I would have just written the sim region stuff. So it's very much an exploratory process.
- Casey
I agree. However, one constructive criticism I insist on the didactic side is that it seems to suffer from the Curse Of Knowledge which is related to the Dunning Kruger Effect.
Casey steps from one level of knowledge(beginner) to the other(guru) in a blink of an eye. I can understand that happening in the Q&A but not on the main content stream.
Casey steps from one level of knowledge(beginner) to the other(guru) in a blink of an eye. I can understand that happening in the Q&A but not on the main content stream.
Edited by Carlos Gabriel Hasbun Comandari
on
Expanding on gazto's comments, those interested in the topic should check out Steven Pinker's most recent book, "The Sense of Style", where he goes into great lengths discussing the Curse of Knowledge. His suggestions on how to mitigate it are very enlightening, and they will be applied to my book project.
In a related note, the Handmade Hero series will reasonably make some viewers bewildered. Consider this quote from the Handmade Hero front page:
And from the technobabble podcast, Casey discusses how the series wants to produce a body of work that explains the creation of a professional game from scratch, with all of the difficult subjects tackled and explained. It is not to teach beginner programmers to become experienced programmers (although the series can potentially allow ambitious beginners to do so).
The Intro to C Series was more of a quick review than anything else, and if you're following along from the start, it will seem like a big jump. However, it was never a jump to begin with.
Hopefully, my book aims to transition beginner programmers to a more experienced state.
In a related note, the Handmade Hero series will reasonably make some viewers bewildered. Consider this quote from the Handmade Hero front page:
Although 100% of the programming for the game is captured in the videos, each step is also accompanied by continuous explanation of what is going on and why. It is meant to serve as a de facto class on game programming.
And from the technobabble podcast, Casey discusses how the series wants to produce a body of work that explains the creation of a professional game from scratch, with all of the difficult subjects tackled and explained. It is not to teach beginner programmers to become experienced programmers (although the series can potentially allow ambitious beginners to do so).
The Intro to C Series was more of a quick review than anything else, and if you're following along from the start, it will seem like a big jump. However, it was never a jump to begin with.
Hopefully, my book aims to transition beginner programmers to a more experienced state.
I remember you mentioned Steven Pinker's "The Sense of Style" in the first part of your Text Editor in C. I am glad that more people(and yet few) are aware of cognitive biases, logical fallacies and immorality(wait, the latter one isn't applicable here.)
Being a good teacher is what makes it or breaks it for a student to continue pursuing a subject matter. We have all had that cranky math teacher that failed at explaining how the theory mapped to the practice in every day life.
Despite the flaws in Handmade Hero. It is still the best resource for aspiring game developers available on the Internet along Game Institute's courses.
I am looking forward to your book Abner, using Compression Oriented Programming AKA Data Oriented Programming. Only excellence can be expected from a guy that takes didactics seriously.
Being a good teacher is what makes it or breaks it for a student to continue pursuing a subject matter. We have all had that cranky math teacher that failed at explaining how the theory mapped to the practice in every day life.
Despite the flaws in Handmade Hero. It is still the best resource for aspiring game developers available on the Internet along Game Institute's courses.
I am looking forward to your book Abner, using Compression Oriented Programming AKA Data Oriented Programming. Only excellence can be expected from a guy that takes didactics seriously.
Edited by Carlos Gabriel Hasbun Comandari
on
gazto
Casey steps from one level of knowledge(beginner) to the other(guru) in a blink of an eye. I can understand that happening in the Q&A but not on the main content stream.
I think this may be due to a misunderstanding of how Handmade Hero is designed to work. It is not a stream that attempts to teach people game programming, like in a class in grade school. It is a stream that attempts to show people game programming, like they would have in an apprenticeship. So I am saying what I am doing so that you can observe it, but not only do I not expect people to understand everything by watching, I do not think it is possible for that to happen. Learning how to program a game professionally takes many years of practice, so Handmade Hero is meant to be your introduction to how it is done, but the onus is on the apprentice to practice, come back to the stream, practice again, come back to the stream, and ask questions in the Q&A's and on the forums to build up the real internalized knowledge that only comes from hard work.
So, I do not consider this to be anything like the "Curse of Knowledge" or DKE. I am well aware that it should not be possible to program like I do just from watching one stream. The point is so that you have seen it done, and heard a clear explanation of what happened, but only through your dedication to working at it yourself will you be able to internalize it.
- Casey
Handmade Hero really provides a resource that just doesn't exist anywhere else. There are hundreds of books and thousands of online guides that can deepen your understanding of programming (many of dubious quality), but none of those resources can compare to actually walking through the code of a seasoned game programmer, line by line as it's developed. Even college classes don't offer this kind of experience -- it's literally the kind of stuff you used to have to pick up "on the job".
Handmade Hero single-handedly rekindled my desire to become a programmer. In high school, I took programming class and was taught Java with an extreme focus on OOP. In college, the focus was still on Java and OOP and the curriculum actually pushed me so far away from programming I jumped ship and switched streams into networking/systems administration because it was so miserable. I figured every software project eventually devolved into the AbstractFactoryFactory nonsense that we were taught.
Eventually I found out about Handmade Hero through one of Casey's blog posts about The Witness, and I watched his Intro to C. Opening up the debugger and seeing values in memory as they were manipulated was where it really clicked for me. That kind of hands-on control over what was going on in the CPU was fascinating and I wanted that power. I wanted to understand everything that was going on behind every line of code instead of dealing with endless abstractions that just served to obfuscate.
I've been a fan of the series ever since.
Handmade Hero single-handedly rekindled my desire to become a programmer. In high school, I took programming class and was taught Java with an extreme focus on OOP. In college, the focus was still on Java and OOP and the curriculum actually pushed me so far away from programming I jumped ship and switched streams into networking/systems administration because it was so miserable. I figured every software project eventually devolved into the AbstractFactoryFactory nonsense that we were taught.
Eventually I found out about Handmade Hero through one of Casey's blog posts about The Witness, and I watched his Intro to C. Opening up the debugger and seeing values in memory as they were manipulated was where it really clicked for me. That kind of hands-on control over what was going on in the CPU was fascinating and I wanted that power. I wanted to understand everything that was going on behind every line of code instead of dealing with endless abstractions that just served to obfuscate.
I've been a fan of the series ever since.
It's so much worse than you would ever expect.
I worked for Amazon.com for 4.5 years, and that culture of early optimization, over-architecture, and factory factories is entirely engrained into the culture. I don't know how many times I've either had to deal with a factory-facotry that was only ever used to create a single object, or been forced to write one because the lead developer wouldn't give my code a ship-it without one. I can't count the number of hours I've spent writing getters and setters only to end up using the object as if it was a struct. I've never once changed a getter or setter to do anything more useful than get or set, yet its entirely required in modern day programming.
Every aspect about the job is around optimizing before writing the code. You go to meetings and discuss what data-structures your algorithms use when in reality you probably saved a couple of nano-seconds on not critical code that gets ran asynchronously a couple of times every hour, while your code took an extra week to write.
Coding in low-level C is so much more exciting. I feel like there's real problems to solve here, rather than setting a flag in a database because a user clicked on a button. It's sort of a breath of fresh air in a world that felt like it was clouded in smog. I only wish it would have happened 6 years ago. :]
I worked for Amazon.com for 4.5 years, and that culture of early optimization, over-architecture, and factory factories is entirely engrained into the culture. I don't know how many times I've either had to deal with a factory-facotry that was only ever used to create a single object, or been forced to write one because the lead developer wouldn't give my code a ship-it without one. I can't count the number of hours I've spent writing getters and setters only to end up using the object as if it was a struct. I've never once changed a getter or setter to do anything more useful than get or set, yet its entirely required in modern day programming.
Every aspect about the job is around optimizing before writing the code. You go to meetings and discuss what data-structures your algorithms use when in reality you probably saved a couple of nano-seconds on not critical code that gets ran asynchronously a couple of times every hour, while your code took an extra week to write.
Coding in low-level C is so much more exciting. I feel like there's real problems to solve here, rather than setting a flag in a database because a user clicked on a button. It's sort of a breath of fresh air in a world that felt like it was clouded in smog. I only wish it would have happened 6 years ago. :]
At some point, on Handmade Hero, we will have to make a factory object that makes a factory object that then makes, you know, like, a single integer or something :P
- Casey
- Casey