Spring RTS Engine

It may be more of a case of mutation then GA in this case....

I have a variety of WAG (wild ass guess) parameters in my bot related to my TO&E (table of organization and equipment)...like how many of certain types of units I will ultimately need based upon map analysis. I'd like to run many battles with my bot tweaking these parameters, and narrow down the proper options for some of them.

we're working on crosscompiling it to windows from linux, as a windows limitation currently prevents compiling this on windows...

in the future, I'll support/allow using my server cluster for AI learning.

aegis wrote:last time I checked, our launching options could've been better... I think maybe these should be the main initial focus... possibly including a nice preset system, the ability to redo runs, an easy way to run replays for crash tests, sync testing across multiple bots...

Sure, go ahead! My own focus is specifically on ai bot-matches, but there's no reason why you can't integrate the functionalities you've mentioned into it.

One thought: it could be possible to have multiple views onto the central engine, essentially boiling down to different menu.py instantiations, and be able to easily switch between menu.py instantiations, eg from a View menu.

Edit: one could store the name of the current view in the cookies table, or maybe have a second cookie value dedicated to the current viewname, and then it would be very easy for menu.py to switch between instantiations.

I was thinking an AI ladder could just be automatically propagated based on the database of completed matches... the main code of the site/botrunner could then focus completely on how to best create matches and run them

aegis wrote:I was thinking an AI ladder could just be automatically propagated based on the database of completed matches... the main code of the site/botrunner could then focus completely on how to best create matches and run them

Well, I feel that the AI Ladder website needs to be capable of scheduling matches itself.

In addition, I feel the AI Ladder website should ideally allow AI developers to upload new versions of their AI on an adhoc basis, and see how they stand compared to their old versions, and to other people's AIs

So, it's not quite as simple as a one-way propagation of results from the runner to the ailadder, but if you mean, have two websites, and one website can invoke functionalities from the other, well possibly.

In the case case that you want to factor the website into two, I guess that AI Ladder would need at least, off the top of my head, to be able to call the following methods:
- getavailablemaps()
- getavailablemods()
- getavailableais()
- installai(ainame,aiversion,downloadurl)
- requestmatch( modname,mapname,ai0name,ai0version,ai1name,ai1version, options)
- getmatchrequests()
- getmatchresults()

hughperkins wrote:Well, I feel that the AI Ladder website needs to be capable of scheduling matches itself.

In addition, I feel the AI Ladder website should ideally allow AI developers to upload new versions of their AI on an adhoc basis, and see how they stand compared to their old versions, and to other people's AIs

couldn't this be handled by statistics on a single run of matches?
for example, I say to test AAI 0.8, AAI 0.9, KAIK, and RAI on SmallDivide and Comet Catcher, and to run all of the matches three times.
it generates a list of matches, groups them, runs them, and displays the results with statistics together, solving "upload new versions of their AI on an adhoc basis, and see how they stand compared to their old versions, and to other people's AIs" if we have a facility for uploading AIs to botrunners.

Running a single league by hand like that is I feel doable, but I feel it will become more problematic when there are lots of leagues and leaguegroups.

I'd like the AILadder website to work like this:
- AI registers new AI, with download url
- goes away for coffee, or work on new version of AI
- comes back a bit later, and sees how their AI fares against other AIs, on water maps, choked maps, metal maps, land maps, ...

Have you tried the new scheduler by the way? It's in the staging website since yesterday. You can see how it works on this page:

http://manageddreams.com/ailadderstagin ... ircount.py

you could set up scheduled runs, automatic runs on upload, etc...

make a preset of matches to run and apply it to anything.

aegis wrote:you could set up scheduled runs, automatic runs on upload, etc...

make a preset of matches to run and apply it to anything.

I could do, but I'd prefer that AILadder does the work for me.

Basically, if you can make it so the runner website that you are thinking of allows for scripted configuration via an xmlrpclib webservice, then AILadder can do all these things itself, without needing me to do stuff for it.

It does seem to me to make a certain sense to factorize the website into two parts like you seem to be suggesting, with one being a service used by the other.

hughperkins wrote:

aegis wrote:you could set up scheduled runs, automatic runs on upload, etc...

make a preset of matches to run and apply it to anything.

I could do, but I'd prefer that AILadder does the work for me.

but that's the point. the website still does the work for you, but "the work" is anything you want instead of a dedicated ai ladder

Here's a few aesthetics changes you can make that Ive meddled with using firebug to see what works.

• Remove all borders on tables, no exceptions
• Your new colour scheme is #fff ##F0F0F0 #F8F8F8 and #000. Use the two shades of gray where you currently have those 2 garish shades of light blue

• Code: Select all

  body * { font-family: helvetica,arial,verdana; }

• Wrap the entire html output in a div container, so:

  Code: Select all

  <body>
      <div id="ailadder">
          <!-- stuff --!>
      </div>
  </body>
  

• Put a title with <h1> tags at the top, and use <h2> instead of <h3> for page headings, your confusing search engines and aprsers and your being unsemantic.
• Add an 'alt' class to alternating table rows
• Add 8px of padding to the td.tablehead class (important!!!)
• Remove the borders and background colours off the top menu

aegis wrote:but that's the point. the website still does the work for you, but "the work" is anything you want instead of a dedicated ai ladder

Alright, we'll run with this and see where it goes, so, on an experimental basis, I've created:
- a new git repository 'springgrid'
- a new ailadder branch 'gridclient'

You have hoijui both have commit access to the springgrid repository, http://github.com/hughperkins/springgrid

There is a springgrid staging website at:
http://manageddreams.com/springgridstaging

Edit: created website for ailadder gridclient branch at:
http://manageddreams.com/ailaddergrid/viewmaps.py

It's connected to the springgridstaging website. For example, if you purge or add maps to the springgridstaging website, you will see that the maps on ailaddergrid change too.

I also second the abstraction, where botrunners are totally separate from all of these websites, we can connect a botrunner to multiple websites, and anyone (trusted) can implement a basic interface to use botrunners.

Update to ailadder git 'gridclient':
- migration to springgrid finished:
-- submitrequest works
-- viewresults works
-- viewrequests works
-- showaimatchpaircount works

http://manageddreams.com/ailaddergrid/s ... ircount.py

It's very slow, but it works.

Edit. Actually, did some timings, using 'time':

time curl http://manageddreams.com/springgridstag ... equests.py > /dev/null:
real: 3.811s
real: 2.338s
real: 1.714s

time curl http://manageddreams.com/ailaddergrid/viewrequests.py > /dev/null
real: 2.832s
real: 2.538s
real: 2.502s

Not so different. Timings are from china, and both websites are on the same web host in America, so perhaps not so surprising, and fairly encouraging.

aegis wrote:I also second the abstraction, where botrunners are totally separate from all of these websites, we can connect a botrunner to multiple websites, and anyone (trusted) can implement a basic interface to use botrunners.

Interesting. How would that work? Each botrunner has a list of sites that it subscribes to, and when it finishes a request from one, it polls the next website in its list until one of them sends a request?

aegis wrote:I also second the abstraction, where botrunners are totally separate from all of these websites, we can connect a botrunner to multiple websites, and anyone (trusted) can implement a basic interface to use botrunners.

Ok, done in springgrid git master. You'll need to delete your config.py and config.pyc, and let it recreate it.
- config.py now contains a list 'websiteurls'
-- by default, it contains the single website you specify when you first run botrunner.py
-- you can add as many urls to this list as you want

How it works at the moment:
- ping pings all configured urls
- for polling for requests:
-- each host in polled in turn
--- any request is processed
--- if any hosts returned a request, then each host is repolled straight away after the game finishes
--- otherwise, sleep a bit, then repoll all servers

One question in my mind: should the results of each game be uploaded only to the host that requested it (how it works currently), or to all hosts?

Replacement css stylesheet

Diagram of architecture of result of draft fission of

AF wrote:Replacement css stylesheet

Added, and I also followed your instructions from before too, before adding in the style.txt.

http://manageddreams.com/ailaddergrid/viewmaps.py

I'm just gonna leave this here.

warning: there's a chance it will overwrite some your spring settings, like viewradius and tree view distance