” Give yourself to the rhythm” – Lucio, Overwatch.

Yes, this week will be all about rhythm, beat, and… attacking?

Why indeed, this week we’ll focus, again, on the enemy object, its attack and the importance of math in videogame making. It’s important to note that unlike previous weeks this week was quite packed with scheduled courses. Specially math from 9-16 (9AM – 4PM) which took quite a bit of worktime as well as mental capacity. And thus, the process was slowed down a bit this week.

 

Anyway, enough blaming it on something/someone else. Time to get into what was done this week: Rhythm and beat.

As time moved on and the project evolved we’ve decided to give the game a “pulse” having everything move, attack and pulsate to a rhythm. And this too goes for the enemy object and its attacking pattern. Now, I’ve already discussed how the enemy object works and what its attack pattern looks like, the only real change was making everything move with the rhythm.

But don’t think this was easy, oh no. Having never done anything like this, finding the proper way to make not one (1), not two (2) but three (3) separate objects move and follow a rhythm was not an easy task.

Now, luckily our other programmer Pål had already worked on a similar system for another title he’d made at a Game Jam, and the rhythm system was based upon this system. Which meant if you follow the golden rule of communicating with your teammates, discussing the problem allowed for more input and to some extent, some more experience and knowledge.

But how did we solve this?

Well the Pseudo code for the logic was:

Have an iterating counter which counts from zero (0). Divide the result of this counter with the beat (or whichever timeframe you want to use). The result is a percentage of how far into the timeframe the object has iterated.

Next, use this percentage with the “Mathf.Lerp(a, b, t)” function. For anyone who has read my previous posts, yes this is the same function as the one used to “animate” the line that the enemy used to show its attack. Then, you multiply the result of the previous function with a “vectorX.Normalize(B – A) + A”. Again, yes this is the same as the line animation.

The reason for this is because this specific line of mathematical functions and work means the object will get the percentage of a timeframe, linearly interpolate this percentage and then multiply it with a simple iteration calculation.

And lastly, take the result of multiplying the two (2) functions and apply it to whatever object/logic you want to manipulate (in this case it was scale but this also works with positions and movement).

The results speak for themselves, the calculation used resulted in the object transform to point with a 0.01f (0.01 float value) difference between the given timeframe and the time taken.

 

Now if you’re not a programmer, or if you have difficulties with math, this might seem intimidating and/or confusing. But don’t fret, I did too and it’s important that anyone who reads this and feel that their math skills might be lacking (I’m including this because in all honesty, I’ve been there myself so, you know just in case):

1. This explanation of how the mathematical formula works is really shit. But I don’t think I can explain it better without having to write a 5-page essay about it.

 

2. No one can know everything and do everything, if you feel like you’re lacking in some skill don’t worry about it, the more you work and the more passionate you are about what you’re doing the more you’ll grow and the more you’ll learn and evolve.

 

3. In all honesty… I’m still a bit unsure about how this all works myself so… you know, there’s that.

 

Post programming thoughts:

I’ve tried to make this part a staple in my blog-posts, allowing me to reflect over past mistakes, why they occurred and how they can be fixed. And hopefully allow you, the reader to get an insight and hopefully work to not repeat them. But this week I can’t say that there were a lot of problems.

Sure, the fact that we had long math sessions during half of these past days meant that there was a less than desirable time spent on the project. Which will probably have to be caught up to in the next days, or over the weekend. But other than that, the communication between teammates went well, the work thus far has been done without that much problem. And everything worked out in the end (?).

So, I guess that’s it for this post. Nothing else to report on really. I hope you found it, interesting.