Gameplay Video

A little gameplay video of the current version of World of Thieves. There are still bugs, but you can get an idea of the style of the game.

World of Thieves - Fight Demo

And here is the last demo of World of Thieves! It's a 3D adenture/stealth game between "Beyond Good and Evil" and "Zelda".

Download for Windows

Actually this demo is a single whole new level (some kind of pirate marina) to test the fight system. But you can also try the stealth approah if you want ;) However, I don't think this level will be in the final game, it's only a test level. There's no real goal except getting all the 74 "magnetite" bonus items. But you can wander around and see what happens.

Controls:

• QSDZ or arrows: move the character. By default it's AZERTY-friendly, but you can change the config in 5s on the splash screen.
• space: jump and climb
• mouse move: move the camera
• mouse wheel: zoom
• left click: attack
• multiple left clicks: chain attacks
• hold and release left click: mega attack
• hold right click: aim with secondary weapon
• release right click: shoot with secondary weapon.At the moment, you can't shoot while running.
• e: weapon menu

There are four weapons:

• Bo (woodstick): basic melee weapon
• Slingshot and stones: use it to catch the attention of enemies. 
• Bow and arrows: to make enemies sleep. You need 4 of them to stun an enemy
• Graple: useful to get onto unreachable walls.

Easter Egg: OK... That wasn't intended but there is still something quite funny to discover... beware it's quite difficult to find

Bug hunt and feedback: As usual, contact me for bugs or any feedback.

Have fun! Peace!

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.

Demo World of Thieves

Here is the last demo of World of Thieves! It's a 3D adenture/stealth game between "Beyond Good and Evil" and "Zelda".

Download for Windows

Controls: arrows or [zqsd] + space + mouse. By default it's AZERTY-friendly, but you can change the config in 5s on the splash screen.

Easter Egg: OK... That wasn't intended but there is something to discover in the menu or the cutscene... beware it's quite difficult to find! Have fun.

Bug hunt and feedback: As usual, contact me for bugs or any feedback.

Have fun! Peace!

Demo World of Ninjas

Here is the enhanced demo of World of Ninjas! It's a 2D top-down view stealth game, somewhere between "Commandos" and "Hotline Miami", where you can create your own levels.

Download for Windows

 Game Rules

• Goal: On each level, get the sword(s) and escape far away from the buildings (in any direction you want). Just get far enough (in reality you have to leave the level area).
• Controls: arrows or [zqsd] + space + mouse. By default it's AZERTY-friendly, but you can change the config in 5s on the splash screen.

Level Editor

• Use Paint or whatever image software you like to create a PNG file with a black background in the "Levels" directory. Levels don't need to be huge to be fun; 100x100px is already enough, but you can create whatever size you want.
• Blue pixel (0,0,255): player (it's the minimum requirement for a level to be playable)
• Red Pixel (255,0,0): enemy. Don't put too much of them, it can slow down the game, but it depends on the power of your computer...
• Yellow Pixel (255,255,0): path for the enemies. An enemy will follow a path if he's just NEXT TO a yellow pixel. You can use a single yellow pixel to make an enemy move to it an look in that direction.
• Grey Pixel (128,128,128): wall
• White Pixel (255,255,255): goal (sword). You can set multiple goals if you want
• Purple 1 (255,0,255) : life bonus
• Purple 2 (255,64,255) : ammo bonus
• Purple 3 (255,128,255) : bomb bonus
• Purple 4 (255,192,255): mine bonus
• Green (0,255,128): a cherry tree:)

Don't hesitate to check out the available levels to get an idea of the color use. Be careful, you need to use the exact color codes (R,G,B) described above.

Don't hesitate to send me your levels if you achieve to create something cool :). May be I'll add them to the next version of this game! And as usual, contact me for bugs or any feedback.

Thanks guys, and I hope you'll enjoy it!
Peace :)

Cutscene and polish

Hi everybody,

It's been quite a long time since the last post (and it will be even longer until the next one).

I - So... What did I do?

During this month of August, I worked on a lot of different things...

• First, I worked on the graphics of World of Ninjas (my speed-dev week game, made at the end of July)
• Then I worked on creating a "cut-scene" engine for World of Thieves. Hence, I could create a short animated introduction to the game. And I'll be able to (hopefully) easily add other ones in the future. This will be the focus of today's post.
• I also cleaned the code and the resources because it's starting to get huge! I have nearly 2Go of data among which 3D models, textures, sounds, ... All this MUST be structured and well organised when you have to fix bugs, improve graphics, correct sounds; otherwise, you spend hours searching for the last version of the resources.
• While I was creating the intro cutscene, I really noticed the lack of music, and I felt inspired to set up a complete workflow for music creation. I spend 2 days trying to configure a Computer Aided Music pipeline... UNDER LINUX: Jack (fundamental real-time sound server) + Rosegarden (midi composer and partition editor) + Fluidsynth (synthesizer) + Hydrogen (drum-specialized midi composer) + Ardour (multi-track audio recording and mixing) + Audacity (sound modification tool)! Yes! Because I always did CAM under Linux, and I think the softwares are really great and FREE of course... But you have to be willing to spend a few days trying to understand them. More on this later :)
• Finally I added some polish to the game: icon, title menu, some help in tutorials and notifications when you get an object, additional graphic improvement and of course, as always, fixing bugs and lags...

So, today's post will focus on the animated introduction of the game.

A screenshot from the opening sequence

II - Creating an opening animation

If you have already tested the previous demo, you may have experienced a few difficulties to get into it. That's because there is no global introduction to the game setting up the "context". All games have this kind of introduction to enable the player to progressively enter the game. Even movies have them. Introduction sequences are often wide shots where you can have a grasp of where and when the action takes places. With this in mind, I made a storyboard about this intro a while ago:

A quite unreadable storyboard (in French) with a weird reading way :)

Of course, these are personal notes, and I have a very poor hand-writing, so you may not understand all. But the goal was for me to have a record of the general idea of how the camera moves, what happens on screen, what is the timing... etc. This storyboard was very optimistic ;) Finally, I simplified a lot of things... For example, at the beginning, there is only the hero on the boat at the moment. Maybe I'll add more guys later. But those are not mandatory for the story understanding.

III - New 3D models

OK! I have the idea more or less clear in my head and on the paper, now it's time to actually model all the stuff we'll see. This includes:

• The Thief Guild Island: until now, I only had the "inside" of the main yard. I have to add the "outside", that is to say the whole island.
• Various decoration stuff: fir trees, benches. I already had a few ones that I took from the Eagle Island.
• The ship on which the hero arrives at the island. 

This doesn't seem that complicated...
...except... that at the beginning, I don't have a very precise idea of how they may look like. So I spend a lot of time trying to "design" their look. Do I want something curvy? Something blocky? What colors? what materials? Something original? Classical? Can the viewer/player understand what it is at first sight? Does it merge well with the graphical style? Of course, one can always say "I want something cool!"... But what is cool? Can we draw it? This pushed me to draw a lot of concepts. And it took me very long to achieve the result you'll see in the next demo.
The 3D model in itself is sometimes complex to create, but the idea is a LOT longer to flesh out. It's a long period of trial and errors, coming back-and-forth between Blender, GIMP and a simple paper sheet. Moreover, you have to put this necessary time in balance with other things: do I have the skills to create what I have in my head? (Obviously, not yet...) Can I spend more time on this according to my planning? (Obviously, no again, I'm always late...)

Some of the concepts I tried before I finally achieved something that "was OK" (but far from perfect). You may notice that this is a mess because I tend to draw everything at the same time: buildings, vehicles, characters... I just think about stuff... and they sometimes mix between them.

The new Thief Guild Island and a "conceptual" Earth-ship: a floating island propulsed by two engines (the "floating" island has a "scientific" explanation, that will be detailed later in the game). It's not just random stuff. By the way, my cartesian mind sometimes bother me when it comes to design, because I always think, "this is not possible in the real world", and I have to find some (basic) believable explanation for everything I have to create.

 

IV- Animating the models

Nice! I have the models! But nothing moves by now... Luckily, this first scene doesn't need a lot of animation. But there are a few ones: water splashes and foam around the boat, the running hero, the camera, and of course, birds and fishes.

Surprisingly enough, the most difficult one to set up was the boat foam and water splashes, because they rely on particle systems that are really CPU-hungry! So, I spent a lot of time finely tuning the memory use to avoid any lag. But I can't be sure it will be OK on any computer. Time and tests will say.


I already had the animations of the hero, the birds and the fishes, so that was a bit of a relief, even if I spent some time on the hero trajectory.

V - Adding sound

And, no that's not finished yet. Because a silent animation cutscene is quite weird. Here again, I already had the sounds of the sea, the wind, seagulls and fishes. But I spent sometime creating the engine roaring sound. I took a creative commons sound on the internet, but the problem was none of the sounds you find on the internet are loopable. Because I want my engine sound to play in loop (I don't want to stock a 4h-length engine sound that will saturate computer memory).
Hence, I used a software called Audacity (great free sound editor) to make the engine sound loopable without the ear being able to notice any peaks or clicks... This was quite new for me, but I finally achieve to made something decent by playing with various samples and alternatively fading them in and out.

VI - Adding music... Wait! What?

And that's it! Because I didn't have the time to create a full soundtrack for this animation. However, I tested it with the Ocean Theme of Zelda Windwaker, which is really the atmosphere I want for this game, and it's kinda cool! But I won't use this (c) Nintendo musical property in the end, neither in the incoming demo, for obvious copyright reasons.

So, don't go to far, there are 2 demos coming in a few minutes... 2? Yes! The graphically improved "World of Ninjas" and the classical "World of Thieves" with the introduction cutscene, the tutorials at the Thief Guild, and the Eagle Island level!

See you soon!