Dev Diary: Bugs, Explained! (Patreon)

Hi everyone, Anna here!

Today’s post is about something that represents a lot of our everyday “background” work on Paralives. Let’s talk about a hidden part of the game development iceberg: bugs! 🐛 Note that this Patreon post is for Patrons only so please don’t share it, thank you!

Let me reassure you right away: even if bugs might seem scary, they’re a normal part of the development process, especially at this stage, since we’re making core systems and adding features one by one. When we do our planning, whether it is for a two-weeks sprint or a year's worth of development, we always account for testing and debugging the features we will add during that time. When we add something to the code, even if we carefully think about it ahead (in the form of a design document), it is really hard (or should I say impossible) to have thought of every possible problem in advance and run it bug free the first time.

Bugs can be frustrating. Sometimes, supposed minor bugs take a lot of development time, but they can be satisfying to catch and fix too, like a puzzle! It makes me think a bit about being a physician looking for a diagnosis. Sometimes the symptoms you see are enough to make a diagnosis and start a successful treatment, but sometimes you might not have enough information and need to design the right exams to find the disease. Other times the treatment might actually cause more damage to the patient because of secondary effects and you have to also fix that or find another ! (It’s very common in programming that fixing one bug leads to more bugs…) In any case, the vast majority of our code usually doesn’t get sick, but curing the small portion of the ones who do can take a little while. (The metaphor is now over, sorry about that).

Some of you who are on the Ancient, Legend and Hero Tiers on our Patreon might have already had the chance to see some quite cursed snapshot of bugs or other oddities on our #developer-posts Discord channel. We also shared a few of the ones from our latest Paramaker focused marathon here.

Today, I wanted to share in-depth  explanations behind some more bugs we encountered recently, in collaboration with Alex and Jérémie.

Procedural Animation Bug

Marvin sprained his back by flushing the toilets… But he seems better now!

This bug happened while I was testing a procedural adaptation of the “Flush toilet” animation. As you may already know, the slider that enables players to customize their character’s height is quite a challenge animation wise. We need some little help from the code to adjust Alice’s animation for the character to reach the objects or Para they’re interacting with (if you want to know more about that, I wrote about it in my “week with a dev” thread that you can read here).

Marvin proceeding to flush the toilet without any side effects

As procedural adaptations are animation-specific (i.e. the code needed is different on a case-by-case basis, so reaching the flush on a toilet doesn't need the same adaptations as reaching the chair when sitting for example), the right ones have to be loaded every time the character plays a new animation. In that case, the part of the code that made the previous procedural adaptations disappear didn’t work! Before the bug in the first animated GIF above happened, Marvin was actually flushing the toilet, so his hands needed a little help to reach the correct position of the flush since he is taller than our average Para. However, this stayed activated afterwards when I ordered him to walk, but since there was no flush, he tried to reach a position at the origin of the character, on the floor!

Skin Texture Bug

No skin? No problem! (Some problems)

Jérémie here! This bug was due to the way we calculate which skin texture to use on a  character based on their fat and muscle sliders - if your Para is very fat or very muscular, their skin will have different lines and details. It was the kind of bug that is easy to pinpoint, but pretty tricky to fix. Because we have a bunch of different skins with specific rules, Étienne actually needed to create a small tool to visualize what texture was visible at specific values of fat/muscle.

The X-Axis is the muscle slider and the Y-Axis is the fat slider, all colors represent the different skin textures that can be used for your characters depending on the fat and muscle slider values. Thanks Étienne!

Using this, we could figure out that certain ranges weren’t covered by any of our skins and we tweaked our data to properly address that issue. There was a little bit of extra code to add, but this was mostly detective work 🕵️

Body Deformation Bug

When the music is so good that your body can’t handle it anymore.

Hi! Alex here to explain this bug. When a character is animated, in this case, playing the dance animation, every bone of its body is placed at a specific position, scale and rotation depending on the current play time of the animation. However, some bones are also moved, scaled or rotated depending on how the player customizes their character in the Paramaker. For instance, when you broaden the shoulders in the Paramaker, the shoulder bones are moved away from the body by a few centimeters:

Changing the shoulder’s width in the Paramaker offsets the shoulder bones.

At any given time, when playing an animation on a character, the animation system sets the position, scale and rotation of every bone but then, the system that changes the size of the different body parts applies an offset, like moving the shoulder bone a bit for instance. But if an animation stops playing for any reason and no other character animation takes it place, the shoulder bone offset will be applied at every moment, accumulating and becoming bigger and bigger. That’s why you can see Sebastian’s shoulder quickly moving away from his body in the bug! A similar thing happens to every other part of the body as well.

The solution to this bug is to make sure that under no circumstances a character should be left without playing an animation. Usually, after the character is done performing an interaction like dancing for instance, we play the standing idle animation so everything goes well!

Of course, before releasing in early access (more info on early access here!), the game will be thoroughly tested so that you players encounter as few bugs as possible when playing the game!

I hope you enjoyed today’s journey into the dark side of programming!

I hope you have a great weekend!

Cheers,

🌞🍹

Anna