Updates

About time for another update I guess. A few bits to talk about at the moment.

Firstly, I've just spent the last few hours changing the GUI system so that the GUI is rendered at a size relative to the resolution rather than the previous fixed size system. The fonts don't look too bad scaled, as long as linear filtering is on, and it leads better into the next point.

I want to start putting the tutorial levels together on the basis that I can't keep adding features to a test level - I need to start putting an actual game experience together and add features as I need them.

Part of the problem here is that I despise tutorials that pause the game while they show you some text so I wanted to be able to have instructions appear on screen during play. The previous fixed-size GUI system did not work well for this as at low resolutions there was a chance of occluding the play area with the dialog.

Now that the GUI is scaled, I can create a system for triggering text dialogs from the scripting system which can be triggered on and off by the existing area system - this will allow for putting tutorial levels together nicely.

Talking about the scripting system, I had a successful moment of inspiration. At the time the script services that are used to trigger things in the actual game were immediate and I was worrying about how I was going to trigger things in the script to happen later on.

Squishy Script has two sorts of code block - functions which take parameters and return values and procedures which take and return neither. The reason is that procedures can be used as entry points from outside of the script and a map is added to the level file between procedure names and virtual addresses of them in the VM.

The existing Event system in Squishy allows me, in the game itself, to schedule events to happen after a certain number of seconds. This is a system I've used for years now which I find a preferrable solution to state machines for lots of situations.

The Event system already had an event to invoke a procedure by name from the script, so I decided to just add another script service to schedule this event with the seconds delay and the procedure name as its parameters. It looks something like this in Squishy Script:

delay_call(string s,float delay){    register(0)=int(s);    register(1)=delay;    service(23);}procedure push_button{    delay_call("delayed_event",3.0);}procedure delayed_event{    stop_music();    begin_fade(2.5);}

push_button would be linked up in the editor using a script gate - a button would be given the script gate as its client and the script gate would be given the name of the push_button procedure. I'll probably post about this system in more detail at some point as it is working out really really well.

delay_call is just a wrapper around the service which communicates with the game engine. It basically calls a method of the ScriptListener and passes in the parameters and the method takes the appropriate action based on the service number.

Service 23 looks up the address of the named method (passed as the address of the string constant in the VM's memory in the int value of register 0) and the schedules an event to call this procedure, using the float value of register 1 as the delay.

This simplifies everything nicely as there is no need to worry now about scheduling events in the script. As long as there is an immediate service to perform whatever is required, it can be wrapped in a procedure and invoked via the delayed call service.

I'm tempted to write an article about the gate system that I've used in Squishy as it has proven to be a really robust and extensible system for integrating objects in the game with each other and the scripting system. I'm also planning an article about my dynamic texture atlasing system, both of which I will submit here and hopefully get better feedback than my last attempt [smile].