Kido system recap

We have created a simple system to handled ranged attacks (kido attacks), which in its simplicity is a list of possible ranged attacks that we can scroll though.
By functionality, it is implemented and works just fine. UI however is a bit of a hurdle, as the selected kido on the server side has to be returned to the client and then rendered.
We still need to expand the selection of kido attacks, but there has been sparse time to focus on that task.

Melee system

A fighting game without melee combat wouldn't be very interesting. We want to make the experience fun and challenging, with room for diversity and counter attacks.
To accomplish that, we have been inspired by other bleach games, and fighting games like Metal Gear Rising: Revengeance

We want to make the it possible to make different combos, so the melee part of the game isn't the same repetitive action (well unless you make it so).
The idea is that a left click will perform a sword swing and a right click will perform reiatsu related attacks.
The reiatsu attacks can be slightly ranged, but it will vanish after a short range. It is neither as strong as a kido attack and opposite a kido attack, a reiatsu attack can be blocked. Reiatsu attacks will also consume a small bit of reiatsu.

This diagram made by Roei gives an example of a possible combo tree.
M is a sword attack (left click) and R is a reiatsu attack (right click).
The number after the letter illustrate the number of times the M or R attack has been pressed.
0 is a dead end, and returns you to the root.
(Notice a typo in the middle of the tree: [Root -> M1 -> R2], should be [Root -> M1 -> R1])

Each character will have a combo tree. We expect to do some QA testing to ballance the trees to each others, and to ensure diversity, which could make some generally unfavorable combos good in certain situations.

Available Jobs

Coding
While we are 2 M.Sc students who can code this work by ourselves, we don't have a lot of time to cover the work.
Out goal is to implement a basic functionality which is playable by January, and then revisit our milestones to decide what we do next.
In worst case, it means that we could end up abandoning some of the "nice to have" features if we aren't satisfied with the system by then.

Hence we would give the opportunity to other programmers to joins us in creating a bleach TPS-mod for the PC market.
BZSmod has always been about learning and working with a project that can be realized.
We don't expect you to have a B.Sc degree. Only that you have some experience with c++ and are willing to work with pointers.
So if you want to add something to your portfolio, train and perhaps learn more about programming, or you just feel like aiding us a hand. Then take a look here: Moddb.com

Animation
As our implementation progress, our animator could also use a hand.
There is no specific job ad on moddb at the moment, but if you are interested, then you can take a look here: Bzsmod.com
Some of the work is already done, but you can be the one who will be creating some of the combo moves, taking BZSmod to a new level of awesomeness.

We were able to conclude that client prediction did make attacks seem more smooth, compared to attacks without. As such we will have to incorporate that with the kido attacks.

Thanks to Joshua Riches for dedicating his time to test this.

Test details:
The test were conducted on a dedicated server, with one client on LAN (1 -5 ms ping) and one client on the Internet (~ 400 ms ping).

Test 1: no prediction
No errors was found in the usage of the weapon. The delay between animation and received damage was so short, that no delay was noted.
The predetermined delay between attacks was also confirmed by the internet client.

As such, omitting client prediction would not indicate any serious issues.

Test 2: Client prediction
As Test 1 there was no errors found during testing. However, the attack animation was considered to be more smooth on the internet client, with client prediction.

Test conclusion:
A large latency can cause a lower quality when client prediction is omitted. While this test covers a very large latency, the test does not include more than 2 players.
To provide the best game experience, and avoid possible unforeseen consequences, client prediction is the best solution.

Was able to resolve some minor setbacks and update the list of several issues.
While there aren't any signs that the client prediction has any effect while on a fast LAN, it might still have an impact on larger distances.

Hence a testing session between Joshua and I will have to be done before continuing with the melee system.
Meanwhile there will be some other bugs I can work on, even though I don't have much time before April.

While steam-cmd dosn't exactly help on linux by appending a relative path to an absolute path, it might be that the software center will install it slightly different.

Right now I got the windows hlds running, and it just reminded me that there is quite some tasks to be completed.

There is an annoying bug, that makes the character flicker when it rotates; I'm trying to deduce whether it is related to prediction or something else. Right now it seems that it isn't about the prediction.

It is however, also important to decide whether there is need for weapon prediction or not. We already know that using the global timer on the server to set the delay between attacks works, but we don't know if there are any consequences of using client prediction vs. not using it.

Keeping it all on the server could result in players with lag or slow computers, has the same experience as those without. It could also result in less ability to cheat. (clearly we haven't tested that)

But client prediction could allow optimization, that provides a more smooth experience, even if there is lag. But this do also open up for possible abuse, such as speed hacks.

However, I will not concern myself about cheating. If the prediction of the weapons has any significant impact, then we will use it.

My semester project is beginning to take form, and i'm yet again way behind on my reading schedule... (wonder why) - It is possible that the upcoming weeks will have less progress.

I changed linux to the 3.0r6 woody (linux 2.2 kernel) which isn't fully supported by VirtualBox... After the longest installation process in my entire life (including windows 3.1), Lack of x11 drivers, lack of support for smb, recursive sftp, numb scp , an ignorant lftp AND incompatibility with dos2unix converter... I took the dos2unix converting to the windows platform, compressed the result to an .iso so it could be mounted as cdrom (at least there was support for that) and BAM Linux 2.2 and GCC 2.95 does it job without standard library issues.

Today a huge update was made. I wont go into all the details, as that could take up to an hour to write, but overall it looks something like this:

Several bugfixes has been done, removing 2 crashes and resolving a sound bug in one of the kido attacks.

The melee system now get the animation from the combo tree. Correct progression though the combo tree still needs to be implemented.

Added 3 animations to demonstrate WIP progress in the melee system.

A few issues were also found and it will take some time to deal with them. HL uses a event system, which i'm still unfamiliar with. This system might handle some prediction for the client, and in such case it might also handle delay between attacks.
The issues lies in, that the code which originate from the SDK adds a delay to a time, which either is the server time or 0. The definitions (also standard in the sdk) chooses this to be 0 and this in result causes no delay, as the server time is far ahead.

The current workaround is to enforce the use of adding the delay to the server time. This works for the host, but we need to make sure that it doesn't provide problems during actual multiplayer. If it does, then we will have to handle this, before we can look at synchronization between attacks and animations.

Joshua have also uploaded his latest version of "the fifth tower" map.
We will add some graphics soon.

To follow up on the last question. It is most likely possible that we are reducing the amount of features, which we want to implement, as some of them aren't trivial. In that case, it is reasonable to consider us at least 60% done.

Right now our focus lies in implementation of the melee attack, which needs to get the info from a player's combo tree. At the same time, we need to sync between attacks and animation, so the attack happens around the middle of the animation.

This is currently a part which we will have to work out with the animator.

Recently I recorded a very very early implementation of the melee "system", if you can call a forced animation and close ranged attack that...
It will probably be uploaded soon, but for the sake of consistency of future videos, you will have to wait till we agreed on it in the team.

It will be easier to tell after our general meeting.Perhaps 40% or 60%.

We might be reducing some features, as the effective work being done, doesn't cover the needs to fulfil everything with a satisfied quality.

Right now we can only cover 2 kido attacks (perhaps 3) with many unimplemented animations. We sorted out how to handle the animations, which would be rather fast to implement by now, but it would not provide the full picture of our progress.

Joshua and I once talked about making a teaser, which briefly would show off the ichigo and grimmjow model, and a kido attack. But we are aware that this is not really what are being requested of us.

Earlier we had some trouble with animations being WIP and the developer requesting to retain these from public view. While Angel have made the grimmjow model and done a great work with the animations. We need to check up on the animations on the ichigo character.

While I'm not a fan of the request to retain work, I still find it important to acknowledge the view of the developers and ensure their credits are due.

I might be able to bring some more details the 16.th February. I will follow up on this question; if you don't see an answer by that time, then feel free to bump the comment section.