4 ms·

Because the players need to plug into the game engine in real time.

cperciva 17y ago
What's wrong with forking off a process to handle the AI?
viraptor 17y ago
Text interfaces over std{in,out} are a "good thing" - especially for sandboxing and on-demand connecting/disconnecting. They also protect you from people trying to manipulate the game server.
- rottencupcakes 17y ago
  The thing is that we would want to run the competition in a controlled environment on a local machine, and somehow enforce computation limits per turn. If anyone has good ways of doing this across programming languages/across machines, please let me know, but something like 6.370's approach (fixed number of bytecodes per turn) seems like the most reasonable and fair.
  - scott_s 17y ago
    If you try to control too much, you'll make the task harder. Just use a hard timeout. Rounds are X seconds or milliseconds.
  - nanotone 17y ago
    Disclaimer: I was a Director of 6.370 for four years, so I think I have a decent understanding of your requirements and the motivations behind them. As you mentioned, using bytecodes to measure computation time is a good approach since it results in deterministic gameplay -- and that's one of the reasons 6.370 stuck with Java for so long. A nice corollary to this approach is that if you can instrument the contestants' bytecodes, you can easily run your game engine alongside contestant code in the same VM, which is a pretty clean and fast architecture. And of course that still allows for JIT compilation if you really care about speed. As for the programming language, I'd cast a vote for Python, since it shouldn't be too hard to instrument [I've never tried] and contestants will be happier coding in a more productive language. If you want to keep Java around, I believe Jython compiles Python source to Java bytecode, under the hood. Java contestants would have a home turf advantage, but perhaps the Python language is worth it? I don't know anything off the top of my head about compiling Java source to Python bytecode, but I imagine that situation would put Java at a heavy disadvantage. Of course, any bytecode will work, so if you're considering going multi-lingual an obvious suggestion would be the .NET CIL which nets you all languages in the .NET framework. But my impression, at least from my time at MIT, is that contestants would be less happy with .NET. You could also just instrument machine code. Piece of cake right?
numix 17y ago
I host a similar competition at my university. We offer client binding for C++, Java, and Python. We have a C core that provides the game engine, and use code generation to generate the language specific APIs.
- numix 17y ago
  Here's the source we used for code generation this semester. http://github.com/joshbohde/megaminer-framework/tree/megaminer4/codegen/ http://github.com/joshbohde/megaminer-framework/tree/megamin... We used templates to create the game stuff. Unfortunately, it's not quite a stand-alone library, but hopefully someone else can use it.

What's wrong with forking off a process to handle the AI?

Text interfaces over std{in,out} are a "good thing" - especially for sandboxing and on-demand connecting/disconnecting. They also protect you from people trying to manipulate the game server.

rottencupcakes 17y ago
The thing is that we would want to run the competition in a controlled environment on a local machine, and somehow enforce computation limits per turn. If anyone has good ways of doing this across programming languages/across machines, please let me know, but something like 6.370's approach (fixed number of bytecodes per turn) seems like the most reasonable and fair.
- scott_s 17y ago
  If you try to control too much, you'll make the task harder. Just use a hard timeout. Rounds are X seconds or milliseconds.
- nanotone 17y ago
  Disclaimer: I was a Director of 6.370 for four years, so I think I have a decent understanding of your requirements and the motivations behind them. As you mentioned, using bytecodes to measure computation time is a good approach since it results in deterministic gameplay -- and that's one of the reasons 6.370 stuck with Java for so long. A nice corollary to this approach is that if you can instrument the contestants' bytecodes, you can easily run your game engine alongside contestant code in the same VM, which is a pretty clean and fast architecture. And of course that still allows for JIT compilation if you really care about speed. As for the programming language, I'd cast a vote for Python, since it shouldn't be too hard to instrument [I've never tried] and contestants will be happier coding in a more productive language. If you want to keep Java around, I believe Jython compiles Python source to Java bytecode, under the hood. Java contestants would have a home turf advantage, but perhaps the Python language is worth it? I don't know anything off the top of my head about compiling Java source to Python bytecode, but I imagine that situation would put Java at a heavy disadvantage. Of course, any bytecode will work, so if you're considering going multi-lingual an obvious suggestion would be the .NET CIL which nets you all languages in the .NET framework. But my impression, at least from my time at MIT, is that contestants would be less happy with .NET. You could also just instrument machine code. Piece of cake right?

numix 17y ago

I host a similar competition at my university. We offer client binding for C++, Java, and Python. We have a C core that provides the game engine, and use code generation to generate the language specific APIs.

numix 17y ago
Here's the source we used for code generation this semester. http://github.com/joshbohde/megaminer-framework/tree/megaminer4/codegen/ http://github.com/joshbohde/megaminer-framework/tree/megamin... We used templates to create the game stuff. Unfortunately, it's not quite a stand-alone library, but hopefully someone else can use it.