Gamedev Grievances #26: Stuck in the Mud (Dynamic Terrain)

After receiving heaps of much-needed feedback on Ambience at the showcase the other week, I’ve been working hard on implementing those suggestions, including tweaking old mechanics and adding new ones.

One suggestion I really liked had to do with the dynamic terrain in Ambience. In the game, the player can use their weather-changing powers to change the surrounding terrain, such as by blowing away leaves or drying up lakes, which allows the player to explore new areas. For example, here’s our hero using the Ambience of Sun to dry up some rivers:

Begone, thou rivers!

While this was a nice start, this only gave the player a limited degree of interaction with the environment. One play-tester remarked that it would be better if the terrain could also be used as a combat mechanic – for example, using the Ambience of Rain to suck enemies deep into the marshy ground.

I thought this was a great idea… but how to implement it?

Inner Workings: Lots of Grids

Ambience has a grid-based motion system, which works by storing all the useful information – player and enemy positions, wall and water tiles, line of sight, and so on – into three, two-dimensional data structures which GameMaker: Studio calls DS Grids. You can think of the three grids as being laid on top of each other over the whole room, as shown in the picture below:

When an Ambience is activated and the water dries up, the water cells in the “room grid” are all changed to ordinary floor cells, which are accessible to the player. At least, that’s how it worked to begin with. While it was easy to just remove all the water tiles and forget about them, this didn’t allow the player to use those cells later on (say, to suck an enemy into the mud), and so my system was limited in its overall functionality.

Marsh Tiles

So I changed the plan. Instead of changing all the water tiles on the room grid to simple floor tiles, I designated them as “marsh tiles” instead. (In reality, I designated separate marsh tiles for corridors and rooms as well, which made things a little bit trickier! However, this was to preserve the line-of-sight algorithms I had developed previously.)

The result was the GIF at the top of this post, which I’ve also put just below. Notice that the marsh tiles appear where the water tiles once were – before the changes, these tiles simply disappeared completely.

Stuck In The Mud

Then came the exciting part – using the marsh tiles for combat purposes. (As strange as that may sound.)

Here’s the aim: When a particular Ambience is activated, any enemies standing on marsh tiles should be destroyed. Any enemies flying above the tiles (such as the Cave Bat in the above GIFs), however, should be unaffected.

To make this work, I took a few steps:

First, when an Ambience was activated, I “flagged” any non-floating enemies standing on marsh tiles to be attacked. This flag is usually the ID of the object doing the attacking, which is then used in damage calculations. However, in this case I set a dummy ID which would tell the game to one-hit KO the enemy instead of doing an ordinary damage calculation.

I then modified my turn-based script so that, after the player has finished activating their Ambience, the game checks for any enemies which have been flagged to be damaged. The script then goes ahead and inflicts that OHKO damage, similarly to if the player had attacked them.

I modified the resultant battle log entry, and also hid the damage call-out showing how much damage had been inflicted, just to hide everything that was going on behind the scenes.

Here’s the final product showing the Player using the Ambience of Rain to easily dispatch a Henchman:

Notice that while the Cave Bat is standing on a marsh tile, it doesn’t get sucked into the mud since it’s hovering over the ground. The Henchman, on the other hand, goes down without a hitch. Perfect!

The Learning Curve

Here’s a couple of things I took away from this.

Mechanics that are easy to implement aren’t always great in practice. In this case, simply removing all the water tiles was an easy task, and allowed for some rudimentary terrain-changing. But in terms of gameplay, it wasn’t quite as interesting or fun as being able to creatively use the terrain to resolve conflict situations.

Plan out your game’s operation well in advance. I developed Ambience‘s grid-based, turn-based dungeon system over a year ago, but it’s only now that I’m finally starting to reap the rewards. Having a well-planned, robust system that works well from the start makes adding or changing aspects of that system really easy later on. (In short, do your homework before making your games!)