This commemorates server-side Overworld emulation. I achieved this using vanilla javascript, and vanilla node.js. I am not constraining myself to any architecture, javascript will serve merely as the discrete execution layer of any Overworld game, for the time being. Simple economics dictate the workload of games to execute should be proportional to their value, but there are any number of improvements to make on my pipeline. This just describes a working prototype I am very happy with.
I have already invested in my scripting language of choice, obfuscating key codes paths. For details, see my earlier post:
http://redasteroidgames.com/?p=499
That got me feeling like less of an amateur putting my code in the wild. The next step was running node.js server-side, to verify client submitted games. Setting up node.js was straightforward, scripts can be easily added to the node.js daemon “pm2”. They can be run on the command line to capture STDERR directly.
Next I wrote some node.js to replace an earlier PHP script, which took client-submitted games and inserted them in the database. “newscore.php” became “newscore.js”. I did this without any idea how long full support of the engine would take (two months), but doing so got me familiar with node.js, and got some important libraries installed. To streamline operations I disabled cross site scripting detection.
Next I catted the output of my javascript obfuscator onto the end of my new score receiver. I spoofed the parent domain object “window”, used to declare externs for export from the engine. The node.js environment does not provision this web-based novelty. I stopped part of the code from trying to bind to the document object model (some game engine cleanup needed there). I fixed all the missing vars that node.js cares about.
I started encoding all game inputs (that successfully impact game state), and passing them on new score submission, along with a pro mode flag (pro mode starts at level 2). I had the server code try to emulate the client-submitted game and validate checksums.
I then noticed huge discrepancies between client and server output, along the lines of pseudorandom number generation. To make the game fully deterministic, I:
- Made a prng server, taking seeds and giving out number sets.
- Standardized consumption and use of in-engine prng.
- Cleaned out external prng consumption by the graphics engine.
I also had to eliminate other sources of low-level indeterminism:
- Open-ended data sorting
- Iterations like for .. in
- High precision operations
My biggest impediment was not being used to debugging on node.js. I basically did all by hand in the console, working with seeds and execution paths that were problematic. I procrastinated on setting up my pipeline, so was manually juggling files for a few nights.
One problem I now experience is that the deploy pipeline is so memory-intensive that the mysql daemon shuts down, poor Battle Mines. I think I’ll have to refurbish the devbox at some point, maybe separate out concerns. 😉
In other news, check out OGBM! The old-schooliest of the Battle Mines games, now hosted by an old afficionado! http://ogbm.pw
Permalink