ok we misunderstood : there is no language related dependancy.
The only feature to implement is the ability to share stdin and stdout between server and client. Stdin/stdout are simply redirected onto sockets. That it.
In facts, I found a hidden constraint. Redirect in/out is a standard application for sockets but the codinGame HTML 5 player looks not synchronous. It looks like playing only battles that are already finished and stored with stderr messages… No calculation during the playing process, just messages stored with game instructions…
So it appears that a debug session would be blind with current html players (GoD & PR) but i may be wrong…
If html5 player can play a streamed battle, , there wont be any concept problem, but if (as i guess) player can only play battles entirely stored in RAM data structures, the debug session would not see graphical result on screen.
Nevertheless, i’m kinda sure that such a debug capability would dramatically improve the concept “big picture”. Giving participants a way of running their program on their own machine, debug and profile it with their usual tools.
On the other hand , html5 player synchronicity is the point that i cannot evaluate impact on implementation complexity.
Only codinGame html5 managers could really evaluate it.
I will take a look on your server…