for those who don't understand how a "very large positive number can certainly become a negative one", you may find it of interest to google a bit on "integer overflow".
It's been many a moon since i had to mess with this, so the following part may be off a "bit" (pun intended), but basically here is what is the situation:
On a (for example) 32 bit system, the maximum range of so-called "signed integers" lies between -2^31 + 1 and 2^31 - 1, or in other words, between -2,147,483,647 and 2,147,483,647. The way this works for a computer is that a "binary" representation (i.e. A large number consisting of only the digits 0 and 1) is stored and that the leftmost one (i.e. The so-called "most significant bit) is used as a so-called "sign bit": If the value of that bit is a 0, the rest of the bits are interpreted as a positive number, but if it's a 1, it's interpreted as a negative number.
An example (reduced to 4 bits, so as to not have to type 32 digits here), on a 4-bit system, using signed integers, the number 6 is represented as 0110 and the number 7 as 0111. Now, what happens if you add 1 to it, by trying to represent 8? Well, the binary representation of the number 8 is 1000, and computer systems (i.e. The hardware itself) can store that number too on a 4 bit system. But... The leftmost bit (i.e. The most significant one) is now interpreted as a "sign bit" (so as to be able to use negative numbers too), and now all of a sudden the binary number 1000 is no longer 8, but it is interpreted iirc as -0 (i.e. 0), or it is seen as a non valid number as 0000 is the proper representation for 0. Either way, when adding one more, the bit pattern becomes 1001, i.e. -1, add another one and the bit pattern becomes 1010, i.e. -2, etc.
The very same happens on 32 bit storage systems: When the number overflows, when using signed integers the number is interpreted as a negative number and hence when adding, the represented amount starts to go down.
When using so-called "unsigned integers" this is not the case. On a 32-bit unsigned integer system, the representable (and "storable") numbers range from 0 to 2^32 -1, or iow from 0 - 4,294,967,295.
If you try to add 1 more to that number you may run into trouble, as matters depend on how the system handles it.
To illustrate this again using a 4-bit system, but signed this time. The maximum representable number now is 15 (i.e. 2^4 -1), which in binary representation is 1111. If you want to add one, for representing 16, you're one bit short as the binary representation for 16 is 10000, but your device can only (physically!) hold 4 bits, so it overflows. Often, in such situations only the last 4 bits are kept, and you'd find your number then all of a sudden to be set to 0000 (binary) which is 0 in the normal decimal notation.
There are various ways in computer science to handle these overflow issues, i shall not go into that, but i thought that perhaps people would be completely puzzled by just why a "very large" positive number can all of a sudden become a negative one.
one thing that i don't understand though is why it would happen on a habitat. I can see how this can happen to the total amount of accumulated coins, but not on a habitat, which holds much smaller numbers. It must then be related to the total sum of all coins + the ones in all habitats or so?!?
Anyway, these are some of the fun "challenges" to solve in computer science from time to time, though i must say that nowadays with 32 and 64 bit systems it's been a long time ago since i've ran into such overflow issues.