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