Add support for the Protoss race

[GoogleCodeExporter]

Support for other races should be added in future releases.

Original issue reported on code.google.com by netpr...@gmail.com on 19 Oct 2010 at 9:03

[GoogleCodeExporter]

I'm interested in assisting with this when it comes to it. Credentials include 
3 years of industry tools programming.

Original comment by rakirte on 2 Nov 2010 at 2:06

[GoogleCodeExporter]

I'm also interested. Contact me if you need some help from an IT-Student and a 
Starcraft player

Original comment by paulmoel...@gmail.com on 4 Nov 2010 at 10:06

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I have started playing around with the changes for Protoss.  I have something 
fairly basic at the moment (probes/nexus/gateway/zealots) and it seems to be 
working.  However, I am having trouble determining when/how to incorporate the 
Chrono Boost.  Is there something similar (ability?) for Zerg that would be 
similar (in terms of decision making)?

Original comment by berg...@gmail.com on 4 Nov 2010 at 8:25

[GoogleCodeExporter]

I think the easiest way to think and implement chrono boost is think of it as 
an ability on each production building. Each building should have a 
useChronoBoost ability on it and should choose the target nexus to use energy 
from. 

Something like
Class ProductionBuilding{
  public int ChronoBoostTimeRemaining = 0;
  public int buildTimeRemaining;
  public Unit BuildingUnit;

  public boolean canChronoBoost()
  {
    if ChronoBoostTimeRemaining == 0
      return true;
    return false;
  }

  public useChronoBoost(Nexus n)
  {
    if canChronoBoost() && n.getEnergy() >= 25
    {
      ChronoBoostTimeRemaining = 20;
      n.useChronoBoost(); //Removes 25 energy from the nexus
    }

  }

  //Called after every time step to see if an action is finished.
  public Unit next()
  { 
     if (buildingUnit != null)
     {
       if (ChronoBoostTimeRemainig > 0 )
       {
         ChronoBoostTimeRemainig -= 1;
         buildTimeRemaining -= 2;
       }
       else
       {
         buildTimeRemaining -= 1;
       }

       if (buildTimeRemaining <= 0)
       {
           temp = buildingUnit;
           buildingUnit = null;
           return temp;
       }
     }
  }

} 

Original comment by michael....@gmail.com on 4 Nov 2010 at 11:48

[GoogleCodeExporter]

Original comment by qwerty10...@gmail.com on 5 Nov 2010 at 5:19

• Changed state: Started

[GoogleCodeExporter]

Something like that could work.  But there is still the problem of how the 
algorithm will decide when to use it.  In the case of the Queen's ability to 
spawn larva, the assumption is that you just use it every time it is available. 
 But with Chrono boost, the typical decision is to use it after you build your 
first pylon for 2 probes and after your Gateway for another 2 probes. After 
that point, it could be used for accelerating Zealots or saving it for Warp 
Gate tech.  How will the algorithm make this decision? 

Original comment by berg...@gmail.com on 5 Nov 2010 at 12:48

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It would seem that the framework would need to be changed a fair bit before 
implementing things like Chrono Boost.  If I understand it correctly, the 
BuildOrder object is really just maintaining counts of unit/buildings and their 
states but not the objects themselves.  As a result, trying to determine how 
much energy a Nexus would have would be difficult once more than one exists.  

This would also present a problem for Queens as the assumption is you would 
only be using the Spawn larva ability.  However if you wanted to incorporate a 
Creep Tumor with your Queen, her energy would be a limiting factor which is not 
taken into account anywhere thus far.

Original comment by berg...@gmail.com on 5 Nov 2010 at 1:05

[GoogleCodeExporter]

Well, implementing it as an event which could only happen on a production 
building that currently is producing something but is not chrono boosted could 
be the way to implement it. Everything in the optimizer is an event. Also if 
you prevent the system from boosting out stuff unless there is something to 
boost and not already being boosted, then the order that the system comes up 
with could show the chronoboost event. When analyzing an order, when the system 
comes across a chronoboost event, it will just check to see if there is enough 
energy, otherwise it will call the wait action until there is enough. As far as 
the framework, it would have to be rewritten to abstract the nexus as a 
production facility as well as abstract all of the production facilities. Then 
you can check the energy on each nexus when trying to call a chronoboost event. 

Original comment by michael....@gmail.com on 5 Nov 2010 at 5:10

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I am putting the Chrono Boost stuff on hold for now as I still am learning how 
the framework is working.  Can anyone explain briefly how the Fitness functions 
work (differences between EconFitness and StandardFitness).  I am trying to 
determine the differences between augmentScore, augmentCappedScore, and 
augmentDropoffScore.

Here is some code from the files I am working in the EconFitness:

public double augmentScore(EcState current, EcState destination, double score, 
boolean waypoint)
{
    EcState c = current;

    score = augmentCappedScore(score, c.probes, destination.probes, c.bases()*30, 50, 4, waypoint);
    score = augmentScore(score, c.stalkers, destination.stalkers, 175, 1.75, waypoint);
    score = augmentScore(score, c.zealots, destination.zealots, 100, 1.0, waypoint);
    score = augmentScore(score, c.sentries, destination.sentries, 150, 1.5, waypoint);
    score = augmentCappedScore(score, c.pylons, destination.pylons, 25, 100, 1.8, waypoint);
    score = augmentScore(score, c.gasAssimilators, destination.gasAssimilators, 25, 1.5, waypoint);
    score = augmentDropoffScore(score, c.numNexus, destination.numNexus, 400, 4.0, waypoint);
    score = augmentDropoffScore(score, c.gateways, destination.gateways, 150, 1.5, waypoint);
        score = augmentDropoffScore(score, c.warpGates, destination.warpGates, 250, 2.5, waypoint);
    score = augmentDropoffScore(score, c.cyberneticsCores, destination.cyberneticsCores, 150, 1.5, waypoint);
    score = augmentScore(score, c.warpGateTech, destination.warpGateTech, 100, 1.0, waypoint);
    return score;
}

I am not sure how/when to use the different augment functions and which values 
I should use.

Original comment by berg...@gmail.com on 5 Nov 2010 at 7:04

[GoogleCodeExporter]

AugmentDropoffScore is used to score things you only would like one of.

AugmentCappedScore... not sure. Oh, it seems that it doesn't count the unit 
over a certain count.

Original comment by Frit...@gmail.com on 6 Nov 2010 at 4:16

[GoogleCodeExporter]

FYI a Protoss (and Terran) version is being worked on here.  I'm sure they'd 
welcome new help. :-)

https://github.com/infinity0/evolutionchamber

Original comment by mike.angstadt on 17 Nov 2010 at 4:03

[GoogleCodeExporter]

Is this issue dead? There hasn't been any checkins to github since November, 
nor anything related to it here...?

Original comment by yuriastrakhan on 5 Feb 2011 at 2:53

[GoogleCodeExporter]

I wish i could help with protoss & terran but I don't know anything about 
programming.
Still, if/when you have something to release, contact me first for french 
translation. Goes for terran aswell, of course :)

Original comment by GSand...@gmail.com on 6 Feb 2011 at 12:56

[GoogleCodeExporter]

There's hasn't been any work done on Protoss/Terran in a while.  I'd like to 
keep this issue open though in case we or somebody else finds the time to start 
doing serious work on it.

If anyone wants to make sure all the unit/building/upgrade info is correct, 
please feel free.  I think they changed some things in recent patches:

http://code.google.com/p/evolutionchamber/source/browse/trunk/EvolutionChamber/s
rc/java/com/fray/evo/util/ProtossLibrary.java

http://code.google.com/p/evolutionchamber/source/browse/trunk/EvolutionChamber/s
rc/java/com/fray/evo/util/TerranLibrary.java

Original comment by mike.angstadt on 8 Feb 2011 at 6:03

[GoogleCodeExporter]

I had thought work was being done by others.

Knowing this, I think I'll start working on the terran race this weekend. It 
looks like a lot of work is already done.

Mike, I'll use your new UI as well, since it's easier to use and cleaner anyway.

Original comment by jeff.dil...@gmail.com on 8 Feb 2011 at 8:04

[GoogleCodeExporter]

Sounds good.

Original comment by mike.angstadt on 8 Feb 2011 at 9:45

[GoogleCodeExporter]

If you can, make your changes to the trunk (the old GUI) and focus on writing 
the logic first.  The trunk is the most up to date and contains changes that 
the NewGUI2 branch does not.  If you modify the branch, then it will make it 
harder to merge into the trunk.

Original comment by mike.angstadt on 10 Feb 2011 at 2:11

[GoogleCodeExporter]

Okay, that makes sense.

Original comment by jeff.dil...@gmail.com on 10 Feb 2011 at 10:04

[GoogleCodeExporter]

How's progress?

Original comment by nata...@gmail.com on 6 Jul 2011 at 1:20

[GoogleCodeExporter]

Is this still being done or have you stopped working on it?

Original comment by person0...@yahoo.com on 13 Dec 2011 at 11:01