This blog has lain silent for a while. I’ve been busy with real life, because real life must take precedence when you have work and children to consider. The main reason, though, was that I just couldn’t decide on how to finish the tutorial. The bar for learning graphics programming seemed just too high (because of course, I’d resolved not to resort to AMOS, which would have made it trivial). No book I read on the subject seemed to truly have what I needed, or to fit my setup, or be low-level enough for what I had in mind.
So there I sat, wondering why I couldn’t make headway. I felt stupid. I questioned if I was even smart enough to begin to understand the subject, let alone write about it authoritatively.
Eventually, I realized that the problem wasn’t intelligence or understanding, but that the underlying logic behind my tutorials was lacking. So I decided to change my approach. My original format was that of the typical tutorial: “this is what you want to do, here’s how you set things up, these are the steps you must take, and you’re done.” When written well, that gives you a good solution for achieving the goal at hand.
On reflection, I wanted something different. The standard tutorial is sequential. I don’t really want that: what I really want to do is to describe a creative process, and that process (at least for me) is not sequential but iterative.
Enter the incremental tutorial. Each tutorial consists of a number of self-contained posts. For each post, we add or modify one piece of functionality, while producing a valid product that does something. That means that each tutorial will have few steps, be of manageable simplicity, and that there will always be a checkpoint close at hand to retreat to, should anything go wrong.
I think this is a promising concept. It remains to be seen whether it's enough to take it all the way.
No comments:
Post a Comment