First of all I don't understand what an Servlet screen is?
I suspect you have an applet loaded in a page which is generated by a servlet, and are using methods to read the HTML page from the applet (or similar) and not realising that the applet can simply send arbitrary commands / requests direct to the servlet, and the servlet can distinguish these from web-browsers and send back arbitrary data...
If your using servlets to distribute information to the other players applets, there is another more prefered way to do this, but it requires acces to the web server.
No need for this - you can upload arbitrary information to a servlet already. Just make the servlet accept POST, and make the servlet have a URL where requests get a list of all the data that's come in from the other applets.
Of course, I would suggest breaking up all these different aspects into unique servlets, since it would make it less confusing to edit...
it is easy for a user to use a sniffer and see what information it send and write it's own program to cheat. To aviod this there are numerous hash and cryptographically way to enforce a more secure communication. ...Then a possible cheater must get a hold of the private key which should be very time consuming.
Not at all - you just made the first mistake of security: assuming that the cracker/cheater will simply attempt the hardest possible way of breaking the security. No, only a foolish or naive cracker would do that. Instead, most go for the weakest link...
Give me five minutes and a page with your applet on, and I'll have decompiled the java code and probably have whichever key(s) I need. The time-consuming bit is going to be remembering the name of a decompiler which does de-obfuscation (if you haven't obfuscated, I don't NEED that part, but it can make up for any bad coding conventions you're using by assigning more meaningful names to some of the methods, variables, etc - so that I can read your source more easily), and then reading through your source code to find whatever secrets I need.