The Power Of Scripts

Scripts in GM are under–appreciated by the vast majority of the GM community. They're treated as somewhere to stick little routines you may use more than once, but that's about it.

However I believe they offer much, much more. In fact, when used properly (or what I consider properly) they are a very powerful way of making your project more maintainable.

I don't think scripts are just for bits of repeated code, but I believe they can replace most actions altogether. The object / event model of GM is very powerful, but the actions that can be performed are limited, and if you use too many an object can soon become unwieldy.

So what am I proposing? Well, the easiest way to explain this is by example I think, so let's use one. As an example I'll use something that will exist in pretty much every GM game – a player object.

Predictably, I've called my player object obj_player.

In the create event, I'll call a script scr_player_create
In the step event, I'll call a script scr_player_step
For collision events I might have a few eg. scr_player_collide_enemy, scr_player_collide_bullet.

In my scripts folder, I'll create a folder called player and put all the scripts in there.

Okay. From now on I will vary rarely have to deal with the player object again. I might want to stick a few more events in (a destroy event, probably some more collision events), but that'll be about it.

Straight away this gives me one advantage. 99% of the things I'll ever want to do to the player object are in the player folder of the scripts section. Working on multiple scripts at the same time is easy enough so straight away there's an ease of use improvement over using actions – particularly the dreaded ‘execute a piece of code' action.

The code should be proceduralised further. This is something I've seen very little evidence of in GM WIPs and examples.

For example, my player script might simply be calls to scripts to handle specific elements.

Eg:

scr_player_step

// Process player input (key presses, joystick, mouse, whatever)
scr_player_input();

// Player movement
scr_player_movement();

// Player graphics (set facing direction, or leg animation etc..)
scr_player_graphics();

 

Of course, all of these scripts go in my 'player' folder. This gives me the further advantage that individual elements of my player object can easily be tracked down. If I have a bug in the graphics, the code is there in one routine – not buried amongst other stuff.

Sure, you'll have a lot of scripts. But with proper organisation this won't be a problem – this is what folders are used for.

There will also be general scripts that every object can/will use. This will go in folders with more general names, like 'Drawing', 'SpecialEffects', 'Scoring'. So typically in my Drawing folder I'll have a routine called scr_draw_blend_add which any object that is drawn blended would call from its draw event. In my SpecialEffects folder I'll have a routine called scr_generate_debris which accepts arguments like how many sprites, which sprites – again, any object can call this.

Again, you'll have a lot of scripts. But don't let this put you off. I've seen loads of examples and WIPs with the player step having an 'execute a piece of script' with about 500 lines of code in it. Sure it's all in one place and attached to the object which in some ways is nice. But in terms of maintining it, it can be a nightmare scrolling through pages of stuff to find what you want, and finding you're 5 IFs deep and worrying that a little change might break something else.

Another advantage is that whenever you want to change anything, you'll have the full power of GM available. You'll never have to go into edit an event full of actions, realise that what you want to do isn't possible with D&D alone, and re–write the whole event in script anyway.

What you will also find is by actively looking to proceduralise everything, over time you will become a more efficient coder. You'll see places where 4 very similar pieces of code can in fact be one function with a parameter. Most WIPs and examples I see have separate code for each of the 4 directions of movement – this is a waste of code, but something that extends to everything.

For example in R2S9 there are loads of different enemies. However, they all inherit a base enemy with some standard properties (in GM's case variables) so that I can use the same scripts for them all. It doesn't matter what type of player weapon hits an enemy, the same script scr_enemy_hit will be called. It doesn't matter which type of enemy the player collides with, scr_player_collide_enemy will take care of it.

I firmly believe this will make your development experience easier and quicker. It will also make you a better coder. This is a concept I've preached to a lot of people, and often they aren't interested. But those who take it on board agree that it makes their development a lot easier. Go on, try it for your next project – you'll be glad you did.


 
Google