a) Allows native use of the library through C++ and
b) allows for the creation of DLLs that can be used to add extra functionality to the script.
I've decided that to do either of these and maintain a useful engine I will need to move the engine from being pointer based, to being handle based. This change will actually be fairly easy; the major change will mean that instead of the scripted objects holding onto pointers for the native counterparts, they will now hold onto handles that need to be dereferenced to get the pointers they refer to. This will obviously introduce a speed hit, as we need to actually deference the handles into pointers, then check the pointers are not null but I think it will be worth it. For one, it'll mean that I can kill a native object and rest assured that the handle will refer to a null pointer. This will force people to allocate and deallocate objects through the API and will ensure that scripted objects only point to a valid object.
Now, the idea for the DLL interface is pretty simple. Writers of a DLL will have access to any engine function that's available in the native API. I would also like to think of a way of allowing runtime access to other loaded DLLs, but that will have to be thought of and will almost certainly not be in the first release. DLLs will be allowed to create new user types in the scripting engine and provide new API functions. Again, I will have to think of a nice 'wrapped' way to do this, but I could do it by simply allowing people to access the gmMachine pointer that holds the entire GameMonkey script environment.
The use of DLLs will allow for cool things to happen, such as perhaps allowing people to write graphics effects plugins, or physics plugins, or maybe even 3d plugins. Provided the interface is consistent enough, it could allow huge upgrades to the engine to be released simply through releasing a new DLL to the user. I like this idea quite a lot [smile]. Obviously, it's a big thing and will most likely not be in version 1.
I've been working on the tutorials some more. It's actually been a great tool for further development on the engine. By writing some simple tutorials you instantly see the gaps in the API you'd just written. For example, I was writing the texture tutorial and noticed that I was always assigning my texture handles to a name in an associative container. Why not provide the option for this in the API itself? So now if you pass in a text name when loading a texture, it's handle will automatically be assigned to the named entry in a "Textures" global table. I'll be doing the same for entities and other objects too as it makes for a very quick and clean interface.
I'll also be adding in the concept of an 'Action' to the engine. This is very much like a trigger, except the action occurs each frame until told to stop. A trigger is currently "An action that occurs when a test is passed". An action will simply be a function executed each frame until the action is disabled or removed. Like triggers, actions can be disabled/enabled, set to repeatable (for n fires or indefinitely). One addition I'd like to add into both triggers and actions is the ability to 'sleep' the trigger for 'n ms or n frames'. This would allow you to easily set off traps and then set a delay until they're reactivated. Internally, this mechanism would be as simple as firing an action, disabling the action and then setting a timed-trigger test to reenable the action. Usage in script would be something like:
global trap_test = function()
if (Entities["player"].position == vertex(50, 50))
global trap_fire = function()
evt = evt_create( "on_damaged" );
evt.props["target"] = Entities["player"];
evt.props["damage"] = 50;
// tell the trigger to sleep for 60 secs
.sleep_secs( 60 );
global main = function()
trg = trg_create( trap_test, trap_fire );
trg.repeatable = 1;
What would happen here is that the trigger would fire once and cause 50pts damage when the player hits (50,50) and then sleep for 60 secs. In this time, the player can move around 50,50 all they want and not be hurt, but when it renables again they will get damaged.
Anyway, I'm back to work...