next »

[irn]

I'm in love. Can't wait to see more!

That`s great, thanks!

This is looking great so far.  You're doing a lot with a little when it comes to the minimalist pixel art, and I'm enjoying the technical aspects of your posts as well.  Look forward to seeing more.

Thanks! There will be much more to see!

[irn]

The world of Tendril: Echo Received will be quite vertical one. There will be houses, facilities, warehouses and other buildings with multiple floors. You, playing as Dragon, will be able to move through ventilation shafts, on walls outside as well as up tall rooms. Civils, guards and other pitiful humans on the other hand will have to use stairs that you will also be able to use of course.

Not far from now we will show you more technical info about how Npc know how to use stairs to move from one place to another and more!

In the meantime just a little animation:

[cepnox]

Today we are going to show you, how we are building navmesh used for finding paths between rooms in the world of Tendril: Echo Received.

Our navmesh consists of rectangular areas connected with stairs thus creating edges. This graph is constructed automatically as you can see in the following image.

Places that are not reachable by stairs don`t contain any node but apart from classical navmesh, they are still traversable. Although NPC on such place is not going to be able to move to another floor.

In the next post we will show you how our NPCs actually use this graph in order to find their doom.

[Garlicguy]

I like the whole evil conquest concept. Interested in watching your game develop! Nice job guys!

[flex$]

been following this for a minute but never commented, everyone loves the look here but i just wanna mention that i really dig what you've been showing off on the technical side and i really believe this work will show just as much as the art will in-game. keep grinding

[Danton]

Great to see this coming along. Love the work on lighting. Navmesh looks great too... clean and elegant approach.

[cepnox]

Thanks guys!

Last time we have shown you how we are building navmesh for our path finding.
Now our NPCs are happily using it to reach destinations beyond their wild imagination.
We are using A* to find the shortest path in navmesh.

We have also decided to change animation of moving into and out of stairs. Now it is more cleaner.
Here you can see the previous concept.

[irn]

Hey!

Have you noticed those ornate decals on the back walls of one of our environments? No? Hmmm... Anyway, there is a small amount of science behind those.
Each decal is a single sprite composed of multiple layers:

When these sprites are rendered, layers are first extracted from them and then all of them are rendered one layer at a time. In Photoshop we have each decal painted as it will be shown in the game. They are of course split into layers also in Photoshop. We use our layer naming convention to determine which layer is which.
The back wall of a room is composed like this:

[Connway]

I agree with flex$. It's been great seeing your editor tools and the workflows you guys have developed.

[irn]

I agree with flex$. It's been great seeing your editor tools and the workflows you guys have developed.

Hey, thanks! You can expect more posts about our editor tools in the near future. There are also plans for improving OwlBt - our behaviour tree editor. We are also currently improving our workflow for exporting assets from Photoshop and Aseprite. There is a lot of automatic stuff. It might be interesting to write about this some more. We love to utilize NodeJs when writing our tools because it greatly simplifies the overall process.

[irn]

Hey! In one of our super old prototypes we experimented with some HSV (hue, saturation, value) modifications. It enabled us to tune colors of our assets in run time. It worked quite well and it was pretty cool! Lately we have decided it has been time to resurrect this idea. Now we are able to play with all three - hue, saturation and value - to achieve variations and specific atmosphere.

In our editor, each back wall defines its HSV profile. When the back wall is added to a room, scene objects in that room use it to change their color. We use this mainly for background objects – not so much for interactive objects. The HSV profile is then used in our pixel shader when rendering each sprite. So in the end we are able to play with the overall atmosphere to create feeling of cold, heavy warmth and so on. We can do this as the first step of designing the room or as the last, or we can come back and change at will.
 

And take a look at this interactive object:

See how the color of the PC is not being changed as much as the color of background? And its screen is not affected at all. We achieve this by defining weights to specific scene object layers that we want to behave differently. This is how we define it in Photoshop:

The PC is composed of multiple layers. Each layer can define its HSV weight. If this would be an animated sprite, the weight could be different for each frame (we animate in Aseprite, where we use the same layer naming convention).
Weights are then applied in the pixel shader and they affect how much the color changes are applied for the scene object's layer.

Weights are especially useful for interactive objects that we want to pop out from the scene and especially for their glows. So camera can still have a red glow while placed into a blue room.

[cepnox]

Hi,
recently we have released a new version of our editor for behavior trees that we use in Tendril: Echo Received, called OwlBt. OwlBt is open-source and it is possible to use it independently of engine that you are using for your games. https://github.com/pruttned/owl-bt

We made it possible to tap into the process of saving and loading of trees and so you can now customize the save format. Now you can even use inheritance while defining tree items and we also support custom types for properties. On top of that we have added UX and design improvements so everything looks more prettier and is more fun to use.

[irn]

Dragon just loves running and jumping. This would be ok, but after some time we noticed that every time he would approach a wall, he would bash its head into it. This was noticeable only when he would stop just in front of the wall. His head would be dug in it. This is because his head sticks out from his bounding box. We had to fix this.
For this we made something we call transformation groups. Each sprite can have multiple transformation groups. We can transform these separately from the sprite itself. Dragon`s head is in a separate transformation group and we move it back from the wall he stands next to. We find the wall using a simple ray casting. 

At last Dragon does not bash his head to each wall he stands next to and we are quite happy with the results.

before

after

[flex$]

glad to see you are still working on this

[RepulseGames]

The game looks awesome. I've always been a fan of pixel art characters with long and thin limbs. It really allows you to give them character solely through their movements. The whole idea for this project is very nice. Nothing super wild but interesting enough to make it feel like a believable and fleshed out world. Keep up the awesome work.

[irn]

@flex$
We live

@RepulseGames
Thanks!

[nova++]

I think my cute-o-meter needs to be recalibrated because I think Dragon is absolutely adorable.

[irn]

@NovaSilisko
Adorable bloodthirsty killer. Perhaps we could add a special skill - Dragon would pose adorably. That would stun all guards and Dragon would then kill them all :D But, on the other hand, Dragon likes guards to be stunned with fear rather than with anything else

[irn]

Dragon is now finally able to move through ventilation shafts to even more surprise his unsuspecting victims! It made Dragon so happy that it spent the whole day doing this:

We wanted the player to be able to control Dragon in the same way as he does outside the shafts. We thought about ideas where the controls would be different and Dragon would also look differently, but we decided that it would be inconsistent. We know that fluid and consistent controls is a must for Tendril: ER. The animations are still just for test, but the idea is there.

[cepnox]

Camera. A pretty large topic, isn`t it? For now, we implemented a basic camera that follows Dragon as he moves. It is a simple lerp movement with a window. The camera moves as little as possible and only when Dragon leaves the window. The window must be quite large because Dragon loves to quickly jump from one place to another and we do not want any sudden camera movements. 

This gives us a starting point and something to test with.

Later we want to try things like moving the camera away from unexplored areas; snapping the camera at the room/area where Dragon currently is; changing the zoom level to focus on important goal; letting the camera be attracted to important goals and others. We will test, test, test. After that we will test.
And Dragon will jump and eat… a lot.