I had a good bit of fun looking at the packets going from / coming to me to from casino / game provider. I'm not sure what detail I can post that is not already known TBH but, for the purposes of what I set out to do, I do think it's possible to simulate a game provider's server at this stage but it would take some time to interpret the SpinResponses and Javascript and, even then, you would need to have 'collected' enough of the game code to supply your client (e.g. The 'Hidden Treasure' featurette below requests a .JS download - presumably if the game client cannot see it cached)
<SpinResult symInView=“8,1,0|6,2,7|3,2,4|6,3,8|2,3,7” overlayInView=“9,9,9|9,9,9|9,9,9|9,9,9|-1,-1,-1”>
<GameSpecificData>
<SpinModifier index=“2” name=“HiddenTreasure” otherPicks=“0,1” />
</GameSpecificData>
(This was also a red skull feature - hence four reels being wilded - shame I was only playing 40p.)
A lot of the data is loaded up before the GUI gives you control (backgrounds, banners, reel symbols, .OGG sound file) so the game would be playable but it would take some time to get the full set of code...... even then, there are probably dynamic parameters from the server based on goodness knows what as well as any logic based on provider<>casino conversations which we cannot see. (Session Keep-Alive ??)
Plus, you will have to self-sign the provider's domain. I would hope that the game client will only talk to a valid, certified provider URL.
In summary - fun to look at the back-end code and trying to work out what relates to what but the original concept would be very difficult and time-consuming to implement but, at this stage, not an impossibility.
I'll probably revisit when I get severely bored but it was a brief stab into a game that I really enjoy playing. I will state that I did not attempt to do any server-side activities here - before I raise any concerns from the industry.
Ade