Can I use asymmetric encryption for more powerful write-protection? I have a game that I am developing which uses a locally-stored internal database. It does not matter to me whether a user can read the file (which, to me, means I don't need a symmetric cipher), but I don't want it to be possible for a user to alter it without completely breaking the game (essentially, to make cheating more difficult). Obviously file permissions alone wouldn't protect against someone on an administrator account or with a rooted device.

My thought was to use an asymmetric cipher where, opposite how it usually goes, the decryption key is public and the encryption key is private. I would then distribute the already-encrypted database and the game could decrypt it. I believe that this would prevent alterations, because the user would have to be able to properly re-encrypt the altered file for the game to be able to read it (unless they also altered the game binaries), which they wouldn't be able to do.

However, I've done a bit of searching and I can't seem to find this method mentioned anywhere, so I don't know if it is a good idea or if I've overlooked something. Is this a good approach?

Also, I want to use SQLite. I know of SQLCipher, but that uses AES so obviously that wouldn't work for me (because it's symmetric and therefore the user could intercept the encryption key by obtaining the key which is used to decrypt). Are there any public-key SQLite encryption libraries?
What you describe is a digital signature, which works using methods very similar to the one you suggest. Examples include elgamal-signature and RSA signature schemes (the second of which I would recommend you read).

Digital signatures allow you to provide a public signature that 'proves' you provided the message. As the author, you would produce database $m$ and a signature $s=s(m)$ confirming it is what you wanted.  You then provide your program with an algorithm $V$, called a verifier.  The verifier tests whether $s$ is a valid signature for $m$. If the signing algorithm was deterministic, an example verifier could just recompute the signature.

As with all crypto code, be wary of implementing a signing algorithm yourself, since there are lots of subtle pitfalls you may hit, such as the RSA homomorphic property.