Timing, Triggers and Pong

A small update on the latest developments, building on the concepts of the separate time queues. The work on them is almost done, and now scripts can chain actions in a mostly seamless way, as shown by the sliding gargoyle in the picture.

Solo pong, a pastime for wizards

Solo pong, a pastime for wizards

This also helps me illustrate the addition of Triggers. Each component on the grid, now, can double as a trigger with various widths and heights.

When objects move, collisions are checked. In case of a collision with part of the scenery, the object stops or slides along a path (according to its pathfinding). In case two objects collide, the default action is fired (in general it means that a basic attack is performed, in this example the attack also pushes the target object). Finally, in case of a collision with a trigger, the “OnEnter” script is executed.

In this case, the ice sheet Entity is owner of a “Grid Object” component with the following trigger:

var movement = Mechanics.GetMovement(Target);
Mechanics.Push(Target, movement[0], movement[1]);

In the script we first wait for a quarter of a second (to be sure that the object doesn’t just move to where he was pushed into), then we get the direction of the “Target” (Target is a global script variable that is update before a script is executed, to be easily accessed, another one is Actor, another still is Player, all of them are entity IDs) and finally we push the target one more step in the same direction (Mechanics.Push is similar to Mechanics.Move, but it does not update the facing of the sprite and it will damage an object pushed against other solid entities, like walls).

Notice that I spoke about component ownership. In this case the ice sheet has a Grid Object component, but it also has a 2D Object component (the sprite). By using an ECS architecture together with our Block Generation Algorithm, it is really easy to manage pure triggers, like end-of-level stairs, or triggers for special events like boss cut-scenes, even in the context of a game with an heavy focus on procedural generation.

To close, a fun fact: the sliding thing happened accidentally when I forgot to comment out some code in a test procedure. Per chance I happened to move around a gargoyle in the fire level like a boulder in one of the sokoban levels of Nethack. Maybe I should evaluate some light puzzle elements making use of the pushing dynamic… any thoughts?

Thanks for reading.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s