On Wed, Jan 19, 2011 at 09:39:33AM -0500, no-re...@cfengine.com wrote: >Forum: Cfengine Help >Subject: Cfengine and AI >Author: neilhwatson >Link to topic: https://cfengine.com/forum/read.php?3,20185,20185#msg-20185 > >This morning I read a fascinating article about a team at Stanford that built >a Starcraft AI agent for an AI tournament(1). I wrote an article a while back >about Cfengine comparing it to a fictional nanobot (2). I can't help but >think about how advanced AI might be applied to Cfengine. > >In the game of Starcraft, or any RTS game, one has to decide what to build, >when to build and how much. These decisions are based on what the enemy is >known to be doing. Similarly combat decisions are based on probably outcome >and acceptable loss among other things.
Several years ago, I read a facinating dissertation on AI, as it relates to the board game Settlers of Catan (yes, I need to get out more, you can read it here: http://sourceforge.net/projects/jsettlers/files/). One of the points was to explore different strategies for how to win (i.e. get 10 points, via several different methods, using different resources). In the game, there is a well defined end condition (similar to cfengine), several possible ways to get there (kind of similar), along with an element of random chance (sort of similar), and competition (anyone who thinks users aren't "the enemy" hasn't been on the job long enough <grin>). The biggest difference seems that with cfengine policies, the target is static, and you converge to it. With non-trivial games, the path to "win" may change substantially due to outside influences (other competitors), or the rules themselves may change (think of games like Magic the Gathering, or even FLUXX). It would be *very* interesting if cfengine started writing policies for later execution. We've toyed with this idea, very briefly, in regards to writing iptables rules: promises on the policy server would manage source iptables rule files, which are then distributed to the clients as usual; this is as opposed to using edit_lines to edit them directly, and having a convergence nightmare. >To Cfengine the enemy is change. What is changing? At this time Cfengine >changes a change back to the desired state. What if the agent could determine >why the change was happening and make a change to prevent it? What if the >agent could determine if such actions were worth the cost of resources versus >just correcting the original change? I've wondered about this myself on occasion. For something simple, and atomic, like file permissions, it's easy to have two promises "fight": one sets mode 775, and a second sets 755. It's possible that these will set and reset permissions for a very, very long time. It's a small operation, but there is a cost associated with executing both promises. Twiddling permission bits is fairly cheap, but constantly parsing and evaluating the promises, determining that they are "in error", and fixing them, can add up over time... Very intersting topic. :) > >1. >http://arstechnica.com/gaming/news/2011/01/skynet-meets-the-swarm-how-the-berkeley-overmind-won-the-2010-starcraft-ai-competition.ars >2. http://www.cfengine.org/cftimes/articles/0000000019.html > >_______________________________________________ >Help-cfengine mailing list >Help-cfengine@cfengine.org >https://cfengine.org/mailman/listinfo/help-cfengine -- Jesse Becker NHGRI Linux support (Digicon Contractor) _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
