Programming

Hello world! We're back with our weekly update so let's get straight into it.

Camera

Alex here! For my part, as I mentioned last week, I began work on the camera, because our static camera was getting a little boring, and it was a little too zoomed out. Here is my result:

How it works? It's pretty simple. There is an invisible sphere which is the camera's root, a spring arm and the camera component.

The sphere moves left and right to always be in the average location of all tracked players. The zoom works by finding the players that are furthest from each other, and then getting their distance from the sphere. Then it clamps the value between a min and max zoom and ta-da.

But this keeps tracking the players. Right now, when a player dies we move him off the screen to avoid doing malloc's every time the player respawns. Memory is expensive! So all you need to do it when the player dies, remove him from the tracked players I mentioned above and add him back in at respawn. But there's an issue! When the player respawns, if he's too far away the camera will snap back at him, which doesn't appear smooth. So using some interpolation and capping the camera's move and zoom speed this is what I got:

This will work for now, you can still get fancier with it but we're pushed for time and I'd like to sleep at some point...

Digging

Following up on my promises from last week I also worked on the digging, you know one of the core mechanics of the game which we left until the very end of sprint 1...

This part caused me a lot of headaches and trouble. The reason is because we want this interaction to happen by holding down the interaction key but in the future, the cannons should be interacted with a press. 2 types of interactions with 1 key was something tricky for me to get down, and while we only have those two events I don't see that as an excuse for a poorly designed system. So I found some middle ground and make an okay system that handles the different types of events. And I ended up with this:

Coming up with a nice system to handle this, as well as communicating between the animation instance, the player controller, the player and the digging spot while avoiding coupling took some thinking, and a lot of re-writing. Right now the player class could use some clean-up but that's for another day (as is everything). I hoped to have gotten the treasure to spawn from the digging this week but it took a few hours longer than I had hoped. The system however is functioning nicely so it should be quite easy to spawn the treasure when the digging is full.

Water level

Hi! Donan here. In this week I worked on two features, the first being the rising tides of the ocean. For this I used the gamestate to keep a timer that instructs the water level to rise at certain intervals. The water then rises if possible and moves the ships up with it. The water level has an array of different height values. These can be set in the blueprint. These values are what determines the different sea levels at each stage. When the final stage is reached the sea level will stop rising and the game will end. This last part we still need to implement. 

Another part to this mechanic is that the player will drown when going too deep in the water, for this we simply check the difference in Z value between the character and the water level with a small offset.

Lightning event

The second part I did this week was the lightning event. For this I used the timers in the gamestate again. The event starts when the water level reaches its middle stage. Then the island mesh will generate points where the lightning can possibly strike. Then with a linetrace the highest possible point of the map above those points will be calculated, so that if a rock is above the point on the island mesh the final calculated point will be on top of the rock mesh. Then we check which points are above the sea level and we strike some lightning on them. The lightning has a small delay and indicator before it actually strikes. If the player stands too close to the strike they will die.

Audio

Hey there, hope everyone had a good week.

This last week has been filled with a lot of work but sadly I have nothing to really show you guys. The last week has been spent on the audio cues when you hit someone with a weapon. 

Other than that I have been dabbling in the thunderstorm sfx, both the ominous rumbling and the lighting strikes themselves. 

The remainder of the time has been spent on some boring 'paperwork' on perforce. Hopefully I can show you guys some more in the coming couple of weeks.

Take care, Xander.

Art

Hiya, welcome back to this weeks art part of the devlog. This was the final week of sprint 1, meaning next week sprint 2 starts. So little time, and so much to do. So let's immediately get into it!

Hello, Joshua here, This week I've been a little bit busy coming up with a new layout for the level, and I have also been doing work on the lightning RFX for the lightning event. I'll start out talking about the level design sketches.

After play testing the level I've noticed a couple of issues like how cramp the level is and how difficult it is to traverse the terrain. We got some feedback that the level could be more playable if there was a straight path that goes directly to the opponents ship.

the blue and red arrows is how the pathing will mainly go. In the process of I've also started thinking about shapes for the islands like a shark or a crab with a massive arm. There after I went along with the 4th sketch and translated it into 3d so I can get a feel on the height variation.

I also got some feedback on the island layout from Jay and added a bit more land in the front. I felt that would make sense since its mainly viewed from the angle presented in the sketch so the priority is mainly on the front part of the island. the blockout was made in Maya, it was a bit more faster than sketching out the height, that way I'm also avoiding perspective issue when I add more props to my sketch.

Lightning RFX

Next up is the lightning particle, the main goal for the lightning is to anticipate the strike so the player has enough time to avoid getting hit. So for that I made a pulsating ring on the area of impact.

After the pulsating ring ends the lightning strikes in the middle of the ring. Here's how the lightning looks.

that's the whole basis for the lightning effect, the only thing left is to add extra effects like adding more particles on the impact. Here's the final result for the lightning particle system. 

The particle system also includes some parameters that changes various attributes like the pulsating ring radius or the time before impact. For the shockwave effect i used material that refracts a circle shape.

That's all for me, its not much but, next week we'll start our 2nd sprint so you can expect a bunch more from me! for now you can read what Jay made, featuring some more shaders!.

Hey everyone, Jay here. This week I took a look at the optimization of the water shader, the creation of a burn effect shader and made a model for the cannon.

During prototyping Joshua had already made a great water shader. While it looked great there were a few area's that could be optimized/expanded upon, namely: the amount of parameters, the textures that were used and the obvious tiling that was happening.

I started by first cleaning up the shader graph and deleted nodes that weren't really used and restructured the shader. After that I considered each parameter to see if it would be usefull to us or not, having full artistic control is always nice but having a shader with 20+ parameters is a bit of a choice overload. After that I took a look at the texture we were using to drive displacement an reflections. I made some new noise texture for displacement and to reduce the amount of tiling I made 3 normal maps overlayed on top of eachother each with a different scale and speed. I'm happy to report the shader is now a bit more usable and visually still looks the same.

I then moved onto the burn effect shader. This shader will be used for stuff like the player spawning/dying, the 'x' appearing/disappearing etc. For this task I decided on making a material function for it so it can be used for a wide range of assets and can be combined with an existing material rather than overriding it.

I started out with creating a gradient going from top to bottom, that gradient then gets combined with a tile texture which we use for most of our assets. I then created a paramter for the burn amount which subtracts from the gradient texture to create a scrolling effect. I do some extra stuff and color the edges using a Curve Atlas in Unreal, which allows us to create a gradient consisting of many colors rather than lerping between just two colors. The material function also outputs a mask which can be used as a transparency mask, and a normal map which combines the user provided normal map with a paper normal map around the burning edges.

To close the week of I made some models. I started with a cannon model which will be put on the ships. If you remember from a few weeks back I did a small breakdown of the modeling process for the rock modules. The workflow I used for the cannon is largely the same, so not much new to show you on that front. I will instead leave you with a screenshot of the models in game. 

As always, some of the models are not yet textured, this will be handled first thing next week so be sure to check-in with us again next week! Have a lovely rest of your week :)