Triggers

In my isometric tile engine I use 2 types of triggers. The first I call "tile_kind" and it works in a big CASE..OF statement based on the tile ID I assign to a tile graphic. For example water tiles that a player cannot cross get assigned in the map editor like so...

CONST WATER_TILE:=0;

tile[0,0].id := WATER_TILE;

...then in my game loop I can go like this

CASE tile[x,y].id OF
WATER_TILE: begin { do stuff } end;
LAND_TILE: begin { do stuff } end;
end; // case

The second type is what I call a "trigger" type. It''s a bit more indepth because I wrote a little scripting system that parses a pascal-like script jammed into a 1024 character string. It can do simple stuff like this...

tile[0,0].trigger.command:=''OK|WELCOME TO THE GAME %PLAYER%.'';
tile[0,0].trigger.style:=ONE_TIME;
tile[0,0].trigger.enabled:=true;

The script system reads the command "OK" and displays an ingame dialog box with the text "WELCOME TO THE GAME PETER." A simple string replace of the %PLAYER% in the command string at run-time allows for some basic flexability to show in game variables.

It''s not great, but it was pretty easy to program...



[ turbo | turbo.gamedev.net ]

quote:

---

Original post by turbo

The second type is what I call a "trigger" type. It's a bit more indepth because I wrote a little scripting system that parses a pascal-like script jammed into a 1024 character string. It can do simple stuff like this...

tile[0,0].trigger.command:='OK|WELCOME TO THE GAME %PLAYER%.';
tile[0,0].trigger.style:=ONE_TIME;
tile[0,0].trigger.enabled:=true;

---

My first thought when I saw this was that it implies that every tile in your map has these three member variables (command, style and enabled). With command having at least 8 bytes (if it is a standard Delphi long string), style possibly being an integer (4 bytes) and enabled being a boolean, this would use up memory in no time flat.

A more efficient and flexible solution would be to have triggers in a separate list and have each tile point to a trigger in the list if required. Then the code above would become something similar to

{ Set up trigger }
trigger[0].command := 'OK|WELCOME TO THE GAME %PLAYER%.';
trigger[0].style := ONE_TIME;
trigger[0].enabled := True;
{ Set index of trigger in the map tile }
tile[0,0].trigger := 0;
 

This also allows a single trigger to be assigned to multiple tiles. If you want to get even trickier, put the script into its own list.

{ Set up the script }
script[0].command := 'OK|WELCOME TO THE GAME %PLAYER%.';
{ Set up trigger }
trigger[0].script := 0;
trigger[0].style := ONE_TIME;
trigger[0].enabled := True;
{ Set index of trigger in the map tile }
tile[0,0].trigger := 0;
 

There may be a few levels in indirection here, but it does allow for re-use of triggers and scripts without using any more memory. Maybe this is more advanced than you want in a simple trigger system. But keep it in mind for future projects.

Steve 'Sly' Williams
Tools Developer
Krome Studios

Edited by - sly on August 24, 2000 1:45:48 AM

My own trigger system uses allmoust the same way as yours Sly.
But it would be even better if the script would be loaded from simple text file. Hardcoding it isn''t very flexible. Any other ideas?

Is there any good script languages for game scripts which would be easy to add to Delphi code?

Pexi

Of course the hard-coded string was only for example. Real-world games would always load them from external files.

If you wanted to roll your own scripting language, there are conversions of lex and yacc available for Pascal. Jedi Knight used a C-like scripting language created with lex and yacc. You can read about how they did it on Gamasutra. As for ready-made scripting, there are a few options out there. I remember seeing a news item or two on flipcode for free scripting languages. Take a look there and see what you can find.

---

Steve 'Sly' Williams
Tools Developer
Krome Studios

quote:

---

My first thought when I saw this was that it implies that every tile in your map has these three member variables (command, style and enabled). With command having at least 8 bytes (if it is a standard Delphi long string), style possibly being an integer (4 bytes) and enabled being a boolean, this would use up memory in no time flat.

---

This is correct, but the system I used it in had a very small map size, so it was fine. For large maps you could do a "DXTriggerList" as a hash list next to the map structure.




[ turbo | turbo.gamedev.net ]