Hero equipment

In the previous post, I talked about having pirates who track the player. But the hero doesn't have any means to respond. So, as he is a thief, and not an assassin, I will give him non-lethal weapons: a wood stick, known as a "Bo" in martial arts, a bow with sleeping arrows, a slingshot, and a graple (at the moment at least). Those are quite classical, but offer different kinds of gameplay. I have a mile-long list of what additional features I could implement but you have to start somewhere ;)

I - Bo

The most basic weapon and surely one of the first you'll have in the game. I wanted to create various moves that can be chained in order to create combos. It brings visual variety and may add a bit of strategy to choose the best moves according to the surrounding enemies. For now, I have set up 3 different moves, that you can perform by clicking repeatedly on the left mouse button. Setting up the time frame tests to chain the combos was a bit difficult, because according to when the player hits the button it may be too late in the current animation to softly blend with the next combo move. So I implemented special curves on each animation ruling when a click triggers the next move and when it's too late. 

 The first simple move with a trail render

To add some "cool" effect while working on the Bo attacks, I added a trail render on this weapon. A trail is calculated by building a stripe mesh between the successive positions of the weapon. But the problem is, if the weapon is too fast, there are not enough points to make a cool smooth trail. So I had to use a clever interpolation trail script nicely provided by the Unity community. This effect is quite nice, but I didn't want it on every frame (for example when the player is walking, that's unnecessary)! So here again I added some custom curves to the animation to trigger the trail effect only during the hitting phase.

Talking about the hitting phase, this was really harsh to implement because even if Unity provides collision detection, a few issues have to be addressed:

• what happens if an enemy collides with a weapon that is not performing a hit move?
• what happens when the move is so quick that the weapon goes through an enemy without actually touching him in any frame?
• what happens if a weapon touches an enemy twice (or more) in a move?

So I  used custom curves again for effective hit timing, and I set up quite a large collider for weapons, which is actually the case in a lot of games: I watched videos of Zelda and Beyond Good and Evil (my usual references) stopping them on nearly every frame to analyze the range of the weapons, the look of visual effects and the timing of animations. They are absolutely not realistic, not even precise, but they are very fun: for example, have you ever noticed that in most games a hitting move is actually slower than the move to get back to its start position? I hadn't until I had to code it, which is quite strange because in reality you expect the hitting move to be the fastest of all...

I also added a unique id to every hit move to easily check if the hit has already been taken by an enemy or not. This is more useful than a simple "invincible state" for a few seconds after a hit because in combos, 2 successive hits can be very close to each other. 

Mega Attack! A 360° quick turn with a longer range.

Then I added some kind of "mega attack", which is also classical in video games: press a button for a few seconds and release it. I added a different trail effect, and changed the impact force. But I had a big problem with the circular animation I wanted to set up for this special move: the hero performs a 360° move while hitting, but the rotation interpolation made him turn in the wrong way at the end of the anim because it was using Euler angle interpolation and not Quaternion (yes, math stuff). So I had to recreate it again, and I didn't get it perfeclty right yet, but the move is so fast that it's really hard to see the flaw while playing.

Another problem (yes there are tons of them!) is the holding of the weapon: it's in the back when you don't use it, this is quite common. But when you start a hitting move, does the player first grab the weapon then hit requiring two click from the player (just like in Zelda?) or does it perform both moves at once? And once the attack is performed does he keep the weapon in the hand? Do I use a button to put it back on the back? Is is automatic? 

At first I thought I could use the same weapon-grabbing system as for the pirates, but this might be a mistake, because, for the player, what I want above all is reactivity and simplicity in controls. That's not a problem if the enemy performs a weapon grab move quite slowly before hitting (that's even actually very useful , because the player understands that the enemy is going to attack him), but for the player this goes against reactivity. When you hit a button to perform an attack, you want it to be fast (sometimes you are in urgent situations!). So I chose to perform both the weapon grabbing and the attack in the same move. Then, I set up an automatic detection of alerted enemies nearby and recent attack activity to automatically put back the weapon on the back when everything is quiet again. And as I could continuously check this "fight mode", I added some kind of guard/defense position while fighting.

 Guard position. It works also with the Bo in the hand.

I also noticed that aiming precisely with the Bo during a fight was quite difficult, so I added some automatic detection of the nearest enemy in the direction of the move. This simplified a lot the game, but makes it quite fun I think.

To conclude on this part, I will just talk about a tricky bug I spent a lot of time on: what happens when you click so fast that it passes between all triggers? To debug this, you have to click in less than 0.01 s, and be able to pause the game just after! So I set up a few indicators that should be framerate independent to carefully detect very fast input change. These bugs occuring on just one frame are really hard to catch. It's already physically hard to make them occur... But those "frame perfect hits" are used a lot by professional gamers to hack/"speed run" games. You can find impressive videos of those abuses on the net. And there are a lot of games out there whose behaviour is somehow undefined if the player performs incredibly fast and complex inputs. And I bet I still have loads of bugs like this...

II - Arrows

OK, next weapon! Yes, the long first part was only for the Bo! Bow and arrows seem quite simple to implement... But as usual they aren't. The more I have to code and create "simple" things, the more I understand they are never that simple. And it can be so tempting by looking at the work of other people to think that what they do is simple, but I think you can't tell if you haven't tried. 

Sooo... the first problem is : first-person view (aim as if you were looking with the eyes of the character) or third-person view (aim from the back camera)? The first-person view is more immersive but breaks the perception of the game and is more difficult to use in a fight. The third-person view doesn't break the game perception, but it's quite complex to code because what you see/aim from the camera is not necessarily shootable from the character... even without talking about gravity. We can find both styles in video games, but I have a preference for the 3rd person view, and I actually would like to have a fight system enabling combos between range and melee weapons, so I want a reactive arrow aiming (and thus, nothing disruptive with a camera change).

But even with those considerations, questions are still there: I have to set up a sight icon, but when the player shoots, will the arrow reach the exact point the sight aims at (which requires complex calculations anticipating gravity and all obstacles on the path)? Or is it mostly some kind of helper towards which the player always shoots in the same way, and then gravity does its job? I chose something in between as usual: within the range of the bow, the sight icon represents exactly the spot where the character will shoot because within the range, arrows go straight without gravity being applied. Beyond this range, gravity is applied, and precision of the shoot is not guaranted: the sight icon becomes red. But you can shoot anyway and see what you get.

 You can shoot here.

 But you can't reach this far away arch. Or at least, not precisely. And yes, you may recognise the old bridge level from my very first demo. I still use those levels as tests.

Another thing was: can the player shoot while running or moving? I thought the answer was no... Because you can rotate the camera with the mouse (to aim) and move the player with the arrow keys, enabling him to aim at a specific point while going in the opposite direction. This requires complex animation blending (running and aiming at the same time) that I don't have the time to set up at the moment. Maybe later... because I found out this burdens the fight game experience.

On a more artistic side, I had to create the bow and arrows and carefully place them in the hand of the character. A quite annoying problem I was faced with was: is the bow visible when we don't use it (like the Bo in the back)? If I choose to make eveything visible is the back (or somewhere else), this may visually clutter the character, plus I need moves to get every weapon. And there are a bunch of games out there whose characters take out weapons/items from nowhere, and that's OK. So at the moment, the code enables to hang weapons everywhere on the character, but I think I won't use it for every weapon.

III - Flingshot/stones and graple

Functionnally, Stones are quite the same thing than arrows (so the problems were already solved!), except they don't send the pirate to sleep, but catch their attention by making noise. Of course, I had to model the flingshot and stones and adapt them to the aiming position.

A well-aimed shot with the slingstone and every enemy will come to the hit point. OK, here I aim very badly...

Concerning the graple, it enables to quickly jump onto a wall, even if it's not normally reachable by climbing. I always thought this was very cool in the Zelda series. This will be used to get to unreachable areas in the game. It still uses the same targeting system, but I had to make more checks to ensure the target was actually climbable, but this test was already (more or less) coded in the climbing algorithm. At the moment there is no visual item for the graple, it seems more like some kind of magic teleportation. This will be fixed later.

IV - Various stuff

I also added a simple item/weapon selection menu. At the moment, you can only change the secondary item (right click). The primary item (left click) is always the Bo.

A very simple weapon selection menu (well inspired from World of Ninjas... :p)

And with all these weapons, another raising problem is the priority between them: what happens if the player starts clicking left, them hold it for 0.5s and then adds a right click on top of that, releasing first the right click, then the left one? Which weapon is prioritary? Some of the weapons react to pressing down a button (simple Bo attack, bow aiming), others on releasing it (bow shooting, mega Bo attack). Some need to be "charged" by pressing the button for 1s (mega Bo attack), others don't (graple). How to combine all this while maintaining a consistent state within the player? And what happens if, in top of that, the player calls the weapon selection menu which preempts every click? What if this is the main menu? What if both at the same time while pressing both mouse buttons? Which events are preempted and which still go through? This was a huge mess to sort out.

Aside from these annoying technical problems, I also worked on little things here and there: I started to code the swimming ability, I added 3 climb animations, 2 species of butterfly randomly flying around and avoiding the player, I corrected bugs, ...

 Ooooh! Butterflies everywhere!

Next I'll have to polish everything in here, from animations and timing, to speed of the enemies, their reactivity and the power of all weapons in order to make it more well-balanced. But this phase couldn't be tackled without having all the basic moves/behaviours coded! We are nearly done! OK, that's all for today, I hope it wasn't too much, but problems this month were really tough!

See you in the next post for the fight system demo, and maybe a gameplay video if I have time ;)

Peace!