Bleach:Zanpakutou Senshi is a totally free Total Conversation of Half-Life 1. It´s based on the japanese hit Anime Bleach.

RSS Update #23: Rescaling the project and Getsuga Tenshou

Our progress over the last year have resulted in some good features, but it has been necessary to evaluate what we are aiming for and how long it will take to get there. We present a redefined design document and course , based on our experience and feedback from the users. Instead of having the vision in mind we look towards the goal of the first release instead. We also present some new content we are working on.

Posted by on

Since the last time, we have been posting videos rather than articles. The most recent video ( ), with humor in mind, shows how far we have gotten with the melee system. Since then we have improved the dummy, applied an push effect to one of the combo finishers, and also implemented blocking as well as parry.

There is still a lot to be done with the melee system. Many of you have suggested us to increase the speed, and the last video was a result of trying to accommodate for such changes. There are other combo finisher effects that has to be implemented - simple enough, but takes time to get it right. Finally it all needs polishing, and not to forget, the blocking and parry are just at its prototype stage.

Changes in the game design:

It takes a lot of time to implement even small features, especially when you are exhausted after a day of study or work. By November I was working close to 50 hours a week, due to engagement with my studies. - January mercifully gave 1 weekend and 1 day of vacation. That is an issue as coding is necessary to implement all the other work and in the right way too (see next section). With a full thesis and a course this spring, it would not be good to aim towards the ideas and visions we had included in the old game design. The game design is self-contained, that is that it also contains comments about what we changed since the last time and why we did as we did. To avoid repeating a lot of its content, i will simply encourage to read the document:

By late November we decided that we would proceed towards melee and 1, or 2, ranged attacks for both Grimmjow and Ichigo. We agreed to change the Redfire attack into a Cero for Grimmjow. If time allows for it he will have a charged attack which we assume to be a beam Cero instead of a ball. Imagine a straight Kamehameha from ESF, but instead of exploding and removing the tail, the tail is dispersing over time and during that time the player continuously takes damage. As if the mean is actually a link of many small Cero attacks.
The idea is straight forward, and therefor we hope we can make it. But we first have to put the base attack into place and remove all the bugs with it.

For ichigo we agreed to make Getsuga Tenshou. It has its own difficulties in achieving the effects of making the model feel alive. NNK has inspired to a solution for that, and we are currently implementing a prototype (oh there goes my 1 day of vacation :P ).

Getsuga Tenshou prototype:

Or should i say, bloody collision system? Experimenting with implementing a model that has to have a precise collision detection or a bounding box all of sudden gives a different perspective to what an attack is, to what an entity is.

Understanding collisionboxes in HL

Usually we consider an attack to be a package of a model with some direction and some code to give damage. But like everything else it is an entity, with its core implementation being a location and an rotation.
The model itself is actually just cosmetics in a sense (it does have hitboxes after all); the collision is NOT calculated based on those hitboxes, they are calculated based on a bounding box aka collision box. And even though you define one in the qc file of the model, studiomdl might choose to simply ignore it.

Understanding collisionboxes in HL

We had to define the collision box by using UTIL_SetSize( vec_mins, vec_maxs); It can be a help to get those numbers from studiomdl itself by calling " this->ExtractBbox(0, mins, maxs);" - It seems as if it simply calculates the size of the model and return the vectors you need.

Understanding collisionboxes in HL

And then one should think it was all good and nice, but no. The size is in relation to the world and not its local reference. Meaning that shooting 90 degrees left or right results in this:

Understanding collisionboxes in HL

So hopefully we can simply rotate the collision box, but in case we can't we will have to start within the safe zone of the model. Meaning whatever angel it has, the box stays within the model.
But that would limit the collision to the center of the model and that is not what we want. Though some struggle we can resolve the issue, even if we can't rotate.

So an attack is an entity that has position, angel, collision box and a model - but it is also just an object.
So imagine that a main attack, holds the model, the code for exploding and then a set of sub-attacks
For all those sub attacks we are only concerned about their ability to collide, and when colliding they can inform the main attack to explode.

This resolves the issue because we can fill the model up with small squared boxes.
The diagonal of a square is calculated by sqrt(2)*a, where a is the length of the side. What is important is the result of the square root, 1.41~ . The smallest part of the model is the height of 4, hence the diagonal must not be larger than 4, otherwise 45 degrees angled attacks will make the collision box stick out of the model.
We can find the appropriate size for a collision box by reverse calculating the diagonal to one of the sides.
4/1.41 = 2.83~

Then we can place several 2.83 x 2.83 collision boxes in the model along its center line on the x axis. We could even place them to follow the shape of the model, creating even more immersion. This works, because the squared collision boxes are contained inside the model and we can calculate where to place them from the position and rotation of the main attack.

Edit: The numbers I used was for a square, but should have been for a cube. instead of 4/1.41 it should be 4/1.73 = 2.31~


Mmmm progress and updates are delicious. Anyway pretty amazing stuff you got going on hear i look forward to future updates.

Reply Good karma Bad karma+4 votes


Reply Good karma Bad karma+2 votes

nice update, thought I was following the mod already but I guess not

Reply Good karma Bad karma+1 vote

Damn IRL!
Anyway, good work! :)

Reply Good karma Bad karma+1 vote
eliasr AuthorSubscriber

I have been looking some more into the rotation of the collision box and to my knowleage at the moment it is not possible. I even rendered the collision box on the character simply to get an idea for it.

I think i will update the article or bring a new one with focus on how to resolve such an issue. Kept in mind that the solution is to make a good experience and not a perfect match - but as seen above the bounding box clearly isn't a suitable choice.

I can however verify that the attacks actually can collide with each other now, which is something we wanted to achieve. :D

Reply Good karma+2 votes
eliasr AuthorSubscriber

I will bring a new article that will conclude this topic. But in short.

The sub collision boxes inside the model is the best approach and the rotation issues we had with them has been resolved.

I'm not sure how technical I will make the article. In a sense it could be really well to put a proper detailed tutorial up on how to do it, like tutorials on - but it could become too complex and heavy of an article.

Maybe I will make a separate article that looks into how to resolve the issue code wise.

Reply Good karma+1 vote
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.

Follow Profile
Send Message
Release date
Mod watch
Related Games
Half-Life First Person Shooter
Related Groups