First stable version of improved ai_plan_research

First stable version of improved ai_plan_research

[Lincoln Peters]

The bug-fixes provided by Eric seem to have eliminated the crashes that
I was experiencing.  It is still far from perfect, but it should allow
the AI to be at least a litter smarter when it picks advances.

Over the next few days, I hope to make it also consider the relative
worths of units that require the advance, what other advances require
the advance in question, and how long it will take to achieve the
advance.


A perfect AI would also have the following abilities for selecting
advances, all of which are (as far as I can tell) impossible to
implement in its current form:

1. Decide what kinds of units it wants, then choose the proper sequence
of advances to gain access to them.
2. If an advance is required for an advanced unit to grow beyond a
certain size, try to obtain that advance before the unit reaches that
size.
3. Determine that an existing unit requires another unit to function
properly, and if that second unit is unavailable, research the necessary
advances.

And so on, and so on, and so on...

---
Lincoln Peters
<sampln@sbcglobal.net>

What use is magic if it can't save a unicorn?
		-- Peter S. Beagle, "The Last Unicorn"


Here's the new function:

static void
ai_plan_research(Side *side)
{
	/*  There are many things to consider when choosing an advance:
	 * 1. What new units do I gain?
	 * 2. How does it affect my existing units?
	 * 3. How long will it take to gain this advance?
	 * 4. Based on all of these merits, how important is this advance?
	 *
	 * Unfortunately, many of these issues are impossible to thoroughly
	 * handle without radically re-engineering the AI, so I'll do what I
	 * can with what we have.
	 *           -- Lincoln Peters
	 */
	
	int numAdvances = 0;	/* Number of advances that could be researched */
	int tWeight = 0;	/* Total weight (potential value) of all advances */
	int *uWeight;		/* Peceived value of available advances */
	int count1 = 0;		/* Used in any place where a counter is needed */
	int count2 = 0;		/* Likewise */
	int count3 = 0;		/* Likewise */
	int result;		/* Random number to determine advance with weighting */
	
	int n, a, i;		/* Legacy code; will be removed after debugging */
	
	/* First, get a count of the available advances. */
	
	for_all_advance_types(count1) {
		if ( side_can_research( side, count1 ) ) {
			numAdvances++;
		}
	}
	
	if ( numAdvances == 0 ) {
		/* No advances are available! */
		Dprintf( "Warning: Trying to pick an advance when no advances are available.\n" );
		net_set_side_research( side, NONATYPE );
		return;
	}
	
	/* Now try to calculate the worth of those advances. */
	
	/* Allocating memory for this array is sooooo much easier in C++! */
	Dprintf( "About to allocate the array for tracking advance worth...\n" );
	/* uWeight = malloc( 2 * numAdvances ); */
	uWeight = (int *)xmalloc(numAdvances * sizeof(int));
	Dprintf( "Finished allocating the advance worth array.\n" );
	
	Dprintf( "Evaluating the worth of advances...\n" );
	for_all_advance_types(count1) {
		if ( side_can_research( side, count1 ) ) {
			uWeight[count2] = 0;
			
			/* Does it enable new units? */
			for_all_unit_types(count3) {
				if ( ua_needed_to_build( count3, count1 ) ) {
					/* This unit needs this advance. */
					uWeight[count2]++;
				}
				
				/* The following block of code refers to tables
				 * that exist in the documentation, but not in
				 * the code.  It should be possible to safely
				 * un-comment it once those tables are properly
				 * implemented.
				 
				if ( ua_multiply_production( count3, count1 ) > 1 ) {
					uWeight[count2] += ua_multiply_production( count3, count1 );
				} else if ( ua_multiply_production( count3, count1 ) < 1 ) {
					uWeight[count2] -= 1.0 / ua_multiply_production( count3, count1 );
				}
				
				uWeight[count2] = uWeight[count2] + ua_add_production( count3, count1 );
				*/
			}
			
			/* Just to be safe... */
			if ( uWeight[count2] < 1 ) {
				uWeight[count2] = 1;
			}
			
			tWeight += uWeight[count2];
			count2++;
		}
		
	}
	Dprintf( "Finished determines worth of advances.\n" );
	
	/* Need to adjust worth based on time required to achieve it. */
	
	/* Finally, choose a course of action! */
	
	result = xrandom(tWeight);
	count2 = 0;
	
	Dprintf( "Selecting an advance...\n" );
	for_all_advance_types(count1) {
		if ( side_can_research( side, count1 ) ) {
			if ( result <= uWeight[count2] ) {
				/* We have a course of action! */
				Dprintf( "Selected an advance!  Cleaning up...\n" );
				free( uWeight );
				Dprintf( "Successfully deallocated the advance worth array.\n" );
				net_set_side_research(side, count2);
				Dprintf( "Advance selection complete.\n" );
				return;
			} else {
				/* Not this one.  Keep looking... */
				result -= uWeight[count2];
			}
			
			count2++;
		}
	}
	
	/* If we've gotten here without a course of action being chosed,
	 * something really weird has happened. */
	 
	Dprintf( "AI failed to pick an advance; falling back to the bad decision-making process!\n");
	
	free( uWeight );
	
	

	i = 0;
	for_all_advance_types(a) {
	    if (side_can_research(side, a)) {
		++i;
	    }
	}
	n = xrandom(i);
	i = 0;
	for_all_advance_types(a) {
	    if (side_can_research(side, a)) {
		if (i == n) {
		    net_set_side_research(side, a);
		    return;
		}
		++i;
	    }
	}
	net_set_side_research(side, NONATYPE);
	
}

Re: First stable version of improved ai_plan_research

[Elijah Meeks]

> A perfect AI would also have the following abilities
> for selecting
> advances, all of which are (as far as I can tell)
> impossible to
> implement in its current form:
> 

You could add GDL support for this by letting the
Designers write weighted tables.  Then someone could
define "Air Focused", "Space Focused", "Ground
Focused" and "Magic Focused" as each having different
values for the various techs and units (These same
values being integrated into the previously
brainstormed AI build recommendation tables) and each
could be randomly assigned per side (Or selected from
the side selection list, with a column next to the AI
column).

It would still be useful to have an
advance-precludes-advance table, in those cases when
two advances are actually in opposition to each other.
 The two examples I can think of off the top of my
head are the different styles of Magic in Opal (You
shouldn't be able to research both Life and Death
magic, or Sorcery and Chaos) and when the advances
represent different ways to implement a new technology
(So that, instead of having a "3rd Generation Tank"
tech, you have a "No-Frills 3rd Generation Tank",
"Typical 3rd Generation Tank" and a "Cutting Edge 3rd
Generation Tank") so that different sides end up
fielding similar but different vehicles (All of which,
after finding whichever tech they chose, can then
research 4th Generation Tank techs).




		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

Re: First stable version of improved ai_plan_research

[Andreas Bringedal]

> A perfect AI would also have the following abilities for selecting
> advances, all of which are (as far as I can tell) impossible to
> implement in its current form:
> 
> 1. Decide what kinds of units it wants, then choose the proper sequence
> of advances to gain access to them.

Doesn't the one that create the tech three place an AI-value of the techs that is of most use for AIs?

Andreas

Re: First stable version of improved ai_plan_research

[Lincoln Peters]

On Wed, 2004-09-08 at 23:17, Andreas Bringedal wrote:
> > 1. Decide what kinds of units it wants, then choose the proper sequence
> > of advances to gain access to them.
> 
> Doesn't the one that create the tech three place an AI-value of the techs that is of most use for AIs?

So far, all it does not is weigh the value of an advance by the number
of new units it could build if it achieved the advance in question.

In the case of tech points (as per postmodern.g), the game (and the AI)
uses an entirely different mechanism.  You pick a unit to build, and if
you don't have the technology to do so (not the same as advances), the
unit researches it prior to building the unit.  Unless the game designer
specified otherwise in the "tech-crossover" table, these tech points are
specific to each unit type.

---
Lincoln Peters
<sampln@sbcglobal.net>

BOFH excuse #18:

excess surge protection

Re: First stable version of improved ai_plan_research

[Eric McDonald]

On Wed, 8 Sep 2004, Elijah Meeks wrote:

> You could add GDL support for this by letting the
> Designers write weighted tables.  

Currently, Xconq only supports tables of integers. One would need 
to implement suport for tables of lists first.

> It would still be useful to have an
> advance-precludes-advance table, in those cases when
> two advances are actually in opposition to each other.

I think the example regarding Opal makes a good case for this. 
As was previously mentioned, you can, in theory, shut off 
advances by degrading the production of a material needed to 
research them. The only problem there might be if someone hoarded 
the material needed for the precluded advance ahead of time.... 
I'll add 'advance-precludes-advance' to my todo list.

Eric