Devblog 04 – Izimu 01: Ibamba-Khulu

Today we are finally ready to show one of the core features of our game: The Izimu.
This isn’t the first boss we designed, as you can see from previous trailers, but the older one had too many technical problems to be used, even if it will always remain in our hearts.
But right now let’s talk about the elephant (or the giant boss) in the room: Ibamba-Khulu, or as we call it in the studio, codename Atlas.




The most difficult part in modeling was making the model as similar as the concept. Animations took a very important part in thinking about it (compenetration problems, coherence, etc.) and the fact that Ibamba-Khulu is an enormous climbable skinned mesh is itself is a lot of work, and every time we try it on the engine we come up with a different ad hoc mesh change.
Another issue was maintaining a good texture quality, by generating the best and most compressed textures and atlases, since you can clearly see bad textures when they are standing 20 meters tall in front of you.
Regarding the poligonal count, unity lets a maximum of 50000 polygons per skinned mesh, so a lot of optimization, cleaning and decimations had to be made for every part of the colossus.
But even after all the optimizations Ibamba-Khulu remains very heavy render side. So to contain framedrops we decided to put the colossi in specific areas closed by mountains and meshes, so to not render other objects thanks to occlusion.




After countless hours of research (aka pissing off different colossi in Shadow of the Colossus), we discovered that every attack that one boss does usually has a common beginning, but a different ending. For example, for Ibamba Khulu we animated one beginning of the kick, but we made several different endings depending on which zone the target character will be.



Adding on that, right now we are doing some researches on an ik system to give more realism to the walking cycle in-game, letting us change the direction even in mid animation without letting the izimu slide on the ground, but this is for the next devlog.
Here is the walking cycle animation:



and now, the juiciest part (brace yourselves because it’s pretty technical)




Our programmers worked on a vertex based climbing system, and here’s how that works (more or less).
With the mapping we managed to know which vertices are adjacent to each other. Basically the code finds the nearby vertices by selecting all other vertices that are sharing the same face, and then, by using the face’s normal, it deterines which vertex is over, under, left, or right. If the automatic mapping goes wrong, you can still select manually wich vertex is over, under, left, or right, and the code corrects itself.
Here’s a video of the code in action:



And, last but not least, we added bow and arrows.


Share on

Leave a Reply

Your email address will not be published. Required fields are marked *