Hello everyone, it's time for the monthly Dev-Blog

Update 0.9.1

Let's start with the main focus of today's Devblog, Update 0.9.1! This update is turning out to be much larger than I expected, not necessarily in terms of content, but in terms of how much work was done for a "medium" sized update. The biggest change made during this month for this update was the complete rework of how collision works.

Collision Rework

While thinking about how to improve performance with the Pike (known to be a very performance-heavy weapon), I ended up reworking the entire collision detection system I'm using. As you may or may not know, Rogue: Genesia is a 3D game, with 95% of the logic handled in a 2D manner (you don't care about a projectile going over or under enemies) with only a few exceptions using the up axis (like worm gland projectiles, for example). However, due to many factors, I was using the 3D physics of Unity, mainly because the game is in 3D, and it's much easier to handle it. But having the game use 2D physics would definitely unlock much more performance. However, the first issue is that there's no easy way to use 2D physics when the whole game is happening in 3D. The first issue is that the game's logic mainly happens on the X/Z axis (Y is used for up), but 2D physics only works on the X/Y axis.
(each circle is a proxy used for collisions) The only way I found to achieve this was by creating invisible "proxies" for every object in the game that requires collision (projectiles, player, enemies, trees, interactable elements...) and updating their positions in real-time on this 2D physics plane. However, it was far from perfect. First, moving an object in 3D, then replicating the movement in 2D, then having collisions displace the 2D object, and finally replicating it in 3D would have been a messy adventure. I also considered using 2D physics for projectiles, enemies, and players, but it quickly became apparent that this would lead to a very messy implementation. In the end, I had to modify many parts of the game to have the displacement logic handled directly by the 2D proxies and only move the 3D objects based on the 2D proxy's position. This was a very time-consuming process, with potentially hundreds of places in the game code that had to be adjusted to move 3D objects this way. Another major issue I encountered was that the performance was somehow much worse than when using 3D physics. After hours of debugging and investigation, I discovered that, unlike 3D physics, Unity's 2D physics didn't handle direct transformations of objects' transforms very well. So, once again, I had to modify many parts of the logic to set or add velocity to the 2D rigid body of the proxies instead of directly displacing them. This, of course, came with its own set of bugs to fix. In the end, after debugging all these situations and enabling multi-threading (which wasn't possible with 3D physics) and setting the physics update to be on the Update loop (instead of FixedUpdate) After some benchmarking in extreme scenarios, I achieved a significant performance gain in collision processing, from 2x to 4x better. Using the same scenario as in https://steamcommunity.com/games/2067920/announcements/detail/3669925177420091529, I went from an average of 60ms of processing for physics to 17ms of processing.
(old 3D physic)
(new 2D physic) (In those examples, even the average frame time saw a massive improvement, going from 5 FPS to 10/12 FPS.) I don't believe there's much more I can do in terms of optimization now. Laggy situations primarily arise from there being too much happening, and there is no "magic solution" to further improve performance without making direct changes to the behavior of things (such as adding a soft cap on projectile count or introducing global cooldowns with larger effects) or basically remaking the game from scratch going for an ECS approach.

Weapon Stats Rework

Another aspect that consumed a significant amount of my time was the modification of how weapon stats were handled. Until now, weapon stats were represented as numerical values that were modified as the weapon leveled up. However, this approach was impractical, especially when I wanted to introduce temporary changes (for instance, a weapon modifier altering a weapon's attack speed). The best solution was to make weapon stats function in the same way as the player's stats: set default values upon weapon initialization, modify the base stats upon leveling up, and easily permit the addition or removal of modifiers. Nonetheless, making this replacement resulted in over 1000 errors that needed to be fixed. These were relatively simple errors to correct, such as changing "Damage = 10" to "Damage.SetBaseValue(10)" or "Damage += 3" to "Damage.AddBaseValue(3." $ Still, I had to manually update each of these 1000+ lines of code one by one, which was a time-consuming process (it took me approximately 2 days of repetitive line replacement to fix). However, this change opens up the possibility for much more flexibility in weapon behaviors. This newfound flexibility was almost immediately harnessed in one of the new weapon evolution introduced in the next update, where a "siege" mode is activated when the player is immobile, granting the weapon (and only this weapon) improved stats.

Weapons

Speaking of weapons, adding a new weapon is always a difficult decision. When adding a new weapon, I have to consider many factors, and this becomes increasingly complex as the game gains more content and weapons. First, I want to avoid weapon to overlap each other too much, which is a bit of an issues with Spear/Bow/Crossbow, they still serve different purpose, so it's fine, but they are very similar in their behaviour and how to use them. Secondly, I need to think ahead about how the weapon will look, ensuring it doesn't turn out ugly, as happened with the Pike when it was initially added to the game. Thirdly, performance is a concern. I must be careful about how the weapon scales, as some super cool ideas might quickly overload any computer when there are more than 30 of them (again Pike was a major Lag source for bit of time due how it worked). Finally, adding a new weapon that isn't an evolution means I have to think of proper talents linked to it. These talents should align with the weapon's theme and can sometime prove difficult to be made. These factors are the reasons I don't add many weapons to the game. I take time to refine a weapon idea for several days before implementing it in the game, and then test if the idea actually works within the game. Implementing a new weapon typically takes 4 to 12 hours of work, depending on how many new things I have to program into the game. Update 0.9.1 will introduce one brand new weapon, as well as four weapon evolutions. I've teased some of them on Twitter and they are already available in the beta branch of 0.9.1 (same code as usual). Here are some screenshots:

Balance and gathering feedback

This part is a bit off-topic about update 0.9.1, but I think this is an important point that I wanted to approach during one Dev-blog Another difficult factor about weapons is their balance. I'm not an advocate of perfect balance, especially in a single-player (or coop) game; this often comes at the price of fun. But I still understand the importance of having a certain balance and playing with compromises. Crossbows and throwing knives may be the most powerful weapons in the game, but they have important negative points so they don't become the go-to weapon for all situations. There are also some weapons that are often underrated, like the Worm Gland. In the end, it's still hard to balance weapons; most of my intel on what weapons are strong or not mostly comes from the Discord. However, I also know they are mainly veterans of the game and may not represent the average players. In addition, I often see players on the Steam forum complaining about X or Y weapon. While it's interesting information, it often comes without a deeper analysis of their strengths or weaknesses. So it's a bit hard to know if it's a proper issue, especially when in the same post, three other people say the absolute opposite. I am always open to balancing suggestions (not just limited to weapons), but I want to have more than one or two people speaking about how they feel about X or Y. Either a deeper analysis of the issues (which some veteran players often do on the Discord, and this is very precious information and feedback to properly balance the appointed feedback) or a large mass of players agreeing with the feedback (which I then know it's time to put serious time into analyzing the issues players may encounter in deeper detail and understand the origin of the complaint). As a player, you also don't have to worry about reposting some balance issues that you still encounter many versions later. I often do a lot of minor balancing all around, and sometimes a balancing change I made in one version gets reverted by something else in the game. An example of something that could happen:

• Players complaining about Health Transmutation not being strong enough at Version X,
• I buff it in version Y, so it's fine
• Now many months later at version Z, I nerf the Max Health gain all around the game, and players who wanted to complain about Health Transmutation not being strong enough see the post that is many months old and simply think there is no point in reporting it again or that the issue has persisted for many months when, in fact, it just got accidentally reintroduced. It takes a lot of time before I notice this important change.

The same goes for suggestions. I receive a lot of suggestions, and sometimes I like to revisit suggestions when I want to focus on adding new content. I also try to gauge how important some suggestions may be based on how many players agree with a suggestion, and it helps me prioritize some things.

What is missing for 0.9.1 ?

The main limiting factor for the release of the update remains the same: the animations for the new snow-themed enemies. This was further delayed due to some misunderstandings between the animator and me, which effectively postponed the entire process by one month. I still believe that this delay provided me with a valuable opportunity to focus on many things I wouldn't have had time for or would have been scheduled for update 0.10. Once 0.9.1 is ready and published, I'll shift my focus to Update 0.10, which should ironically be quicker for me to develop than 0.9.1, even though there's a substantial amount of work due to the new region added with 0.10.

A few other things

I've noticed some players expressing concerns in the comments of the previous dev-blog that I might abandon Rogue: Genesia. I want to reassure you that I won't abandon Rogue: Genesia and will continue to develop it until 1.0. My loss of motivation is simply preventing me from maintaining my previous pace of working 10-15 hours a day continuously, which has led to a slowdown in the game's overall progress. However, this just means that it will take an additional 1-2 months for the game to reach 1.0 compared to my original estimate.