[SCRIPT] Splitting cycles - best scripting habits.

[Cranky Old Man]

Hi, I'm a perfectionist, and I've got two pretty complex questions about which way is the most optimal way to script, in terms of clock cycles and instructions gained or wasted.

A lot of parameters are internal names, which are often wasted.
When it comes to Addtimer() functions, you can have every AddTimer() call the same function, and then divide this function according to the internal names. This will obviously spare the engine from keeping track of several functions, so the code becomes neater.
However, you can also have every type of callback call the same callback function, and then divide them according to asEntity, asParent, and so on. Whether or not this is wasteful of clockcycles, depend on how had it is for the engine to rig up an entirely new function, compared to making an additional if case statement.
Which method is the most perfect?


Another thing is that there are lots of callbacks that can be defined through the level editor itself (under the Entity tab of the entities) instead of at OnStart(). Which method is the fastest and neatest in this case?

[Damascus]

Regarding your second question, I always put my callbacks in the script as I have a tendency to lose track of/delete/recreate items in the level editor and it's nice to have the script stay constant unless you really want to go in and edit it.

I guess I'm not sure about the first. I mostly only group related timers and callbacks, such as grouping timers all based around spaced out player reactions to a scare, or callbacks related to the messages displayed when interacting with doors.

[Your Computer]

Like other scripting languages, AngelScript parses scripts into bytecode before doing any further work with the code. This, obviously, makes things run a lot faster than, say, constantly searching through the source code for the required definitions. This allows programmers to spend less time improving their code and more time writing code. But if you're really worried about efficiency, then you should do research on DRY (don't repeat yourself) and KISS (keep it simple, silly).

[Cranky Old Man]

Like other scripting languages, AngelScript parses scripts into bytecode before doing any further work with the code. This, obviously, makes things run a lot faster than, say, constantly searching through the source code for the required definitions. This allows programmers to spend less time improving their code and more time writing code. But if you're really worried about efficiency, then you should do research on DRY (don't repeat yourself) and KISS (keep it simple, silly).

Yes, well, say we have an object like a key. If I use an interact callback (with SetEntityPlayerInteractCallback()) and every object already comes with empty CallbackFunc properties, then I would be going against DRY by creating a whole new function without using the one already there.
I've decided to go with interact callbacks, and tie them all together into a single function later, but if this method is somehow deprecated in HPL3 because it wasn't how the developers figured it would be, then I'd have a hard time converting to the next engine.

[Your Computer]

Yes, well, say we have an object like a key. If I use an interact callback (with SetEntityPlayerInteractCallback()) and every object already comes with empty CallbackFunc properties, then I would be going against DRY by creating a whole new function without using the one already there.
I've decided to go with interact callbacks, and tie them all together into a single function later, but if this method is somehow deprecated in HPL3 because it wasn't how the developers figured it would be, then I'd have a hard time converting to the next engine.

In the background the game would simply be calling the same functions available to scripts for the CallbackFunc property. I personally recommend doing it all through scripts (for practical reasons), but there's technically little to no difference between how you setup an interaction callback. Nevertheless, the principles i stated apply more for when you're designing something from the ground up. In Amnesia scripting, you're pretty much starting from the middle. However, this is not to say that what one can learn by the DRY and KISS principles can't be applied to Amnesia scripting (e.g. one of the very purposes of functions is to not repeat yourself).