Many people do not like to "reverse engineer" others' work as a pre-requisite for learning. When you use this approach in your "Crash Course", these people are left wondering about many elementary points. And, opening up the "Behaviors" that have been made for you, trying to see how these work - is intimidating to many users - and does not illustrate the order of steps that were required to make all the parts work together. (Stencyl requires a linear workflow, for many things to work at all).
Using this kind of "reverse engineering" approach really ignores many of the "Why's" which are "timeless", as you have noted.
Many users want a more "step-by-step" approach that takes them from the ground upward:
1) How do I put an Actor into a Scene - to see it's animations?
2) What is the most basic way to move an actor with controls?
3) What is the most direct way to make the camera follow an Actor?
4) Do I always have to use a "tiled" background for platform games?
5) How many pixels, square, should my Actor be?
6) How do I know when to use an "Event" instead of a "Behavior"?
7) Does an Actor need to be a "Player" to be assigned keyboard controls?
I made changes to my game, but they don't show up when I "Test" it - Why?.
And the list could go on and on.
Using very simple examples of making objects do simple things is far less intimidating - ultimately more inviting - than leading someone through a game made by somebody else. This is how the "Why's" can begin to sink in, fostering an overall understanding of how Stencyl does things.
Psmith
