Since Marc-Andre has covered empty ifs, enums, and OO structure very thoroughly, I'll add a bit about style.
public class Game {String yesOrNo;Input inputClass = new Input();Computer comp = new Computer();Checking checker = new Checking();Score score = new Score();Scanner input = new Scanner(System.in); public void gameLoop() {
Since the rest of your indents seem good, I'm going to assume this is just down to Stack Exchange's kinda weird Markdown. However, since it seems like none of these are used outside of gameLoop, they should all be variables of gameLoop, not of Game. It doesn't matter too much in this case because Game only has one method, but in general we like to only give variables the scope they need (if you haven't come across variable scope, you can just ignore this until you do). Some of these names are strong (input is pretty standard, and score makes a lot of sense). Others could do with some work. yesOrNo, in particular, is used in two semantically different contexts: it is used both as "does the user want to see the score menu?" and as "does the user want to play again?". Separate these out into two variables, and suddenly their names can be specific: openScoreMenu and playAgain.
On spacing, I suggest adding more, or at the very least being consistent. People have different styles, and it doesn't make sense to say that others are invalid, but it is important to find a style that works well and stick to it. If you don't use spaces between the if and the (, then never use spaces between the if and the (. (Exception: when editing someone else's code, try to keep their style as much as possible.)
For example, here use use lots of whitespace:
if (pGesture == cGesture) { return TIE; } else if (pGesture == 1 && cGesture == 2) { return LOSE;
And here you use very little:
if(yesOrNo.equals("y")){ score.ScoreMenu();}else if(yesOrNo.equals("n")){
Personally, I like to use lots of whitespace in my Java, but I know some people like to use very little.
Finally, in Java it's very important to pay attention to capitalization. Sure, it'd be nice if the ScoreMenu method was OpenScoreMenu instead (general rule: make method names verbs, and object names nouns), but it's much better if it's scoreMenu. Methods and variables are always camelCase, class names are always NormalCaps, and constants are always ALLCAPS.
(also, one irrelevant point because I'm super pedantic: choice is spelled with two c's and no s's)