Update #23: Rescaling the project and Getsuga Tenshou news

Since the last time, we have been posting videos rather than articles. The most recent video ( Moddb.com ), 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: Moddb.com

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.

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.

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.

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:

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~