Computers store integers as binary, and when the code in question doesn't need to use negative numbers, a programmer might use a so-called "unsigned" integer. That is, it has no positive or negative sign. It's just a number, like 10 or 7777. They are stored as ones and zeros, and the largest number an integer can store is based on how many binary digits it has.

For instance, an 8-bit unsigned integer has... eight bits. So 00000000 is the number zero, and 11111111 is the number 255. So there are a total of 256 numbers you can express with an 8-bit unsigned integer: 0 through 255.

Every string of binary ones in number is one less than a power 2. So the OC was noticing that your number is very near a power of two: 2^31^ , minus another power of of two: 2^8^ .

Now, computers are both smart and dumb, and often don't care what you do with numbers since it's sometimes useful to do weird things with them. So if you take the 8-bit unsigned zero (00000000) and subtract 1 from it, you can't get negative 1 because there is no such thing as -1 for such an unsigned binary number. Instead it "overflows" and loops around to 11111111, and now the value is 255. This is a very common bug (and exploit) in all sorts of games when yoy can trick the game into subtracting 1 from 0 and now you have 255 Diamong Rings or whatever.

Now, your number is very close to 2,147,483,647, which is the maximum value for a signed 32-bit integer. In fact, your value is that number minus 256, which is a strange coincidence, since 256 is also a power of 2.

How exactly a signed integer in the game achieved something near its maximum value is unclear. It's not as simple as subtracting 1 from 0 because in a signed integer, that would simply be -1, but programming languages do have easy ways of accessing that number like long.MaxValue or something. (long is many programming language's name for a 32-bit signed integer.) But why that was in the code at all or how that value got used for the effect is very odd.