If I understand your situation correctly, there are 4 alternatives that you can use:
Option 1: Load a SkookumScript text file and have it parsed and run by the runtime. [Possible, though not recommended: low performance compiling text at runtime and our plan is to remove the text parser from the “Shipping”/“Release” build of the SkookumScript C++ library. We *could* always provide a separate library with the parser for people that need it. I strongly recommend always using compiled scripts - ideally ones managed by the SkookumScript IDE - otherwise any changes to classes/methods/etc. that these scripts depend on might not be noticed at compile time. You would only notice that something is broken when/if a script is loaded at runtime. This has been a *major* headache on other projects.]
Option 2: Just use different classes for the behavior that you want. It may seem like overkill to give different instances a completely different class when perhaps(?) there may only be one instance of each class - however this is pretty simple to write and it is very likely that the extra overhead for a class per object isn’t really a big deal in terms of memory or code management. [This is (almost) exactly what was done in the open world Sleeping Dogs and massively multiplayer Triad Wars - one class per mission. It worked great.]
Option 3: Use different classes per behavior - like Option 2 - and use demand loaded classes to load and unload whole classes or classes and their subclasses as needed. [This is what was used on Sleeping Dogs and Triad Wars to keep the memory overhead down. Note however - this feature is a paid add-on since most small games shouldn’t need it.]
Option 4: Use closures (essentially more sophisticated anonymous functions/delegates) to assign different behaviors at runtime. Create one class (or a few variants) that has the common behaviors that you want and have a few data members to store the different behaviors that you want as closures that can be set at object construction or any time during its lifespan. [Note that closures are new to SkookumScript version 3 and were not available to Sleeping Dogs or Triad Wars.]
Option 5 (requires C++ or yet to be implemented tech): It would be possible to compile arbitrary scripts as little binary snippets that would be fast to run. All the C++ API calls necessary to create such functionality are available though not in a handy ready-to-use form. We could add this as a future SkookumScript IDE + runtime feature.
If you don’t mind creating a bunch of classes - go with option 2 or 3.
If you want to have a single class (or at least a small number of classes) - go with option 4. This is probably the best option and the one that I recommend if I understand your goal and preferences correctly.
If you really want to run arbitrary scripts that have their own text files - I can give you some example code for option 1. I strongly recommend against it.
So again I recommend option 2. Closures are very cool though they don’t have much documentation yet (just like most of the features at the moment). Take a look at the closure doc entry and give it a try. Feel free to post here or on the closure forum post if you would like help or more examples.
If you want to go with a different option just let me know and I’ll give you any additional help that you need.
Let us know how it goes!