You don't specify your encryption method. To show you why that is important, I'm going to pick a really bad one. Let's say we use a stream cipher to encrypt. "stone" and "paper" have the same length, so we are good there, but "scissors" is longer. So, if Alice chooses "scissors", Bob can see the ciphertext length and know what she picked and choose "stone". Therefore, if Alice chooses "scissors", Bob always wins.
If you pick your encryption method so that the ciphertext lengths are always the same, this attack is mitigated.
Bob, once he knows whether or not he wins, could refuse to send $R_B$.
The major flaw, however, is, even if you pick a really good encryption method (say AES-CBC with a fixed length size), you are doing nothing for integrity checking when integrity is really the primary concern here.
The proper way to do this would be to have Alice and Bob each publish a commitment to their choice. Then they open the commitment publicly. This could be done, for example, with HMAC. Choose a random key $k$ and publish $HMAC(k,m)$ where $m$ is the choice. Once both have done this, they can each publish $m,k$. That way they can verify that the choice hasn't changed.
A -> B : **A**,R_A
? (actually I'm not sure I got the entire notation right, so please add a note explaining that) Also take a look at commitment schemes. $\endgroup$