Categories
Ambience Dev Diary

Dev Diary #11: Stories, Speed, and Shaders

Hello everyone! It’s time for another week’s progress report! (Rather than just calling it another progress report, I’ve decided to give these posts the more interesting name of “Dev Diary” entries.)

Recently I’ve been making solid progress on Ambience. I don’t know if I mentioned this before, but these past few weeks I’ve been keeping a changelog documenting everything I’ve done each day. It’s actually been really surprising to see how much progress I have been making!

Most of the entries in the changelog (with a few exceptions, of course) tend to fall into three main categories:

1. Story-telling.

I’ve spent the last two days or so writing up the dialogue for a fairly important cutscene, which happens at around the two-thirds mark of the main storyline. The reason why it’s taken that long is because the dialogue (and in fact the entire subplot) depends on the player’s previous interactions with the other characters. I don’t want to spoil too much, but I think I got the atmosphere of the scene about right in the end – which is tricky to do when you’re juggling about fifty different possible text combinations.

2. Shaders.

Yes, I finally decided to return to the world of shaders for the first time in about a year. This time, instead of simply changing the hue of text, I applied a warping effect to the game’s application surface (the surface which stuff gets drawn on) to illustrate the player’s nauseous response to a disturbance in the Ambiences.

Now, I’m no expert in OpenGL, so again this process was kinda long – but once it worked, it worked well. What was most frustrating was actually getting the effect to work in both fullscreen and windowed modes without having the application surface drawn somewhere completely different on the screen.

3. Speed mechanics.

I recently implemented a new mechanic where Ambiences could affect the movement speed of the player, allies, and enemies. For example, when the player activates the Ambience of Wind, they can take two turns in the time that enemies can only take one – making this a neat way of escaping from groups of enemies when you’re in a pinch.

Debugging, however, has been a nightmare. To give you an idea of the sorts of strange results I had to fix, here’s a copy-and-pasted extract from my changelog:

  • Fixed a bug where Ambiences wouldn’t properly affect speed when used on the first turn
  • Fixed stuttery movement in dungeons where out-of-sight enemies had higher movement speed than the player
  • Fixed a bug where having an enemy with higher speed present would prevent ambush battles from being activated
  • Fixed a bug where opening and closing the menu would make enemies with higher speed take extra turns
  • Fixed a bug where enemies with higher speed wouldn’t use up thrown items properly, causing them to throw a single item multiple times…

You just can’t make these things up sometimes.

Gamedev can be a bit like building a house of cards – one tiny slip, whether intentional or not, could throw everything into disarray. I’ve found this is especially true when implementing new mechanics. Just when you’ve put a new mechanic in place and you think everything’s all right, suddenly you find yourself facing yet another strange bug – at which point you sigh, roll up your sleeves, and fix it.

And then you find another.

And another…

Leave a comment