none
Weapon progress in UE4

Two weeks ago I promised to make a new blog post regarding the state of the weapon in UE4. The original post van be found here. Ideally I wanted to write this sooner, but I got a little busy with life, hence the small delay.

Either way, let's talk weapons. As said in the previous post, everything had to be build from the ground up, and this includes the weapon. Before you can actually implement cool weapon functionality, you need to have an actual weapon. And thus, the first thing we did was spawning an empty weapon actor and gave it to the player. It had no functionality other than looking fancy.

[video width="640" height="400" webm="http://supraball.net/wp-content/uploads/2015/05/2015-05-31-1551-17.webm"][/video]

Next thing up was to allow the weapon to hold the ball. For that we had to implement the player bubble, which is the yellow sphere that you see around a player when he or she is carrying the ball. Upon touch, the ball should get passed on to the player, who passes it on into the ball. This extra detour is for programming reasons of which I will not go into.

[video width="640" height="400" webm="http://supraball.net/wp-content/uploads/2015/05/2015-05-31-1555-54.webm"][/video]

Now that the weapon had a ball, it seemed trivial to implement a dump shot. Even a simple thing as a dump shot required a fair amount of work in order for it to function correctly on both clients and server in multiplayer. You can read more about that in my other post here. In the picture below, you can see me performing a simple dump shot without any problem.

[video width="640" height="400" webm="http://supraball.net/wp-content/uploads/2015/05/2015-05-31-1556-17.webm"][/video]

However, under certain conditions when we move forward and perform a dump shot, we'd immediately catch the ball. This is because after releasing the ball, it would collide with the player's bubble, indicating a pickup. This is still an unsolved problem in UE4. It might look easy to fix at first glance, but in reality most of these 'easy fixes' are ugly hacks and cause unwanted side-effects, which only come up after implementing given fix.

One of the reason this is hard in UE4 and solved in UDK, is because UDK doesn't use continuous collision detection, but performs raw comparison between the new and last position of the ball manually. The way it's implemented in UDK causes weird edge cases where the ball might go through the player, even with the shield up. For UE4 we've wanted to fix this by using the physics engine for collision detection, but this has some downsides as well. It's not as easy as it looks!

Either way, after implementing a dump shot, it sounded logical to implement a charge shot.

[video width="640" height="400" webm="http://supraball.net/wp-content/uploads/2015/05/2015-05-31-1556-34.webm"][/video]

And now we had a charge shot, we could implement overcharging!

[video width="640" height="400" webm="http://supraball.net/wp-content/uploads/2015/05/2015-05-31-1611-05.webm"][/video]

One might think that the next step would be adding spin; but remember that kicking also makes use of the spin. Therefore, it was a better choice to implement kicking first. Kicking has a lot of subtleties that are not immediatly visible. The speed of the ball after kicking does not only depend on the kick power, but also the movement of the player. And what should happen if two users kick the same ball at the same time? What if the two kickers are from the same team? Then there's the issue of lag, and how long should the kick be active? If we're kicking, should we be able to pull the ball at the same time? How can we make it so that you can kick both player and ball at the same time in a nice way such that the code doesn't become a mess?

[video width="640" height="400" webm="http://supraball.net/wp-content/uploads/2015/05/2015-05-31-1556-51.webm"][/video]

I'd say, kicking was one of the hardest thing to implement because of the wide variety of use cases and circumstances. Pulling on the other hand, was a lot easier. Not because there are less edge cases and variety of circumstances, but because we could re-use most of the solutions used by the kicking mechanic. You could almost see pulling as the opposite of kicking, although not entirely.

[video width="640" height="400" webm="http://supraball.net/wp-content/uploads/2015/05/2015-05-31-1557-17.webm"][/video]

With kicking in place, we could now properly implement spinning of the ball. This however, turned out to be a real pain in the donkey. Not because of the math involved, or code design, but because of the parameters used for the physics engine. As discussed previously, we could not just copy over the values from UDK. We had to completely re-tweak those values, on what is a totally different physics engine and behaves quite differently in comparison the the version used in UDK. We've tried our best to match the experience of UDK, but I'm afraid that this will be a lose-lose situation; it's very hard to get it a 100% perfect, and people will most likely complain about it. Sadly, there's not much that we can do about it, except tweak it some more.

[video width="640" height="400" webm="http://supraball.net/wp-content/uploads/2015/05/2015-05-31-1558-15.webm"][/video]

Now, there were only two things remaining: deflecting (shield) & sucking. Because sucking sort of depends on the shield, because of it's bouncy nature, it was only logical to first implement the deflecting. Aside from the fact that there's no shield visible yet, the deflection wasn't too difficult. Most of the math had to be redone however, but it seemed to work out nicely.

[video width="640" height="400" webm="http://supraball.net/wp-content/uploads/2015/05/2015-05-31-1557-36.webm"][/video]

Finally, with the deflector implemented, the last thing remaining was the sucker. Just as with the spin however, it was very hard to get the right parameters in comparison to the UDK version.

[video width="640" height="400" webm="http://supraball.net/wp-content/uploads/2015/05/2015-05-31-1557-57.webm"][/video]

As you can see, the core mechanics of the weapon (and thus also the game) are nearing completion. What remains is polish and some nice visualization. For example, we're having some difficulties with attaching various effects to the weapon model, which in turn is attached to the player. For example, the weapon's kick effect make it look like the weapon is not rotated, while in reality the player is looking upwards. The bulk of the logic is there, but all those tiny, minor details are what really make the game.