Well then, that’s the alpha over.

Now what will we talk about today?

Mainly the second enemy (again). And the importance of feedback. As, this week was all about tweaking the enemy, refining the code it used, and improving upon what we had.

 

The alpha testing that was conducted on the Monday (13/2-17) this week gave some excellent feedback. Having a good balance of both direct and mixed reviews on different aspects of the game.

In my case, I was mainly interested in the enemy logics, what needed improvement and what was working. That is not to say that I wasn’t interested in the rest of the feedback, but knowing that the enemy object wasn’t still perfected to a satisfying result, I felt a need to knowing how to improve it further.

The most outstanding of feedback regarding the enemy was about its actual purpose. Which was expected. The early version of the enemy moved, spawned an attack object, waited until the attack was over and then moved again.

But there was no indication of the actual object spawning the attack, it just sort of “appeared”.

Enter: Unity Line Renderer.

The Unity line renderer, for those who may not know: Is a tool available in unity that allows the user to create lines between two (2) or more points in space. This works in both 2D as well as in 3D as the tool uses the vector (that is vector2 or vector3) for its points.

However, being a programmer, I of course had to do all the work in code (Unity Inspector, what’s that?).

For anyone not interested in using the line renderer in code, I’d advice looking more into how the inspector works. I do however recommend anyone interested in the line renderer in general, to look up how to use it in actual code, as I found it way simpler and more customizable than the actual inspector tool.

 

Now for what I did this week:

As you might expect I did some work using the unity line renderer to show the enemy creating the attack object. That is to say, I made it look like it actually attacked.

But on top of that I also changed the actual behaviour and workings of the attack itself. This was something I brought up in my earlier post “The First post about the second enemy” where I described more in-depth the logics and workings of our enemy object.

In the post, I also described how the attack object was made up of two (2) parts. An actual attack object, and a sort of warning area. And how these objects where separate and controlled by the enemy object.

This has now changed. The enemy object only instantiates the attack object, which now goes through a short attack process.

 

The pseudo code of this process looks sort of like this:

When you’ve been instantiated, set your own parameters, the scale you should start in, and the scale you should end up in. Now instantiate the warning area object.

The warning area object then sets its parameters in a similar way to the actual attack object, and then starts scaling. After its scaled it calls back to the attack which now scales itself to size.

Once the attack has scaled to its desired scale it should then change colour to a darker tone, indicating to the player that it has now changed, and now does damage.

 

This logic is a lot better than the previous one because of the simple fact that the attack-object now holds every aspect of itself, and the warning, which it should do from the get go.

The reason why this is such a big deal is because the previous version would have the enemy-object hold the destruction of each object. Meaning once the enemy was destroyed the destruction calls for each object would be destroyed with it. Which is completely unnecessary if the attack-object held all that information instead. As it would know when everything in the attack should be destroyed regardless of their existing an enemy object that created it or not.

This was of course the plan all along, it was just done dumb during the stress of finishing everything for the alpha.

 

Next the line, oh the line, the beautiful line that show the enemy-object attacking the player. The line object is itself quite simple: you give it 2 or more points for it to draw a line between, a start with and an end with (if you want to). And a few parameters controlling its sorting order/layer.

And once the code goes through all of this, the line creates itself (if the component itself is enabled).

The challenge wasn’t so much creating a line, as it was animating it. Why? Because the line renderer in unit doesn’t draw a line from point A to point B over time, it is instead instantly created. How did we combat this? Some might argue that we could have our graphical artists draw an animation of the line and then use that. Well, we don’t have any graphical artists in our team. I won’t get into detail why, just know that we did, and now we don’t.

Either way, the challenge was now to animate this line moving from A to B over time. There are several ways to do this, all based on the same base concept:

Have a point in space move or increment towards the desired end destination and lock the line point on it.

Which Is what I did. Using some clever coding I created a small incrementing counter which moved the point from point A towards point B over a desired amount of time.

Creating 3 points: point A, Point B and PointAlongTheLine. I saved the origin point and destination point in points A and B, and then used “Math.Lerp(float a, float b, float t)” to solve for float x.

Math.Lerp as unity describes it: “Lineary Interpolates between a and b, by t”. I then took this calculation (named x). And multiplied it by Vector3.Normalize(Point B – Point A) + Point A. Which then became the Point “PointAlongTheLine”.

This would then set the direction of where the line should move, and continually iterated it forward towards that point per an internal counter/timer.

I then just set the end positon of the line on the moving point and constantly updated it. This made the line seemingly animate out from the enemy object, towards the attack position.

Then it was just a matter of having a check if the line had reached its destination and spawn the attack.

 

Post-Programming thoughts:

Only a single post programming though this time, and this one is incredibly important:

To anyone using or planning to use unity collaboration.

When you start the program, you have two (2) tabs, named: “On the Disk” and “In the Cloud”. For the love of everything, make sure you open and use the project under “In the Cloud”.

This weeks’ major screw up was brought to you by:

The fact that I did all my changes and fixes of the enemy object in a project with the same name saved under “On the Disk” not realising until once I was done that none, I repeat NONE of the work I had just done could be uploaded to the collaboration project.

And as you can imagine, even if the scripts share the same name, they’re not universal. Meaning you would have to either re-write everything, or somehow copy and paste everything from one script/file to the other.

I did the later, copying the scripts over to a word document and then pasting the text over the scripts in the cloud version. And fortunately for me, I only had to do this to three (3) scripts. But for your own mental health, make sure you’re in the right project from the start.

 

And that’s it for this time! Hope you’ve found this information interesting. Now get out there and good luck on your future game making!