Sunday, March 5, 2017

Sundays afternoon with Godot: E02 exploding the world.

Custom objects which explodes in many parts is not so easy. There are several ways to do it and mine is, most probably, not the best one. Let's take the example of a simple crate. First, it is decomposed in several wood pieces, allowing to break it afterward.
So this crate:

Is made of those little pieces:
Which are all a single part of a bigger sprite (all the objects of a given scene are subparts of a single sprite in my case). When the little girl strikes the crate twice, a call to a function "explode" is made.
First, let me show you how the crate is organized in its tree
Since I didn't manage to create properly the collision shape at run time (mainly because it has to fit exactly to the visible part of each wood piece) I prefered to create those collision shapes from the editor.

When the crate explodes, I'm creating a RigidBody2D per wood piece and throwing it away with speed. Then comes the messy part:

First, I get the wood piece, which is of Sprite type. Then I get the CollisionShape
D, which is only a proxy node for the GUI, but not really a type. Then I extract the real shape (rectangles in my case) and set them as collision shape of the newly created RigidBody2d. I haven't managed to set the shape directly to the rigidbody2d. Then remember that the RigidBody2d is created at coordinates (0,0) from its parent. Therefore to place it properly, we move the rigid body to the position of the sprite. Since the sprite becomes child of the rigid body I then set its position (relatively to its parent to (0,0)). I do the same for rotation. It's messy, but it's some kind of workaround.
I tried other things, and if anyone has suggestion to do it cleaner, I'm taking it!!!

And here the result:

Sunday, February 26, 2017

Sundays afternoon with Godot: E01-Collisions

Varying the environment is necessary to make the game less boring. I give here some examples implemented in LittleShadows. You'll see how easy it is do that with godot! First, here is the resulting video:

First of all my main character, the little girl, has several collision layers and masks.

It decided to keep it easy however, you'll see how I dynamically manage some bit masks to alter the behavior. The first collision layer is used to collide against the main tiles of the tilemap which is used to create the ground and walls. The two layer masks are used to detect collisions against ennemies and objects. Additionaly, the collision layer no. 4  (and not mask) will be dynamically set when the girl touches the ground and removed when she jumps or the move down button of the joystic is activated.

Stairs: Stairs are important element of a platfetormer game.In the case of LittleShadows, the stairs are distinct elements from the basic tiles used to create the ground which are gathered in a single tilemap. n the contrary the stairs are a special "scene" or node.

In blue you can see the collision shapes of the the tilemap and in red the collision shapes of the stairs. In order to make a smooth transition between the ground and the stair there is a gap between them, allowing the collision shape of the girl to pass in front of the stair without noticing it. If the player wants to move on the stair he or she only needs to jump. The stairs are in collision mask 4 therefore as soon as she jumps the collision is not detected so she can pass through. However as soon as the Ray2d detecting the ground collides with it, the collision layer 4 of the girl is set back to true allowing collision.

Scaffold: The scaffold uses the same principle allowing to get down from it using the move down button of the joystic.

That's all you have to know to set interesting rules of collisions!

Friday, January 6, 2017

In-game footage

Sooner this week, I have uploaded an in-game footage of the game. I got some nice feedback from social network, which made me rethink the visual look of the backgrounds and the animations. Is always good to have some constructive feedback from people not involved in the dev process.

The forest bakground will change quite a bit and ressemble more to something like this, with more pale tones. 

I'm so excited! Moreover it helps me to construct the game's story and move it forward, so I can't wait building more elements and showing them. 
Soon !

Saturday, December 10, 2016

Streamlining workflows

One of the most precious for a developer, and in particular an indie developer, is , at least for me, time. It's SO easy to waste time doodling, trying stuffs around and not really doing something for your game. It's not really procrastination, but you're just get stuck at some point in the creative process and fell you can't make progress anymore.

My solution to that? Designing carefully workflows and steps you can follow systematically, a framework you can apply each time you want to create a new level or a new character or a new anything inside your game. Create simple workflows and follow them.

Inside this frame, you have all the liberty, the creative power is free to be unleashed, but always stay within the frame. Or at least: leave it at your own risks!

In my case it always starts by doodles on paper. I got a wacom tablet but I just like the feel of paper. I'm used to it. I'm probably old school by many aspects, but I need this real feel. In that case the doodle are done fast. I just take a picture and wooop it's imported in inkscape

The next step is straightforward: creating the assets from the doodles. Sometimes I'm working from scratch in Inkscape, but for some reason I don't fully understand I just got much faster if I have an underlying reference. It's probably the way I'm working with the stylus of Inkscape with my mouse (can you figure that.... with my mouse!) rather than with the pen on my tablet. I never achieved to work properly with my tablet on Inkscape, I should try do achieve that one day.

That's my assets with some random color I added to make it nicer. However, I think you noticed, my game is rather dark and in greyish tones. Therefore before puting them in  godot, I need to grey them out a little bit...

And after some trial/error/sleepless nights, here the result:

Wednesday, February 24, 2016

How to smash the world with Godot?

Short answer: use  a "destroyable" group for your game entities

Now, here's the awaited long answer. My main player wants to use the sword in her hands to smash many things into her world. First, she wants to smash ennemies. And crates. And rocks. And occasinally plants, maybe because she's pollen-allergic although it's probably not a very good idea).
In order to make the sword aware of the object it crosses, I had first to create an Area2D around the sword like that

However wa have to discriminate when the Area2D crosses something to smash and when it crosses something else. In order to do that, we just kept the relevant area entering discarding all the bodies (RigidBody2D) and Area2D which doesn't belong to a given group, a group we tag as 'destroyable'.

In order to set a given node to a group, you just have to select the group button at the top of the Tree View (the selected button in the next screenshot)

So all our smashable objects are in the same group, the "destroyable" group. Then,in the code of the Area2D we just call a damage() function on any object of the destroyable group. Therefore the ennemies, the crates, the plants should have a damage() function which can all be different, allowing to have different behavior when those entities are destroyed. The gdscript for the sword is the following

Note that we first check that the girl is playing the "hit" animation, which assures that the girl is effectively doing a hit gesture.

And that's it !

Saturday, February 6, 2016

Setup your tiles to work with Camera zooms.

In this small post, I'll discuss a little bit how to organize the tileset in order to avoid artifacts when zooming/dezooming with the main scene camera in Godot.

If you craft your tileset naively (as I did as a first timer...), playing with the Zoom factor of your camera will trigger some weird artifacts, like in my case dark or empty line around each tile. Here the zoom factor is 0.75

First of all, why? It simply because the GPU renders scaled textures by trying to compute some average value from a number of neighboring pixel. In the case of the basic rendering of pixels at the border of my tiles, it may (and will) use the pixels of the next tile, which may be of a different color (transparent when I want black and vice versa). Although there are option in OpenGl to select to extend the border of the current image, it seems that godot doesn't use this option for tilemaps. But that's not a problem.

We know how to fix it.

The first solution is to use a different image for each tile. It works, but if you want to deploy on a smartphone it may be a bottleneck, since loading your tilemap will require to load a lot of different images in memory, and this should be avoided, as far as I know. But smartphone change so fast that I'm not sure.

An other solution is still to use a single texture/image for all your tiles but simply to organize your tileset in such a way that the border of each tile has exactly the same color of the tile (up/down/left/right) next to it. I'm guessing that the upscaling is probably more problematic, but as far as you don't use a crazy Zoom factor, I think it will only rely on 2-3 additional pixels around each

For instance, here how I'm doing within Inkscape. I'm gathering tiles along their borders, so that they make a compact bulge. Each tile will take the place of each red lined squared, and you may see that the pixels across each of the borders have exactly the same color in the 2 dimensions.

And here's the result, with the same zoom factor than above with a carefully designed tileset sprite

Much better don't you think?

Saturday, June 13, 2015

Just a small snapshot

Just for you to enjoy the atmosphere... What do you think ?

Do not hesitate to follow news on fb page of Little Shadows !