• entries
    437
  • comments
    1000
  • views
    335615

More scripting

Sign in to follow this  
evolutional

76 views

So my entities are all nicely scripted. Each one has the ability to define an event callback - so to assign a 'think' event function:-


global ent_think_fly_forward = function( a_event )
{
.move_pos( vertex( 0, 1) );
};

global ent_setup()
{
ent = ent_create( 0, 0, vertex( 250, 0 ) );

// assign a 'think' event function
ent.events["on_think"] = ent_think_fly_forward;
};


Running that little script will produce a motion in an entity that moves it forward one step each game frame tick.

Entities now have a properties dictionary, allowing you to customise it in your own way.


ent.props["health"] = 100;
ent.props["speed"] = 2;


This allows you to create functions to build specialist entities:


global ent_enemy_type_id = 1;

global ent_create_enemy = function( a_position )
{
ent = ent_create( ent_enemy_type_id, 0, a_position );
ent.props["health"] = 100;
ent.props["shield"] = 50;
ent.props["speed"] = 20;

ent.events["on_think"] = ent_think_fly_forward;

return ent;
};

global setup_ents = function()
{
ent = ent_create_enemy( vertex(250,0) );
};



And there we have it! Work is now centring on setting up the user-triggers trip events within the game. Events are pretty cool in script as you can have a single event object and assign properties to it like in the entities. So a positional trigger that fires an event to damage an entity would look like:


global trg_positional_test = function()
{
ent = .props["entity"];
pos = .props["position"];
return ent.test_collision_point( pos );
};

global trg_positional_test_action = function()
{
evt = evt_create( "on_damaged" );
evt.target = .props["entity"];
evt.params["damage"] = 20;
evt_fire( evt );
};

global setup = function()
{
trg = trg_create( trg_positional_test, trg_positional_test_action );
trg.props["entity"] = gm_get_player_entity();
trg.props["position"] = vertex(300, 400);
trg.activate();
}


Now when the player collides with the specified point he receives an "on_damaged" event (which he should handle)...


global ent_on_damaged = function( a_event )
{
.props["health"] -= a_event.params["damage"];
};


And there you go... The entity receives damage from the event. Naturally, the engine will provide you with some triggers (such as the entity-position-collide, entity-area-collide, timer triggers, etc).

What do you think?
Sign in to follow this  


2 Comments


Recommended Comments

I like it...

It's been a while since I read your GM articles (have they made it to the front-page yet?) but can you have C-style #include statements?

Maybe I've not quite understood it correctly - but it seems theres quite a bit of typing for a relatively common/simple thing?

Scripts are awesome, but some way of getting "to the point" and being able to script the interesting parts without all the extra setup fluff would be useful [smile]

Being able to #include that boiler plate code could solve that.

Keep up the good work!

Cheers,
Jack

Share this comment


Link to comment
Quote:
Being able to #include that boiler plate code could solve that.


Agreed. GM Script doesn't have a preprocessor, so #include is out completely. However, the engine I'm building does include a "dofile" style function ( it's called scr_load_script() ) which will load in and process a script when it's called. Bear in mind it's not like '#include', but if used correctly it can emulate some of the functionality.

The engine itself looks at several main entry points in script. The first is the function "engine_init" which is called when the engine starts up and the first script is loaded. This will let you set configuration stuff such as "fullscreen" and screen size. The next is "game_init", which is called when the game module itself is setup. After game init, the engine will then open a scripted thread which called a scripted function "main". This is ticked on each game frame; when this loop terminates the game will shut down. Typically, you'd throw your additional scripts to be loaded into your game_init function...

Like I said before, most of the common triggers you see will be exported from C, so that 'positional' trigger will not need to be coded in script. It was provided as a simple example only...

What I would like to do now is hook it up to TinyXML, SQLite and a file interface so that entities are serialisable to some extent; this way I should be able to provide a way to load in entity data from an XML file, a database or a flat binary file. Right now, entities have a type_id; I'm going to hook up a 'entity class' system that acts as a factory to build these different types. That should take out a lot of the heavy work in setting stuff up.

I'll be tackling GUI stuff soon which I believe you'll be interested in, Jack ;)

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now