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!

Bringing pirates to life

Hello everybody, it's been a while!

I finally managed to get back to work after these long holidays... And since the beginning of October, I've worked mainly on the combat system, and interactions/items/weapons. So the incoming demo will focus on this part. I won't post again the tutorials and 1st level, even if I fixed a few bugs on them. And today post mainly describes the creation of enemies.

I - Moving Pirates!

OK, let's start by talking about pirates! Of course, it doesn't make any sense to code weapons/interactions if there are no other characters to interact with. So I finally used my old pirate character (see this post) to bring him to life. I added a few animations, especially punching, aiming, being stunned and seizing a weapon. By the way, I used a quite singular weapon I had the idea of a while ago: an anchor. It can be used either as a melee weapon (it goes well with the tough bad-guy look of the character as well as the overall sea theme) or as a range weapon (it looks so much like a giant crossbow!).

This is a big anchor :) And yes, I made a test level where you can walk on water. Just for fun.

Once every models and animations are created, the most difficult part comes in: synchronizing everything in the game. Because depending on the state of the pirate, the weapon can be held on his back, or in his hand. As the character is deformed by a skeleton, this means that the weapon is linked to a particular bone to follow the movement of either the hand or the back of the pirate. But when the character reaches for the weapon, this link changes. And it has to change at a very precise time and place. This is very long to set up and finely tune, because it involves a lot of going back and forth between the 3D modelisation software (Blender for me) and the game engine (Unity), as well as executing the game frame-by-frame.

The precise moment when the weapon goes from the back to the hand of the pirate. This seems so simple when you look at it... But I spent hours on this.

So I finally set up something I hope is quite generic and flexible: the pirate can carry various weapons and can have different moves to automatically catch the right one. With this sytem, I should be able to create enemy variations quite easily: various weapons, ammo, strengths, speeds, aggressiveness, textures and skins... And of course, the pirate should be able to choose his weapon according to some kind of analysis of the surroundings....

I also added a few particle effects and sounds on the hits.

II - Reacting Pirates

...Which leads us to the high-level AI (artificial intelligence): now that basic moves are set up and well coordinated, I want my pirates to have some kind of "intelligence", or, at least, believable behaviour. And this is generally a huge burden in video games, even the most recent ones. I already tested a few simple algorithms myself in my little game World of Ninjas as to how enemies can react to the player behaviour. 

I kept the same global scheme, and, for the moment, in World of Thieves, enemies basically shoot at the player when they see him, try to get close to him and punch him when they don't have any arrows left, and search for him when they can't see him anymore. Of course, it is impossible to create a perfectly realistic behaviour, because there are so many things to take into account. So, as usual, I asked myself a lot of questions, like:

• Do they have an infinite number of arrows? If yes, they don't ever have to come close to the player, but that's obviously unrealistic.
• Do they punch with their bare hands or with the anchor? Can they switch? If yes, when would be the moment?  
• When they "die" (fall asleep actually), what happens if they're holding their weapon? Do they keep it in the hand? Do they put it back on their back (which is in no way likely to happen when you fall asleep)? Do they leave it away on the floor? If it goes away, the player will surely try to catch it and will be disappointed if he can't.
• If a pirate has many weapons, how does he choose the one to use? 

I'm lucky they don't have infinite ammo.

Usually all these questions lead me to think about "what would *I* do?" Then, "Is it interesting for the gameplay?", then "How many additional modeling, texturing, animation, coding, and sounds this 'simple' move will require"? Is it even possible to code such a behaviour for a real-time game? Does the fun it gives counterweights the required time and problem solving to set this up, which you can't obviously know without actually doing it?

And one always has to sacrifice some aspects to save others. It's ALWAYS a matter of compromise.  But at the end, the only question I should have to ask myself is "is it believable enough to have fun?". And I regularly see people playing my game without even noticing all the little behaviour/logical flaws I see everywhere.

III - Cycling the behaviour

So I've got something quite OK for the fight attitude. But I want my game to be a "non-killing" game. So enemies won't disappear when you beat them. They fall asleep where they are. But this raises other problems: 

• Do they fall asleep forever? 
• If no, when do they wake up?

To this point, I thought it could be done easily: they sleep for a while, then wake up with their full strength and they're back in the game, remembering nothing because they are stupid pirates.

But while coding attacks from the player (more on this in the next post), I noticed that it would be funnier if there was some kind of impact projecting the enemy back (as in a lot of video games by the way, that's no coincidence). But, by adding those impacts, enemies may be thrown away in areas where they are not supposed to walk (sloppy roof, water, another enemy, a big hole from which they can't get out...). This simple decision made me think a lot about what an enemy who falls in such an area should do? Just disappear? Dig and get back to his previous place? Be killed? Teleport back?

The hero can do a lot of moves, but the enemy doesn't have the climb ability (for purely technical Unity reasons), so I had to find something else...When I was sick of spending so much time on such an insignificant choice, I finally gave up and chose to make the ennemy stay there, and "reset" to his start place when the player is far away and doesn't look. While waiting, I will make him have a funny animation like playing dices, playing with his parrot, drinking rhum or whatever a pirate does when he waits. About the water, if they fall in the sea, they just stay there too, enjoying the calm while floating on their back. I like the idea of "water-addicted" pirates who become useless once surrounded by water. Of course, I'll have to make this funny by making them say stupid things like "Oh I forgot how cool it was to take a bath", "Waaaaaaateeeeeeer", and other "Ooooh the sky is so beautiful from here", in short, things a really-tough-pirate guy would certainly not do. But, hey, this is a humorous game, and those guys already have a "Mom" tattoo.

 Bath for everyone! And yes, in this level, you can't walk on water. I had to test the swim and floating moves ;)

That's incredible to see how a simple decision as "arrows project back enemies" impacts other aspects like "can the psychology of the pirate justify its non-action in water?". Everything is so intricated if you want to create something consistent (not necessarily realistic, but consistent in its own way)!

So at the moment, pirates react... But they are still quite stupid (it's Artificial Stupidity), you can check it in the next demo :)

In the next post I'll talk about creating the equipment/weapons for the main character.