1 reply to this topic

[snufkin]

Hello!

 

I'm currently writing my first proper 2D game (integrated in a custom built engine) using C++ and SDL. I have a question about how to script certain events though. The engine itself is state based.

 

My game state is made up like this:

class PlayState : State
{
private:
    Camera* camera;
    Player* player;
    Map* map;
}

In turn, the map is primarily a manager of tiles (Tile*** tiles; which get initiated in accordance with the map file).

 

Now to the problem! When I step on, let's say tile [25][100], I would like the game to change to a certain state (declared either in the map file or in some script). What's the best way to do this?

 

PlayState holds a pointer to the engine, and it would be possible for it to pass a ChangeStateEvent to it, but then I have clutter the map file with both info about what event to send and possibly a parameter to the same (i.e. ChangeStateEvent, Cutcene(cutscene nr 725)). Instead I was thinking about having some kind of script trigger every time I step onto a new tile and check if the tile is a trigger tile. If so, the script will handle everything necessary to view the cutscene.

 

So, what do you suggest? Is scripting the way to go, or am I completely off?

 

PS

I own all of the code myself (and the game art is all Creative Commons licensed), and wouldn't mind sharing it if necessary (it'll most likely cause a headache for the more advanced game devs though).

[Krohm]

PlayState holds a pointer to the engine, and it would be possible for it to pass a ChangeStateEvent to it, but then I have clutter the map file with both info about what event to send and possibly a parameter to the same (i.e. ChangeStateEvent, Cutcene(cutscene nr 725)). Instead I was thinking about having some kind of script trigger every time I step onto a new tile and check if the tile is a trigger tile. If so, the script will handle everything necessary to view the cutscene.

Both sure have advantages. Sure having a "clean" world representation appears nice, having a centralized "tile script" resource shared with the whole world might appear handy.

Historically however, the world was populated with "trigger" brushes. That has been the case for all ID Software engines (sometimes with hardcoded events). Unreal engine also does that. I do that as well.

 

The main property is that "trigger brushes" can be of arbitrary shapes. This comes very handy if you have (say) a tile with live exposed wires. We can then set up a trigger brush to hurt the player, but only if near a specific set of pixels.

If the tiles are 3D (such as in TES3: Morrowind, and probably in all TES games as well) then having a per-tile script is probably too gross-grained to be useful.

 

So, I'm afraid you'll have to "clutter the map" with those trigger brushes. It's not as bad as it sounds however. I use blender for my DCC. Blender allows up to 20 different layers to be toggled independently. So, put your world geometry on a layer and your trigger brushes on another.

 

Ok, so let's say we have this system now and consider the other part of the problem.

 

Is scripting good?

Sure it's not strictly necessary, as you already noted. You might just have a set of "hardcoded scripts" and only allow to call them. It's really ok and you would probably get quite some mileage out of that.

But, as the number of scripts gets higher, you will have to pour them out to scripts instead of code. Having, say, 725 cutscenes, hardcoded in engine would drive me insane for sure.