For example, in my situation I know
hash(20) = 486e9638177faf1f34e49910491b77af.
I also know the hashes for all values from 0 to 20.
Is it possible to work out the algorithm used to hash these values?
In practice, maybe, if you got additional information, such as that the hash function is known to conform to some published standard (you just don't know which).
Theoretically, though, for any finite list of values, there is always more than one bounded algorithm that generates the list. You can never be absolutely sure you figured out the correct algorithm.
A hash function is not supposed to provide this kind of security: if you have access to some message $m$ and $H(m)$, you can compute $h(m)$ yourself for a given hash function $h$ and check if they match. So, if you really have hash outputs, you can test the usual suspects MD4, MD5, SHA-1, SHA-2, RIPEMD and a few others depending on the hash length. If it's a custom design you will not find it, but that's security by obscurity which is outside the security model we generally use in crypto.
However, if it is a MAC, then it's expected to be impossible to recover the MAC key.
Your first assumption is assuming this is a hash digest value at all. It might be a block of data encrypted with AES-128 and a secret key. (I suppose finding the digest value in association with a name like PREFS_SUPERPOWERS_COUNT_HASH would be more of a giveaway that it is indeed the product of a hash.)
One way to attack this would be to dump the binary of the application, looking for symbol names or external library links that might indicate what hash algorithm was used.
You have provided only one other clue so far, and that is it's a 16 byte (128 bit) value. MD5 yields a 128 bit digest, while SHA-1 has a 160 bit digest, and other variants of SHA have larger digests, so MD5 would be my first guess as it's one of the most common hash algorithms. But there are plenty of other hash algorithms that have 128 bit digests, so it's not a certainty.
I would caution though that if it is being used as an anti-cheat mechanism in a context like an iPhone app, it probably is not a simple hash of the value "20". They likely salted their hash by prefixing or postfixing their value of "20" with extra secret data, like "20@ABC-123@2013-04-22T22:40:00@YourRegistrationCode". At least I would do something like that if I were coding an iPhone app and I was trying to stop people from copying the monetary purchase of coins.
If this is just an attempt to circumvent a payment, I'd recommend purchasing the coins through legitimate channels and not to deprive the company of their revenue stream. If you like playing Cut The Rope, pay for it.