Hello and Καλήν ἡμέραν ("kalín iméran") to this week's devlog for Olympunch!

This past week has been incredibly hectic for programmers and artists alike, but we're happy to present our progress! Let's take a look at how the game scene is looking!

Would you look at that! The game's come to life! We've implemented many of the artistic assets previously produced, as well as created several additional assets, such as the UI icons and new arena pillars, which proved to be useful and an enjoyable addition during a playtesting event.

Character

This week, we finished the character. It underwent a lot of design changes during the week, which improved readability and visibility. For performance reasons, we kept the textures very low in resolution. This does not show at all during the gameplay and the characters still look fantastic!

Here depicted is the red version only. But we do have a blue version aswell for the second player! But aside from the raw model and texture work, we also spiced up the character by introducing: Particles! That's right, we gave the characters a little trail on the bottom and nice fire hair!

The Arena

The major part of this week, however, was dedicated to the arena. Yes, the old arena looked like a prototype. But we completely revamped it and overhauled the whole battlescene! There are still adjustments to be made to the surrounding environment, but for now we are able to  show you the arena! Gaze upon it! Be dazzled!

As you can see, it looks fantastic! But jokes aside, by overhauling the arena, we also looked into possibilities to change up the gameplay a little bit. And thus, we introduced the large pillars on the outside. These sometimes prevent the players to be knocked out instantly, and rather get another chance of survival.

As you can see, the design is simple, but adds a lot of flavor to the whole scene. It's like a meal. By seasoning it, you make it a lot better! And this is exactly what happened here. 

Now venturing into the programmatic section of this devlog, we took into account player feedback after a playtesting session and made some changes. 

HUD and UI

This week, we made significant improvements to the UI to optimize costs. As a result, we had to remove the sprite sheet for the opening of the scroll. However, we have devised a plan to enhance the scroll menus by resizing the paper of the scroll, ensuring there will still be an opening animation.

Our artists have created new HUD icons that are specifically designed to fit on a 1920x1080 resolution screen. In addition, we have implemented progress bar functionalities for all icons, enabling players to track the cooldown periods after throwing a punch, or dashing away, and a visualizer of when the hook ability is in use.

To accurately represent the player's punching strength, we have refined the logic governing the speed bar's progress bar. This involved introducing two extra progress bars to show the different punch states.

Unfortunately, while implementing the complete HUD, we encountered some challenges during the build process. Despite these setbacks, we are working on resolving the issues and ensuring the HUD functions smoothly not only within the Unreal Engine editor but also in the final game build.

Particle Implementation

Next, we directed our efforts toward particle implementation. To accomplish this, we developed a blueprint that effectively monitors the player's state and registers the usage of specific abilities.

However, similar to the issue encountered with the HUD, we have encountered a problem with the communication between the blueprints and the underlying C++ code. As a result, the blueprint responsible for spawning particles cannot currently be utilized in a build. 

Audio Implementation

Furthermore, we created a blueprint for implementing sound effects. This blueprint can already play the punching sound when a player is hit. Although due to the persisting issues with the HUD and particle implementation, we have not yet integrated this blueprint into the build. 

Cable Component Addition

The first thing we had in the list for the order of works on the programming side was to add the cable component into our scene. Or, to be more precise, to make it visible. Unfortunately, in the beginning we did not know there was a difference between the two. We were aware that something was in fact in the scene. We knew that because the cable was somehow casting a shadow, even though it was not visible.

We tried multiple things to make it visible: we tested it in a build, with different physics materials, with different materials, materials with different properties. Nothing seemed to work. 

For this reason, we jumped out of C++ and started debugging in the blueprint. Afterall, it did work during the prototype phase in the blueprint. We wanted to be sure it was attached at the correct objects and locations. We attached the cable component to two spheres, one at each end… and voila!! They appeared. Not only that, they appeared and moved as the cable should. But the cable was nowhere to be seen. We kept on playing with the values, anything we thought that it might somehow have an impact on the cable. Lost and without knowing what to do, we continued to try to change values that we believe to have 99.9% chance to not have anything to do with the cable. We changed the size of the spheres to be really big, and that's where we noticed something strange. where the camera direction would overlap with the cable and the sphere, we could see a tiny bit of cable. We extended this hypothesis. We substituted the whole arena for a simple plane that used the same material as the sphere. And there it was, the cable. The cable had always existed in the scene (hence the shadows) but it was never visible because it was not rendered. A call with the material artist was set up to help debug this error. We discovered that every material in the game derives from a master material (meaning that this problem would propagate downwards). To fix it all, we had to fix the master material. After a long and tedious effort of trial and error, we came to the conclusion that setting the mater material to double sided and making the cable material emissive (which was our intention from the start) would fix this error.

Finally, the logic was converted back to C++. Unfortunately it was not all smooth as we would like. Some of the logic (visible to non visible) was left out in the blueprint as it functioned better and made the overall game more pleasing to the eye.

Hook Animation and class

Although mostly done, we felt the need to now fully incorporate this class with the arena bp and have the map generate randomly the hook locations.

Unfortunately, there were more important tasks for this week, so we were not able to fully implement it just yet.

Nonetheless, the animation, and how it interacts with the player is now 100% operational

Sound Manager

Found new errors with this class and we were able to fix them. However, the sound still does not play.

Build Crashes/Player State

During various tests related to build crashes debugging we came to the conclusion that it was related to the PlayerState class. It was initially believed that that crash was the result of a float pointer variable that was implemented to make the code simpler to use and cleaner to read. For that reason, we simply turned off the class for the time being.

This weekend, we picked it up once again in hopes of fixing this error. However, the crashes now were not happening during play, but rather at the very start of the program. There was another class messing it up (more on that later).

When that was fixed, we were back at the player state. We removed the float pointer variable and worked around by having a couple of set and get functions to overcome this change. And yet, the program still crashed during runtime.

We still do not know what was causing it, but we found a solution for it. We sacrificed an organized class for a crashless game. Instead of having a play state class, we migrated the code from there to the player character. This is what we had initially done in the prototype phase. It works, it does not look bad as we feared, but also it is not as cleaned as we hoped.

Failed Punch

Just like initially set up in the prototype, the player now has an incentive to not punch “left and right” and be smart about his decisions. A failed punch will automatically push him back to stage 0.

Punch Power/Player Speed Correlation

Also, as initially intended, the player will not be able to win the game by “camping” and waiting for the opponent to come to him. That will result in a punch with a total power of ZERO! We want a fast passing, entertaining and fun game. We want you to rotate, so you can speed higher and therefore punch with a stronger force and kick your friend out of the Olympus. It is too small for two gods!!

Multiplayer Input Fixed

We can proudly say that the issue has finally been fixed! We had a suspicion that there was a problem with assigning the controllers. It appeared that the first controller was being skipped during the prosessing stage for the players. As it turns out, we had forgotten to enable a setting called "skip assigning gamePad to player 1." We spent many hours investigating this, so it goes without saying that it's always important to check for basic problems that could occur. This being our first time developing in Unreal Engine using C++, it's a lesson we'll remember and carry forward to future projects.

Barrier

It was suggested not to implement this feature considering the limited time remaining. However, we strongly believed that it should still be included in the game. The feature consists of a barrier that bounces the player when collided with, but when the player gets punched, they will fall through the barrier. Although it still requires some polishing, the basic implementation has been completed.

we reflect on the journey we've embarked on during the development of this project. We've encountered challenges, made decisions, and put in countless hours of hard work to bring our vision to life. While there were suggestions to omit certain features due to time constraints, we've chosen to persevere and include them because we believe they add value to the game. As we approach the finish line, we're committed to giving our utmost effort to polish every aspect of the game, ensuring an immersive and enjoyable experience for our players. The team is excited to see our project come together and eagerly awaits the moment we can share it with the world. Let's make this last weeks count and deliver something we can be truly proud of. Onward to the final stages!