For quite a while I have pursued the dream of complete scriptability of all parts of my "game engine". I have come up with viable solutions, but they seem slightly inelegant. I was wondering if anyone has a more elegant interface solution. I developed a scripting language with an interface as explained in the FuBi article which allows direct calling of functions, both native and script. I have a problem however with deriving from objects where it is not known beforehand what elements will be scripted. The native code used to be heavily object oriented, but I experimented with dissalowing virtuals. This allows me to create custom vtables and be able to derive anything from any class, (allow native or script code anywhere). This however makes everything quite ugly on the native side, even though it fulfills the goal of pure scriptability. Now I am considering a more removed interface which allows me to preserve my object oriented internal structure (like the interface in java or lua). But this means I must explicitely differentiate script hooks from native code hooks, and I don''t like this. I am considering making an interface style which allows explicit exporting of groups of hooks to the scripting language, but this means an interface will be either all script or all native, or an ineficient hybrid. Does anyone have an elegant solution where all the code can be more unified?

Well, the first person that came to mind to glint information from is Scott Bilas - but I see you've already read his FuBi article.

The Right Thing To Do is add additional support to FuBi to support virtual calls. A generalized functor (grep Loki) could help with that, as it turns every type of C++ invocation into a executable entity with first-class value semantics. It's hard to convey what that really means, if you don't grok the naunces of language 'citizenship'. The lack of first-class functions has long been a deficiency of C++, that interpretted OO & functional languages possessed (e.g. smalltalk & ML).
Alternatively, a virtual call is just a vtbl dereference and then a normal function call. It shouldn't be too hard to pack that into FuBi (I know, always easier said than done). You would need an additional FuBi table of virtual function names (use the mangled names) to virtual function offsets, which you would use on the vtbl of the passed object, then invoke the method in the vtbl by the normal Fubi means. Use the already in-place FuBi cookies to remote the object.

Almost undoubtly Scott has added this functionality to DS, though he may have run out of time. Odds are good a new article for Gems3 will cover this

P.S. The game Scott's been working on was released a few weeks ago, Dungeon Siege - cool game, I'm still learning how skrit'ing (DS scripting language) works (which is where he put FuBi to work).

[edited by - Magmai Kai Holmlor on May 2, 2002 1:20:04 AM]

It''s actually a run-time linking process... dynamic binding may never be the same.