Solomon - I don't mind at all!
1.) Behaviors...
I use javascript to create behaviors. If I do something, like math, or really any set of isolated events I often create a small behavior that does the same thing. It helps keep my event sheet clean and tidy. The downside is that creating a behavior takes alot longer than creating events because you have to connect it all up so you have conditions, actions, etc. If you want the behavior to save its state then there is all that work too.
Here is a case example: In my game I have a boomerang. The math that controls the boomerang is the same every tick (if a boomerang exists) so instead of using events to control it I created a small behavior that has 2 actions: "SetTarget", and "Update". If you hard code the constants, writing the bahvior is quick and easy, but if you think you will need it again for other things its best to expose those constants as variable parameters exposed to construct. In general, if I spend an hour prototyping an event based behavior, I can get it set up as a behavior in 10-20 minutes depending.
If the behavior is more of a object relationship behavior, things get a little more difficult, but in the sdk you can have two behaviors talk to each other... The problem is that they become dependent and only work if you have both behaviors. Typically I don't let behaviors do anything without me telling them to do so via an action. I even have split out the everytick auto update that occurs in platformer and created an action "Update". In this way I can control when an object gets updated, if at all.
Events that are purely math or similar are most like you said, "an external function". I would do this for things like quadratic lerp, Threshold translations, and other things. If a function made via events does not refer to specific objects, I most definitely add it to a custom plugin that houses all my functions for a particular game. This ties in a bit with what I mentioned about event functions which I'll get to in a moment.
I hope this all makes sense!
2.) functions.
I keep my event functions to a minimum for a few reasons, though in the past I used hundreds of dynamic functions. I would have functions calling functions and objects updating by calling a function name that was stored in a variable. There is neat stuff you can do around that kind of orginization but there are some problems with that in construct.
Firstly, there is an overhead performance hit to every condition and action you do. If you make an event sheet to do the same thing a behavior does, the behavior will run much much faster. For some games this is irrelevant, but for others it can be important. If you create a nested loop in construct that doesn't do anything (100 x 100) it will make a noticeable hit on your performance. (basically thats 10000 conditions, or however you want to think about it). If you do the same thing in a javascript behavior you will hardly notice it running (assuming its doing nothing as well). The result of the putting that in a behavior is that the event sheet only does 1 thing and thats call the "update" action on the behavior, then the behavior does the rest at a much better performance. The event sheet is great, but it is also incorporates a super powerful object picking system that has its costs.
Function within construct make that system do more work. The time it take to call a function is 5 times what it takes to perform a simple variable = x action or condition. If you function has many actions then it is probably worth it... but if you call a function to only do 1 or 2 things and then that calls another function to do a few things and then this function needs a parameter passed to it with an object uid and then you have to pick that object again... This can all add up if you are doing this 1000 times a tick.
Functions are only for the benefit of the programmer. A computer is so fast that it makes sense to use them. But in the case of construct 2 you are using a virtual function system that is built ontop of javascript. The performance loss here is not trivial if you have many objects. There is a forum post that I started a month or so ago where ashley talks about this. In most cases you needn't worry about using functions, but in my case, and in my particular game, I was using functions like I would be if I were writing in c++ creating a very object oriented dynamic event system. This was okay until I wanted 100 baddies on screen at once. My performance bottleneck was function calling. Even in c++ there is a performance hit for using functions, its just much more trivial. But when you use a function in construct you are basically emulating a function. Its a very high level language, so to speak, built on a high language.
This is true for any export platform. For my game, I basically stripped out the functions and put them in behaviors. It allowed me to up my object count and still stay within a performance goal.
....
I'm going to go ahaead and post this and then answer the rest of your questions in another post. 1 sec