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 !

Thursday, June 11, 2015

Water Splasing effect

Hi guys !

I've been struggling this week to make a nice water splashing effect, directly integrated into godot as a module. It has the advantage to appear has a node into godot's object selector, it simply create a new object looking "like" water with which the user can interact nicely. Here's the video

You can get the code (100% free) on my github rep

Tuesday, May 19, 2015

Godot tiny tips, part 2

In this post, I'd like to talk about character UI and interactions. As I said in the previous post, any interaction with the main character that require some UI response is dealt within the UI node which belong the main character. Since it does a lot of stuff, I decided to make it a separate node in order to make the associated scripts clean (both UI node and character node have their own separate GDscripts).

Read and Talk

Let's take an example. Imagine your character read a panel sign or a old scroll. How to log on the screen this properly. First of all, the panel sign should trigger an action when read. For instance, by passing close to it (with an Area2D node) or clicking on it (with a OKButton node). In this post I'll as an example the panel sign, which show in a dialog a message. I called it a Read node which inherits from an Area2D. The enter/exit functions of the area are simply created in the script thanks to pressing the button shown in red:

This create the functions direclty into the GDscript of your panel sign node (if you don't have a script, you are in trouble, you should have created a script first). But should we do when triggered then ? Well, without surprise, it triggers a call to the UI node. My read node contains some children as shown here:

A button (to click in order to read the sign...), a sprite (the panel sign itself), an anim (to fade in/out a
arrow and a Label that says "Read", letting the user know that he/she has to click on the panel). This is shown in the following picture

Here now is the script of my read node

The ready function masks the arrow. The body_enter, if entered by the girl, fade in the white arrow (which bounce) and the "Read" label, the body_exit invalidate the girl_body reference and fade_out the white arrow.

The button_pressed action, if the node knows the girl_body, just call the read_text function of the UI node (which is a subnode of the girl node).

What does the read_text function of the UI node ? Well nothing special. It popups a panel (the grey bar in the bottom part of the next picture)

And write some text right in the middle of the grey bar. This popup is set as exclusive and the tree is "paused" in order to block any interaction with the game during the time to read. Once the text has been displayed for few second the white arrow on the right of the popup appears, allowing the user to close the popup and reactivate the tree.

Here is the result !

You can download character UI code here:

Enjoy game dev with godot !