World of Thieves - New Free Demo

And here is the last demo of World of Thieves, a 3D adventure/stealth game between "Zelda" and "Beyond Good and Evil". Don't hesitate to test/share/reblog/comment/like if you want to help me!

Download for Windows

This is the end of December demo!This is the first "complete" demo, with all levels built together, and a global (simple) story going on. And from now on, you can complete an online survey to tell me about the game.

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 (useless in this demo)
• A: mission list
• Tab: head up display of the map... if you have one.

There are four weapons (but only the bo and the slingshot are effective in this demo):

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

Easter Egg: OK... That wasn't intended but there is still something quite funny to discover in the title menu... Beware it's quite difficult to find

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

Have fun! Peace! and Merrrrrryyyyyy Christmaaaaas!

First stealth level

After this week demo, I will talk about little enhancements and the creation of the first stealth level in a pirate warehouse!

I - Little enhancements

• I added a new screen for object discovery: the first time you find a casual item or every time you find an important item, a little screen pops up to explain what it is an how it works, with a little animation of the item.

 The new item discovery screen

• I also tested to add a cast shadow everywhere, just to see the effect. Maybe it won't make it until the end, but it's not too expensive to test (in terms of work). This made me discover a lighting bug: there is some light flickering when the sun sets down and the moon raises because Unity only renders shadows cast by the most powerful light. So I had to smooth light transition between the sun and the moon.

• Then I wanted to work on the graple animation of the character, because it's the only one that hasn't been set yet (even if only in a rough state). I had a very hard time designing the graple itself, to the point where I gave up because I was losing too much time on it. Maybe later... But I set up the basic aiming and flying animations, which makes the trick already.

 I belieeeeeve I can flyyyyy : the graple animation! (This item is not usable in the demo...)

• And finally I worked a bit on the AI of the enemies: I added some reaction when they see one of their colleagues down. So now, they can check out the fallen guy and look around if they spot you. The problem was that I wanted them to remind which guard was down, otherwise, they would check each time... So I implemented some kind of relatively simple memory to avoid this stupid behaviour.

II - Item creation and level design

Another big part of this month work was to create items, including modelisation and texturing of simple objects: nets, pontoons, lanterns, various wood stuff, ramps, ramp poles, chests, doors, switches, keys, ropes, apples, map, ...  But, of course, modeling a door and a switch does not make them interact together. So I coded "simple" (and obvious) systems to make a switch open a door, a chest give items once opened, an apple restore life, ...
 

Aaaah! Lantern and fireflies... :)

Meanwhile, I gathered all those items to construct a "simple" level. I wanted to create the first stealth level (even if you can fight against the enemies). By the way, it would be the first level with pirate enemies. In order to create this first level, I made various logical schemes (even if not very complicated), and ended up with a simple level design: a warehouse secured by a magnetic key where pirates keep their stuff. I added 2 other "big" buildings around to make it more believable: a restaurant (where the guys would eat) and a dormitory set up in a former sailing ship (for the pirate-ish look). I wanted wood, sails, nets and ropes everywhere to accentuate the style.

Once the basic idea was established on the paper, I created the level in Blender using it as a level editor rather than using Unity 3D (which is supposed to have level editor capabilities), because I found out that object positioning is not that precise in Unity. Moreover, and most importantly, I can't model objects in Unity, I can only copy and instantiate objects already modeled in Blender.

The level in Blender. I used a lot of "empty"s with special names to create all the "complex" objects (hero, enemies, doors, chests...) that will be replaced in Unity.

So, I enhanced my simple script dedicated to parse a level created in Blender to partially convert it into smart objects inside Unity (I already talked about this basic blender editor stuff here). I had to find a way to give "parameters" to objects in Blender that could be reinterpreted in Unity, for example: a parenting link is used to represent the key-door relation, a simple tag in the chest object name describes what can be found inside, same thing for a map point name, etc...

The level once imported in Unity. Complex objects are not replaced yet.

The level in Unity after replacing all the complex objects.

But... actually finishing the level (or at least polishing it until it had a nice look) took quite some time! I had to place more than 1800 items in this level! And it's really not big... Creating content may be longer than I expected... :p

See you next time!
Peace!

World of Thieves - New Free Demo

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

Download for Windows

This is the end of November demo! I'm still quite unsatisfied with it... :( There are still crazy bugs in the climbing system and this first "stealth" level is not finished yet (so, once you found the red magnetite, there's nothing more to do except exploration). And the usual posts are coming to explain how this is done.

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
• tab: head up display of the map... if you have one.

There are four weapons (but only the bo is effective in this demo):

• 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 in the title menu... Beware it's quite difficult to find

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

Have fun! Peace!

Gameplay video - Pirate warehouse

Here is another gameplay video of World of Thieves. This time, it's the pirate warehouse level. If you plan to play the demo, don't watch it, or else it will spoil you what you have to do.

Water interactions

Hi everybody!

Here is the usual sum-up of my recent activities, mainly water-character interactions here.

I - Swimming animation

OK! The first idea was to enhance the swimming of the character. So I first worked on the swimming animation in Blender in order to make it more believable (if you played the last demo or watched my last video, you may have noticed that there was no swimming animation).

And once the animation was done, I had to work on the transitions with the other possible states of the character. The more states already exist the more complex it is to insert and "connect" the new one. So I worked mainly on the following transitions:

• swim / climb: the character  can now fall down into water while he is climbing, or jump out of water to a wall
• swim / walk: the character can progressively come from a slight slope beach into water and once he is in a deep enough water zone, he transitions to the swimming state.

A very basic animation. But, we're only going to see the head out of the water anyway.

The final tweaks needed were on the swimming speed and "inertia". Of course, in water, a body is subject to the Archimedes principle as well as to some liquid friction. I started by coding the exact "realistic" forces, but those are not "reactive" enough to make the game nice to play. So I had to tweak the values and coefficients in the equations to give the game a good response time. But I'm not still quite satisfied with it. This may require more work.

II - Particles effects

Now the character swims! But visually, the moves in water seriously lack some water reaction.
I needed to add a few things:

• a more or less huge splash when the character jumps into the water from a relatively high level
• little splashes when the character walks in a bit of water
• falling droplets from the character when he comes out of water
• ripples and foam around the character while he's swimming
• ripples and foam around land and platforms immersed in water
• little water splashes for small object falling into water (arrows and stones mainly at the moment).

And finally, I had to set up the exact same water particle systems for ennemies.

Simple ripples and foam around the character

Foam around a little island and water splashes while the character walks in the water. Well, OK, it lacks a beach...

Little droplets falling from the character after a swimming session. Subtle... But more obvious with the animation.

Ripples around ennemies in water. This required to correct all the sizes and parameters of the water effects.

A few more updates are coming, hopefully with a new level in the next demo at the end of the week.

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!

World of Ninjas Demo

Hello (again),

As promised in the last post, here is the demo of my "Speed Dev Week". It's called 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

How the game currently looks like

Game Rules

• Goal: On each level, get to the objective (the white square) 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. 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

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 :)

PS: My other game (World of Thieves) is still in progress, but I couldn't finish the "eagle Island" level this month, so I won't post an uncomplete level demo.

Speed Dev Week

Hello everybody,


This week, it was logistically complicated, because I was away from home... Some kind of holidays in a sense.... So I chose to work on a little side-project: a 2D top-down view stealth game with the possibility for the player to easily create levels. Graphics are of course very simple, but the goal was mainly to create a tool to quickly test 2D level design. So if you want to create levels yourself, watch out for the next demo of... World of Ninjas (yes, I'm really inspired when it comes to names).

 A very poor look... But it works...

Hence, this (long) post will explain more or less in detail the creation process done in... 1 week. The next post will link to the demo!

Day 1

• Basic character and camera control: the player can move, the camera follows him.
• Dynamic level loading from image file: I simply choose to use paint (or gimp) to create a logical map of the level. The map is loaded and each pixel is interpreted as a game object:

1. blue = player
2. grey = wall
3. red = enemy
4. yellow = path of the enemy
5. ... and additional colors for other elements can be added

• "basic enemy": I created a simple enemy game object that follows a path

 

 

A basic map made in GIMP

Day 2

• Field of view of the enemies: they can detect the player if he is visible within a given distance
• Checking out of an old path planning algorithm (A*) and adapt it: now enemies can avoid walls and find paths on their own (not only follow a designed path). They can also search around when the player was visible but escaped.
• Optimizing A* to have real-time compatibility: path planning computation are really cpu intensive and can make the game lag/slow down. I had to limit the computation time available on each frame. Thus, complex calculation takes more frames to get done, but does not slow down the game.

Day 3

• Main menu and level listing: adding a title screen with level selection (levels are read from image files on the hard drive)
• Enemies can shoot the player if he is visible
• Player can shoot to respond to enemies: use the mouse to aim
• Player can slash (short range attack that won't consume ammo). You can move the mouse to control the blade direction while slashing. It's quite fun to do :)
• Refine field of view display: I want the player to understand quickly what enemies can see and what they can't. So I used the old "Commando" game style:

Enemy field of view. Quite harsh to implement, and far from optimized. But... quite functional at the moment.

Day 4

• Add "Goal" object (white pixel on the map): a particular object the player has to get to before exiting the level to succeed
• Level success/failure: check when the player finishes a level or when he dies
• Statistics on kills and time: once the player finishes the level, display a few information
• Add a level validity check: verify that the image file exists, is not corrupted, and has minimum information (a blue pixel for the player)
• Keep last score: once a level is finished, the last statistics are saved and displayed on the main menu
• Add command list: start to create a head-up display (HUD) to explain commands and show the player inventory
• Enemy react to killed enemies: when an enemy sees a killed enemy, he goes towards him.

Day 5

• Shockwave : to simulate sound, I add "shockwaves" when a bullet hits a wall for example. If an enemy is hit by the shockwave, he will go to the sound origin to check what happens.
• HUD improvement
• Add impact when enemies are killed
• Player can carry objects or killed enemies
• Player can throw objects or killed enemies
• Player can drop bombs: bombs create a large shockwave that kills enemies and destroy nearby walls.
• Add wall debris after an explosion
• Add proximity mines: some special kind of bomb that explodes when something moves around. This was quite tricky to implement, because this mine must take some kind of "snapshot" of what's around when it's armed and constantly check what changes nearby.
• Add a weapon selection menu

Shockwave during a bomb explosion

 Day 6

• Additional HUD modification to take into account all the new available moves
• Various bug fixes (I don't talk about it, but I do this everyday of course)
• Display the proximity mine danger area
• Add a few items to pick up: life, ammo, bombs, mines

Day 7

• Write this article (don't laugh... it takes some time!)
• Write a readme explaining how to create levels
• Put a download on this website

And at this point, that's all I have. I already noticed a few additional bugs that I'll have to fix, but the goal was to set up a playable prototype within a week. If it works well and is quite fun, maybe I'll improve it later, I already have a very long list of possible enhancements/corrections.


About the bugs: adding new items/functionnalities always raises new questions. For example: "what happens if a "life bonus" is hit by a bomb shockwave?" The more elements there are, the more complex interactions can be. I surely missed some. By the way, professional developpers often say they only create 5 bug free lines of code per day. I coded ~2250 lines, with hopefully 50 free bug lines... That means there are still loooooooots of bugs to find, I count on you :)


That's all for this week. See you next time.

Saving data

Hello everybody,

Today, I'll speak about... saves! So this post won't have a lot of screenshots, mainly boring text ;)

Not very impressive, but here is the save menu!

As I want to be able to build up a complete version of my game as early as possible (even if it's only on 1 level), I have to implement eveything the final game will need. And recently, I thought about the "game over". What happens when the player fails?

I - Problems

Well... This question is a lot trickier than it seems. Because when the player fails, the game must bring him/her back at some point where (s)he is OK.Thus... we must save this "some point where he is OK". Hence a few questions come up:

• Does the player choose when to save? If so, he can ideally save whenever he wants, and there is absolutely no difficulty to the game. Moreover, technically, this means being able to dump everything that is in the RAM, resulting in hundreds of Mo of data (maybe many Go). This makes the save and load process rather slow. And by the way, who cares about the exact position of a bird in the sky that you may not even have seen?
• What happens if the player saves during a battle? How to manage all the timers, the physics engine running in background and all the objects in an unstable state? What happens if the player saves when (s)he's dead? (Yes, there are some games where it's possible...)
• If the player doesn't choose when to save, does he still control the saving process? That is to say, are there some visible "checkpoints" at which the player can save its game? 
• The other way around is that the computer manages everything and performs automatic saves completely hidden from the player. But in this case, it means that if a crash occurs, the player may totally lose his game. Moreover, if many players try the game during the same period, the game should be able to manage different "profiles" in order to accept different players.
• If the computer manages the saves, I don't want them to happen everywhere. I have to chose some "safe places" (ie without too much interaction around) and at strategic points (beginning/end of a quest, before difficult parts...)
• There are some games where, when you die, you don't go back to your latest save, but to some automatic checkpoint that you didn't even notice. This avoids a lot of frustration to the player if it's been a loooong time that he couldn't save. But of course, if you quit the game and you come back later, this automatic checkpoint does not work anymore. You start from your last save. Is it an interesting mechanics for my game?

Hence, those questions sum up in "when, what and how do I save?"

• when: everywhen vs checkpoints
• what: everything vs only a few states (player position, inventory...)
• how: player vs automatic

And there are some more-or-less inevitable links, for example: everywhen => everything, automatic => checkpoints, everything => slower and space eater, automatic => difficult crash recovery, ...

II - My chosen solution

So I considered using some kind of "old-school" save system: There will be checkpoints, and the player will manage saves him/herself. At the moment, I allow 5 save slots for testing purposes but this number will likely raise. Here are the main advantages:

• This enables many players on the same computer, and/or many different saves (I usually liked old games when you could keep a save just before a cool boss). 
• The saves will be dumped on the hard drive in different files (slot1, slot2, slot3... etc). Hence, one can copy-paste saves to keep them after removing the game, 
• It's also possible to share saves with friends!
• It enables to have various saves in case one crashes
• Furthermore, this system may be compatible with some "automatic checkpoints" too. Maybe I'll add some at any point where I don't want a "game over" to be too harsh.

III - Implementation

While implemeting this system, I had lots of problems, especially with regard to the software design (I'm not that good in software design). I won't detail everything here, but amongst other (this is a bit technical):

• The "save" data is implemented with static attributes (some kind of "singleton class"), which enables me to easily reach/modify it from every object in Unity. As soon as the character makes actions/complete a quest, everything is registered in the save object.
• At save points, I dump the save object on the hard drive using XML serialization, but, static attributes are not serialized, I had to code this myself.
• Hence, that means there is only one "save" object in memory everytime, which is problematic when you want to list all the saves that are accessible from the hard drive... Because when you want to load a save, you want to know what's inside. This means the game has to read them all, and display a few relevant information (place, time played, inventory stuff...).
• The dumped files may be edited with an hexadecimal editor... I tested it, and it seemed I corrupted the file, so I had to add some kind of validity check before effectively loading a save.
• And of course, I also had all the classical problems of GUI: menu navigation, font and button resizing, toggle character control when you're in the menu, differentiating main menu and in game menu...

Well , that's all for today! See you next time guys!

Peace!

First level - Eagle Islands

Hello,

This week, I worked on putting together the first level of the game. Beware, spoilers below :)
As usual, I'll try to explain what my goal and constraints are... So I hope you don't mind if I get chatty :)

OK! First, I must think about a simple goal for this first level that may fit within the universe/world, the global story (because yes, there is a global story), and my guidelines (humour, freedom, oneiric).

A glimpse at the first level.

I - Technical constraints

This is the very beginning of the game, and the player doesn't have a lot of skills at the moment. This level will more or less be a tutorial, but without instructions, just to see if he got all the basic moves, and if he's able to combine them in new ways. At this point, the moves are mainly platformer-like (no fight yet, but this will come ;) ).

II - The world

I want the game to take place in a world where there are many different islands (in the sea... or floating in the air). Why different islands? Because...

• This is fun to have many islands to explore, there is a feeling of freedom while moving from one to the other, and islands often sound like "paradise" (even if that's not always the case). 
• Technically, this is much easier to manage: while navigating through the islands, the levels can be dynamically loaded and unloaded without the player noticing it too much (well, theorically... We'll see if I achieve this in practice).
• In terms of design, this is a natural partition of levels: adding a new level/environment can be done by adding a new island without having to think about all the connections to the other environments.

III - The story

The goal in this first level will be to use the thief skills of our hero to get an egg on the Eagle Islands. The Zoological Institute has watched this place over the past weeks and has noticed that one egg is not brooded anymore, maybe the mother eagle disappeared. The goal is to get this abandonned egg  and bring it back so that the Institute can take care of it. However the place is not easy to approach because of all the brooding eagles.

So in this setup, we've got platformer components with floating islands, stone walls, jumps to make, rocks to climb and the first lively ennemy: eagles. Eagles can add a good value to the oneiric feel :). They are just peaceful beasts, but don't get too close to their eggs!

IV - Prototyping the platforms

This is actually not that complicated. A few cubes here and there, and let's see if it forces the player to practice all the basic moves he's been taught, and a few more that he will have to imagine. The most important thing to test is that there is no hack to avoid those particular move combinations.

A simple level (logical) prototype in Blender: pretty much only cubes...

OK prototyping is always quick and fun... But creating the real graphics is a lot more time-consuming... Once basic forms / hierarchy of the level are OK, I have to create every island, and vegetation spot on it.

Sloooooowly creating the real graphics in Blender... I don't detail every stage here, maybe on a later post.

Final level (at least for the moment...) in my game editor (Unity)...

V - Steven the Eagle (yes, this pun seems to work with all bird names)

Creating the first lively enemy has been a great challenge... I started with the model of the seagull that I corrected to make it look like an eagle. Of course, I kept the few flying animations to add flying eagles around the level. But the BIG difference with the seagull is that I want it to be on the ground too. And I was a bit unaware of the difficulty to make an animation of a bird folding/unfolding its wings. It's such a mess! See for yourself:

The eagle with folded wings (after one full morning of work... Just to finely position the bones) ... You can see the skeleton in blue. This was a real challenge to smoothly deform the 3D model without creating too much artifacts on the high-torsion zones... I had to catch up a few zoological anatomy classes in order to create a believable wing deformation ;) Believe it or not, a bird wing and a human arm are not that different.

And then I had to add some "logic" to its behaviour. I want it to be an obstacle to the player, but the player has to be able to find a way around it without using any fight skills (he doesn't have any at the moment). I won't detail here the tricks I used to design this eagle enemy (how to make the player understand there is a danger? How to make him understand how to counter it? Do I help him a lot? Not at all? What is the sanction?), but you'll see the final result in the next demo (surely at the end of the month).

 Don't upset him! Or you'll regret it... Can you believe it? He can spread his wings! Yay!

Wow! I've written a lot, and I didn't speak of everything yet (adding some pickable items,  tracking bugs, adding a few sounds, adding variety to the look of the eagles, including an albinos one... for a secondary quest). Well I guess that will be for another post :)

Peace :)