Nie znam Shakes And Fidget - ale jak przeglądarkowa gra to w sumie bywa prosto.
Albo podglądasz komunikację w chromie lub firebug.
Albo stawiasz sobie proxy server na komputerze i podsłuchujesz (np. Fiddler).
Potem piszesz bota np. korzystając z HttpClient gdzie robisz
- parsowanie jsonów/ htmli itp.
- walkę z prostackimi zabezpieczeniami (np. http headery typu referer, ale wszystko da się sprawdzić metoda prób i błędów).
(ja to robiłem tak, że jeśli nie dostawałem poprawnej odpowiedzi z serwera to analizowałem gdzie moja komunikacja się różni od tej z przeglądarki ,
każdy szczegół (headery głównie), ale czasy nadawania też mogą być brane pod uwagę (np. nie wysyłamy żądań częściej niż raz na sekundę itp.)
Gorzej z Captcha (chyba, że jest kiepsko zrobione - ale to też do przejścia: https://deepmlblog.wordpress.com/2016/01/03/how-to-break-a-captcha-system/).
JavaEE jest do tego absolutnie zbędne, a nawet bardzo przeszkodzi.
Wiele zależy od specyfiki gry - kilkanaście lat temu napisałem mega prymitywnego bota do gry przeglądarkowej (Starkingdoms). Parsowanie html robiłem
metodą html.substring(html.indexOf("<div class='player'"), ....)
(O rany... sam z tego się śmiałem)
Przetrwał kilka lat i kilka zmian szaty graficznej gry (drobne zmiany w HTML dawało się, mimo durnoty kodu, szybko dopasować).
Zwykle jest to łatwe bo autorzy gry poświęcają raczej czas na implementowanie ficzerów, a nie walkę z botami, szyfrowanie komunikacji, obfuskację.
(Bo i tak nie mogą w 100% botów powstrzymać ).