Bugs, shackling girls and simplifying mechanics

Hello guys, it's your programmer, Cardinal, and today I'll talk a bit more about the code refactor that is going on.

Since this is more code-oriented, it's fine for you to skip it, since it is purely informational :)

So, some players were having an interesting bug related to the Slaver Master. If he shackled a girl when the other two were incapacitated, the game would softlock. That is because I didn't factor in the possibility of a turn starting with no girls able to be selected without triggering a game over. My bad.

We put a quick fix for that, where Brad would not use this skill if there were less than two available girls:

As you can see, I just created a number equal zero and for each incapacitated girl, the number would go up by one. the number being less than or equal to one means no girls were incapacitated, or just one was.

It's a dirty fix, but it worked. The main reason for the code refactor is that there are hundreds, if not thousands of these dirty fixes all around, so the more we expand, the more bugs the game will have, and they will be harder to fix too, so better now than later.

So another thing related to the shackled is the fact that when a girl is shackled, the game does not really recognizes that this girl is unavailable, it just looks like it. I'll show you what I mean:

In the code above, we can see the process for determining if a girl is selectable or not. As you can see, the shackled condition is there, with another one, "incapacitaded" (yep, I misspeled the variable). This other variable relates to the sex resistance or stamina being depleted.

At the end you can see that the method that starts the turn (PlayerTurns) is called.

But the sprites for the shackled girls never turn grey, and sometimes it still breaks. That's why I said that the game does not consider the shackled condition as making the girl unavailable. Here's why:

This relates to the change of the sprites to grey. The game does not look to the shackled condition to determine this. That is bad!

Let's look now to my first attempt at fixing this:

Now I make the change of colors in the same place that decides whether the girl can be selected or not. The "CheckIfGirlCanBeSelected" takes into consideration the stamina, sex resistance and the shackle condition. 

I also created three boolean variables, to decide if a girl can be chosen or not, and if a girl can be selected, her sprites will be of normal color and the turn will not pass automatically. But if none of the girls can be selected, their sprites will turn grey and the turn will pass.

That is an improvement, but we can do better. If every time a girl can be selected, her sprites will be of normal color, and every time she cannot be selected, her sprites will be grey, why not use the sprites itself as the condition? So that led me to the following piece of code:

It does exactly the same as the previous one, but is a lot more succinct, has less variables, and achieves the same as before. It is less computationally expensive, but it may not be as easy to read as before, but most of the time that's the price to pay.

I used a ternary operator to reduce the 12 lines long check to one that only uses one line. It's pretty neat.

Anyways, this post is getting very long and more complicated than what I'd like, but I hope that if you are still reading it, that you enjoyed looking how the game works more closely.

Until next time!