Olympunch: Week 06

Olympunch: Week 06

Hello! – or rather, “Χαίρετε” (“khairete”) everyone! That’s Ancient Greek for hello 😉

This week we have quite a lot to report and to show, primarily development progress as well as things that will help during our development to streamline the workflow.

Tileable Textures

This week revolved a lot around texturing and material upsetting. We’d like to show off three different tileable textures we have made: Mountain Rock, Grass and Stone Tiles.

The grass texture has the blocky, stylized shapes we figured out during our artstyle exploration. The texture was purely made in Substance Painter and its limited capabilities in procedural texturing, which was more than enough for this task.

The stone tile texture however was made using ZBrush. The base models were made and Sculpted and then baked onto a single plane in Substance Painter. In Substance, we made the Basecolor, Roughness and Normal Map Texturing, giving it the nice stoney finish and maintaining the stylized feel.

The mountain rock texture used a very similar workflow, only that the Normal Map information is a single stamp in Zbrush, which made the Sculpting pass very short. Most of the stylization of the Texture therefore lies in the Basecolor and Roughness Information.

Master Materials

We introduced master materials from where we can instance future textures. The master materials are user friendly and adaptable to multiple cases. For now, we have two Master Materials: One for Tileable Textures and another for Decals. 

As you can see, there are a lot of Parameters that can be edited to fit the Texture as needed. The example shown here is the Material for the Tileable Textures. The Master for decals is a little bit more complex, but all in all should amount to the same.

Environment and Modular ArchitectureIn addition to textures and materials, this week we’ve also made significant strides on our environment and its assets. We’ve completely modeled and unwrapped our modular architecture pieces. They’re ready to go, and we’ll be spicing up our scene with them in the coming week.

Furthermore, the mountain base has been added. We’re going to be playing around with materials in the coming week to find a material that truely suits the vibe. Separate placeable ledges were made to give the modular architecture platforms on the mountain to sit on. The architecture and environment is made with the fact that this is a slanted top-down game in mind.

Pillar Layout

We also made more progress on the “level layout”, meaning the procedural placement of the pillars on top of the arena.

The number of pillars that are placed on the arena can be chosen by the user with a parameter. With the help of some loops, the blueprint will try to then place the wanted amount of pillars. To avoid infinite loops, we made the blueprints so that if a loop has happened a certain amount of times, the amount of pillars that will be placed is subtracted by one.

As can be seen in the video below, if the user wants 1-5 pillars on the arena, the placement will be very fast. However, when trying to place 6 or more pillars, there is a big chance for the swing radius of the pillars to overlap. Because of this the placement of the pillars can take a long time. 

For the game we want the players to be able to choose how many pillars are placed, but because a bigger amount of pillars will take too long to load, we will take into consideration that we might have to limit the number of pillars.

Because the blueprint for the pillars is placed on the procedurally generated coordinates, the pillars will automatically activate and deactivate throughout the game. This is shown in the gif below.

Particles

For the particles this week, we decided to focus on the ones that will appear when a player gets ready to punch the other player.

The strength of the player's punch will be dependent on how much speed they have gathered by swinging around the pillars. We want to show the difference in strength in the particle system.

The softest punch the player can use, when they haven’t gathered any extra speed:

Next is the punch strength for when the player is at <50% speed:

Then the punch strength for when the player is at >50% speed:

And lastly the punch strength shown when the player is at max speed:

The build up of the particle system nicely shows how strong the punch of the player will be. In the gif below, you can nicely see the difference between the punch particle systems.

RayCast

Our RayCast functionality is working! 

Visually it works better than in our prototype since it previously casted rays-specific intervals. However, the end points of the rays were not being calculated correctly. With the new update, now the rays are created correctly.

Better even. Now the raycast stops when it hits a hook, and only a hook.

A red line is used to represent the path of the cablecomponent.h mesh.

Regarding Cable components, a lot of this week's work has been spent on research of the cable component. The Cable Component, although available through blueprints, is not available in Code. A plethora of forums read, discord channels scrolled, and questions later, we found the issue:

The cable component does not exist in UE5. We tried multiple things, including adding the CableComponent.h to Engine/Source/Runtime/Engine/Classes/Components but it did not solve the problem. We will be testing out with a spline component to see what results we can get.

Finally, rotation around hooks is working as intended.

Punch Mechanic

This week we tried implementing the punch mechanic in c++. There definitely were some challenges here but somehow we did manage to implement it correctly. However we'll be going over the code more to make sure we’re taking full advantage of the system we're using to make our player character. The punch retracts once it has hit an object and adds an impulse to that object in the direction of the aim arrow.

We also want to mention that we fixed the movement and Arrow components to move accordingly. Added a cooldown to the dash, merged this mechanic with that of our co-developers to create a coherent player character.

More things have been worked on, developed, or researched. For instance the design of the code and approach used was now implemented and the previous files re-coded. Avoided circular dependency ect.

That’s all for this week, folks! Thanks for tuning in.