The latest version of the framework, including all strategies for the past tournaments, is available on our git server:
git clone https://econgames.org/git/econgames-python
For example, to replay our first tournament, you can do
git clone https://econgames.org/git/econgames-python cd econgames-python git checkout tournament1 python play.py
Final scores will be printed and the whole history of the tournament will be output to
log.json in the latest version).
Individual strategies should be placed in their own folders inside
tournaments/tournament_name/ directory. The best way to start is to copy the first example strategy to a new folder and modify it to your liking. You can enable or disable the participation of individual strategies by changing
active variable in the respective files.
Single Language Option
I suggest we begin with a single language, which most sensibly should be Python: it is the most popular scripting language and it also starts to gain popularity among economists (thanks to scipy). Excellent documentation and simple syntax make it easy to move to Python from any other programming language. One potential downside is speed, but that should be addressed only if it ever becomes an issue.
Multiple Language Option
We can extend support to other scripting languages, e.g. R, which is also popular among economists, and to compiled languages, primarily C/C++. The pros:
- We might attract more people if they can program in their language of choice.
- There is no simple way to organize intercommunication between all these languages. On this server that can be done, so that is not the issue. The issue lies on the user side. Just with python everybody can easily run the complete simulation on his home computer and try to make his own program better. If we allow for multiple environments, then most people will have to run just a subset of all the programs, the ones written in their preferred environment. It is unreasonable to expect that everybody installs a C/C++ compiler, Python, R, etc., plus configures whatever mechanism we choose for inter language communication.
- A lot of economists use Matlab and Stata, some use Mathematica. If we opt for multiple languages, these two (three) should be on the list. But then expensive licenses are required, which at the moment we cannot afford.
At this moment we are a few well intentioned participants and the security should not be an issue. However, if the project grows to the point where any public submissions are allowed, then two security considerations arise.
- A malicious user might submit a script that scoops whatever information is accessible to it, hoping to find passwords or other private information, and then sends this information to the user. Or the script might install malware, etc.
- Python does not provide any internal security. While a proper interface will separate firm scripts from each other and from the managing script, it is only meant to prevent human error. Python allows any part of the program to access any other if the programmer explicitly chooses to do so. An entrepreneurial user might submit a python script that directly interferes with the managing script so as to increase its score.
On the server, both of these attacks can be prevented if each python script runs in a separate process with its own privileges, and the firm scripts communicate with the managing script via, say, TCP sockets. However, if an external researcher decides to download all the programs and run them on his home/office computer, he is still exposed to both attacks. Is there a robust way to prevent that risk?
I suggest we use Git. Currently we are small group, so users can simply email me the programs when they are ready for competition and I'll take care of the version control. Meanwhile, I'll investigate what could be the easiest option to allow users to automatically upload their programs.
There are a lot of web interfaces to Git. I will install one on this website, so all the programs (and all edit history) will be readily available.