news
dmangame matches on appengine revived
i spoke too soon again. the appengine instance is now running tournaments, using the new app engine Cloud Storage APi (instead of the old files BlobStore APi). i look forward to the next form of Storage that dmangame has to migrate to.
dmangame matches on appengine archived
i spoke too soon in the last update: it was possible to recover from the broken HTML, so now the matches on the appengine instance are viewable, but the Files API has been deprecated, so no new matches can be run for now
dmangame no longer on app engine
after watching dmangame’s HTML5 viewer suffer bit rot for a few years, i’ve decided to take the game off app engine. games will still be playable locally, but tournaments will not be running on a dedicated app engine instance any longer.
the main reason for taking the app engine instance down is that the HTML blobs that were being stored are no longer viewable in modern browsers (because of an extra semi-colon!) and it appears difficult to recover from. so - it’s been a fun ride, app engine - but we are going to have to part ways for now.
appengine migration to dmangame-hrd
we are migrating dmangame-app to dmangame-hrd instance on appengine, as well as clearing out the old instances and games for a new fresh start. hope to see you there!
dmangame at pyclass (pt. 2)
retiring AI from dmanai repository
if you’ve pulled from dmanai recently, you may have noticed more than a few deletions. i’ve decided to keep only AI i’m working on in the dmanai repository, as users can host their AI on github and play against other github repositories.
this also makes sense because the AI on the ladder are being hosted in other github repositories which are the definitive source of the AI.
thanks everyone for contributing, hopefully you won’t run into many git merge conflicts on the next pull ;-)
Post-June updates
On github
A new AI has appeared in the ladder, welcome OliAI2. OliAI2 is built on a squad based strategy, allowing for better coordination among subsets of units. Cool stuff :-)
at pyclass
This coming monday, (july 11th), dmangame will once again be at pyclass. This week, we’ll go over a basic AI strategy. Or to put it another way: how does one go from nothing to having an AI with some semblance of a strategy.
ranking system changes
If you’ve been following the ladder, you may have noticed that the rankings are volatile. We’ve been speculating as to possible reasons: one reason for this is that the maps have too much variance in the base positioning… it’s possible for an AI to get sandwiched or put in a bad place. In order to prevent this, we are moving to more static maps, with the help of behindcurtain3. While working on this, behindcurtain3 raised the point that having a variable number of players per map can lead to confusion about the strength of an AI.
Supplanting macro, micro and village will be static maps with a set number of players. Hopefully the rankings on these maps will settle more, since the number of players per map is fixed. In addition, the overall ranking will be an average of the AIs ratings on each map, leading to more stable overall results.
Deadlining AIs
Also related to appengine, the appengine instance went over quota yesterday. Since there isn’t a good way of getting access to the quota programatically, it becomes somewhat harder to run matches and host the server on the same appengine instance, without running into resource usage issues.
Since it can’t be prevented, I’ve put in place a system for marking when an AI hits the deadline. If the execution expires on a game and an AI is responsible for more than 90% of the runtime, it will be marked as faulting. If an AI faults 10 times, it will get disabled temporarily and a notice will be sent to the author.
dmangame at pyclass
github, your issue system is pretty good.
There has been some good discussion on github, which prompted a bunch of updates. if you have any feature requests, ideas or whatever - open an issue on github - it’ll get looked at. i promise.
game mechanics
the capture mechanics have been adjusted, recently - now buildings spawn units UNIT_CAPTURE_LENGTH turns after the building has changed owners.
developer updates
two updates have been added to help AI developers make assumptions and speed up their code. , game settings are now passed to each AI and are available in the ‘settings’ object.
print settings
print settings.map
print settings.map.size
--profile now saves per AI profiling information, so if you think your AI
is going slow - now you know.
# Saves a profile to "%s.prof" % killncapture.AI_CLASS which would be
# ./KillNCapture.prof
python main.py ai/killncapture.py --profile
finally, the default for github hosted AI is to run in safemode using safelite, so if you are writing an AI, try not to import sys or os. I know it may issue warnings about modules being loaded via require_dependency - that is being looked into.
user submissions
behindcurtain3 has submitted the warzone map - it’s a fast paced close combat map with lots of damage and unit spawning.
how safe is it to run remote code?
tldr:
somewhat safer, now.
use the -s or --safe-mode flag when running remote AI to run the
game with more restrictions. do it. it’ll keep you safe.
the long of it:
one really cool feature of dmangame is that it has support for loading AI off github, allowing for AIs to play against each other from any repository. unfortunately, this also means that if you run an AI from someone else’s repository, you are about to run untrusted code.
i am happy with running untrusted code on app engine, because they
are google’s machines. i am less okay with running untrusted code on
my own machine. For example: import os; os.system("rm -rf /") is
all that is needed to bring down my computer by a rogue AI.
according to the python wiki, sandboxing python is notoriously hard and difficult. so, i’ve been keeping an eye out for how other projects are sandboxing python.
two interesting projects i’ve seen that sandbox python are zope and hackiki. they take different approaches: zope creates a very limited subset of python features that can be used and drops the interpreter into a lower state of trust, while hackicki creates chroot jails for running the python in.
they both looked to have high setup costs, though, so i actually decided to try out tav’s safelite mechanism. safelite went around the python mailing lists in 2009 and through a day of iteration, led to a stripped down python. unfortunately, due to the way the game works, f_locals has to remain exposed in stack frames in order to verify that AIs are only accessing allowed variables.
conclusion:
it’s still being tested, so for now, use the --safe-mode or -s
option to run AI’s in safe mode. It will prompt you whenever an
untrusted module is loaded - try not to allow AIs loading sys or
os and if your AI depends on either of those, consider removing
them as dependencies. once the kinks are worked out in the future,
games will run in safe mode by default.