For the GBA and DS but applies to most thingshttp://www.romhacking.net/forum/index.php/topic,14708.0.html
I rarely see encrypted text outside of the PC. A ROM might be encrypted but that usually means something else, and PSP isos might have been as well but that is not a problem in the modern world (we have all the keys, including public and private thanks to Sony's major screw ups with the PS3).
Most games won't practice anything like safe handling of decrypted data either and have it all in plain text in RAM (also goes for compression). A RAM dump of a script is usually not so useful for end users (usually incomplete, hard to use as a hacker) but can be a step along the way or narrow your search down if you are facing compression (or maybe encryption).
Compression is common, especially in text.https://ece.uwaterloo.ca/~ece611/LempelZiv.pdf
while nominally about LZ family compressions is my usual choice for an overview of compression, though maybe also grab some source code handling any BIOS, SDK or otherwise known compressions seen in games to get another idea. Step through at least a few steps of it manually and it usually starts to make sense.
I assume you have the basic idea of an encoding. English/European languages might get away with 8 bit encodings as there are usually less than 100 characters but Japanese thanks to the thousands of kanji tends to go for 16, and in some odd cases even 24).
While most PC things use known encodings console game devs seem to have a proud tradition of not doing that. By the time of the PSP that had changed a bit so yeah check to see if there are a whole bunch of 16 bit values starting with 8 or 9 (most common characters in shiftJIS http://www.rikai.com/library/kanjitables/kanji_codes.sjis.shtml
) or whatever you feel necessary for http://www.rikai.com/library/kanjitables/kanji_codes.euc.shtml
English has the defined alphabet order, Japanese has no official order or even much of an unofficial one (though depending upon how much Japanese you know you might still spot common ones that are taught to tests, schools, said same but back in the day when either the game was made or devs likely came up, somewhat logical like having *kuten next to their respectives or in the same order afterwards) or copied from other orders (same as shiftJIS but starting at ?? being seen on multiple occasions).
On the flip side there can be game based orders like most/least common, first in script (though it might be first in beta script). Commonality is also a trick I like to use (RSTLNE in guess the word games, scrabble scores, space is probably the most common, the vast majority of all words in English have a vowel or a known alternative like y) but you are on your own for Japanese beyond see what the split is like between the kana (some don't do many loanwords) and/or kanji to bias your tests.
Said order can help in various ways, relative search https://www.romhacking.net/utilities/513/
being my tool of choice. For English then most encodings will be ABCDE....XYZ so if you search for a sentence (careful with capitals, variables and new lines) from the game then as the chances of a matching patten (CAB could be a pattern 0-2+1 between them) are generally slim and usually immediately noticeable by reading characters a few either side with the pattern. Some like to overwrite Japanese fonts with a known user chosen order (be it alphabet or numbers) and search for the gibberish (but still alphabet/numbers) that the game displays, though it works less well as Japanese encodings often have gaps for various reasons.
Having a little poke at the code to see what happens in the resulting game is also quite valid as a thing to do, though best if you narrow it down a bit first and maybe have an idea about what the encoding will look like (you can start randomly tweaking things, it is a process known as corruption, but it can take a while to get useful results). Indeed it can often be the best way to figure out random characters that the game does not use, or commonly use.
There are also things like DTE/MTE where a character is split across a few tiles and thus can be made up from a few values. Around now I should probably note old school half width stuff but that is mostly a PC affair.
Modern games also often resemble a markup language as well, or can have variables. Sometimes these will be binary, sometimes textual, sometimes both. Both of these things can throw some methods off. Oh and 8 bit markup in text can be found in Japanese games which can frustrate decoders as things will pop in and out of 16 bit alignment.
You can also trace back through things from being displayed on screen to where they land in the ROM/ISO if you are so inclined. Most of the above stuff is based on lived experience and works well for a lot of things.
I am basically rewriting documents written by myself and others, usually far more clearly with nice pictures and examples, so I will tie it off there for now.
Short version. Known encodings are great, certainly check and see if the game uses them, but it is far from the whole story. You might want to grab a relative search tool, and make sure your hex editor has nice options like distribution of characters. Other than that is it mostly a combo of linguistic techniques, brute force, code analysis and maybe actually just taking it from the top and working backwards to find the origin via the code itself.