August 25, 2013

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".



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!

August 24, 2013

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.






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

August 23, 2013

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!



July 29, 2013

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.



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.





July 28, 2013

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.



July 19, 2013

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!

July 7, 2013

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