In this week’s development blog (it’s been a loooong week), we talk about paradoxes and why they suck!
Merriam-Webster defines a paradox as: an argument that apparently derives self-contradictory conclusions by valid deduction from acceptable premises.
Comic has been provided through the courtesy of the very talented Zach from SMBC whom we love <3
For instance, if I made the proclamation that:
“This sentence is false.”
then you might find yourself caught in an interesting logical loop…
‘This sentence is false’, is false which:
Which leads me to this week’s conclusion: Why computers and paradoxes don’t mix.
provided courtesy SMBC
Computers are amazing at computing (amazingly enough). One of their largest strengths is the ability to answer questions over and over and over… as many times as you ask them to.
Loops are amazing! Without them, video games (and the world!!) would be much different. But you just don’t want to have them loop forever (unless that is something you intentionally plan for). Actually programs crash, hang, lag, and do all manner of bad things if you don’t keep ‘paradoxes’ (and similar ‘infinite questions with no correct answer’) in mind while programming.
While programming, paradoxes (or better put: multi-threading race conditions, infinite loops/unintentional spinning, etc.) can and are intentionally avoided at (nearly) all times, especially while making loops. Programmers take a great amount of effort to go out of their way to over-plan for possible paradoxes and infinite loops…
Sidenote for programmers:
While this does work…
while( i != 0 ){ i -= 1; }
It is not nearly as good as…
while( i > 0 ){ i -= 1; }
This is because, if for any number of reasons (by another programmers hands, the hardware, or by magic itself), if “i” skips past 0, the loop will never end, and unless you have a means of dealing with that, that’s not a good thing. In 99.999% of cases this is generally impossible for such a problem to occur, and the countdown WILL be sequential, but you eventually will find that .001% oddball right when you least expect it (especially when working on a team and someone ‘helps’ by i–’ing something inside the loop to solve some other issue). And better still, the second way is just as readable (arguably moreso) and as functional as the former… so there is literally no good reason not to write it that way…
The programmers of the world can mostly agree on this (through necessity), so this is usually not a problem, and usually goes unsaid.
provided courtesy SMBC
However, CURE is so robust with its item system, that it gives players (many of which are not seasoned programmers) the ability to… well… cause ‘logical loops’ to form. Some loops are welcome additions that make the game that much more interesting,… however, players using that power CAN create some pretty gnarly paradoxes that can cause the game to either crash or create results which are… ‘unexpected’.
For instance, let’s say you had three genes (the ‘items’ that are in CURE, that one uses to upgrade their units), and you added them to your unit in this order:
▷This is gene 1 and adds +1 Health and turns off gene 2
▷This is gene 2 and adds +1 Potency and turns off gene 3
▷This is gene 3 and adds +1 Speed and turns off gene 1
So… if you have those three genes on your unit… which stat is modified (Health, Potency, or Speed)?
There are a half dozen ways to go about ‘trying’ to solve this issue… And some that work better than others…
provided courtesy SMBC
But the best conclusions we came to is:
Don’t allow for paradoxes to exist!
Genes which are placed in such a way that is ‘logically impossible’, are not saved and that issue must be fixed before the genes can be applied and saved.
The main benefit is it allows us to have our cake and eat it too— we can have amazingly complex and intricate genes, with the safety of not having infinite loops or contradictions that result in less fun while playing.
