The problem with delivering the pre-defined templates as "modules" is that makes the sprite less customizable and flexible. One of the goals of SGDK2 is to separate the features/framework into layers so that the user is free to customize the code at a level/layer they're comfortable with. In version 1.x, you only had 2 choices: use a pre-defined sprite type or script all of your sprite's behavior manually. SGDK2 creates a new layer of "Rules" that expose behaviors in a format that's (intended to be) simpler to use, but not as complex as coding, and more flexible but not as straightforward as simply selecting a template. And yet it keeps both other options open. You can still simply select a template, and you can still totally customize everything at the code level. If I were to convert all the templates into modules, it would defeat the purpose of having this intermediate layer where the user could perform relatively simple customizations to the sprites' behaviors because the rules would no longer be exposed. There are too many variables about a sprite's behavior (even those exposed in version 1.x); they just couldn't all be exposed by a single rule function without giving the user the opportunity to control them. In version 1.x you can control the gravity, inertia, input source and jump height (among other things). That alone represents too many parameters to pass to a rule function. To it seems to make sense to split it up a bit more as I have tried to do in 2.0 so that you have high-level functions controlling the sprites behavior at a level somewhere near the midpoint between manually coding everything and simply selecting a template. Ant the goal of limiting the number of parameters in a rule function to 3 is to help enforce the idea that these rule functions should be simple and easy to create. If there are more than 3 variables affecting a rule, the rule should be split into multiple rules to make more of it visible as separate components in the tree (or parameters tab) instead of having it all collapsed into a single tree node.
The reason I suggest having an option to convert a set of rules into a single function for non-template sprites is because you have the opportunity to customize those rules in the rule editor before converting them into a function. Also, the delivered templates are relatively short and don't need to be converted into functions. The number of rules on most of the templates is quite manageable. But I imagine that often times you can end up with some pretty complex sets of rules for sprites while incorporating or manipulating them for a specific project, unlike the templates which are just a simple framework for sprite behavior.
Does that make sense?
