48 replies to this topic

[quantumstate]

Almin, on 05 April 2012 - 11:48 AM, said:

But the first version of common-api will stay where it is now, won't it? Because I play around and try myself out on an own bot and probably need it as a school porject. So will the regular common-api stay the way it is, at least for the next half year?

I have no plans to remove the old common-api. The common-api-v2 is pretty backwards compatible. I think the only breaking change is that ownEntities was removed. That is assuming that your code doesn't use nasty tricks like qBot did. Though if you only do that you don't get any of the benefits of the new API.

6 months is quite a long time though and there might be things happening like threading the AI scripts which might change some stuff, so it isn't guaranteed that the your AI won't break. Any changes should be fairly easy to cope with though.

[feneur]

You can of course also use an old version of 0 A.D. for your AI development (the easiest way is probably just to have a separate SVN checkout of a specific version of 0 A.D. that's just for your AI development, and another/the release version for playing the game). It depends a bit on the objectives for the school project, and for your AI development. If you just want to try things out and play around it depends on how much time you're willing to put into it. If you might want to keep on working on it/release it for others it's definitely recommended to stay on top of the development, but if you just want to play around a bit in the short term using a specific, unchanging, version of the AI API is probably easier. For a school project that may even be required, to make it easier for the teachers to follow it if nothing else, but on the other hand it's more realistic to have to be able to keep up with changing APIs, so hopefully it could work either way. (Also, Jonathan et al are after all not going to change things "just because"/to make things harder, so hopefully the improvements will even make further development easier, and should be worth staying on top of )

[Almin]

Thanks, both of you. Can anyone tell me whether JuBot is still maintained, as I used it's gamestate, or shall I rather switch to the gamestate of qbot instead?

[quantumstate]

JuBot is not being maintained very actively. It is likely to be kept compatible with the game for a while but the main author Jubal hasn't been around for a while and I don't know of anyone else interested in working on it.

The qBot gamestate is likely to change in the near future as I do more work to convert to the new api. If you want to switch to the new api it would be good to switch, otherwise it probably won't be of much benefit.

[Almin]

Thank you very much, quantumstate! I switched to your gamestate and common-api-vs2 and it works! For the case that you didn't know it until now: You're awesome! Keep up the good work!


by the way: Nice new avatar-picture of yours!

Edited by Almin, 06 April 2012 - 02:45 PM.

[quantumstate]

Here is an example of how to use the new API. The new API is almost completely backwards compatible with the old one with the only breaking change being the removal of ownEntities.

if (!this.allWorkers){
        var filter = Filters.or(Filters.byMetadata("role", "worker"), Filters.byMetadata("role", "militia"));
        this.allWorkers = gameState.getOwnEntities().filter(filter);
        this.allWorkers.registerUpdates()
}

When filtering from an existing entity collection the new collection will inherit the filters of the parent.

This will make this.allWorkers contain an entity collection of all units with a role of either worker or militia which will be efficiently updated. For the updating collections to work you should use the filters provided by Filters.

The special ownEntities case has been removed since this is easily implemented using Filters.byOwner.

qBot's gamestate.js gives examples of how this new system could be used

[wraitii]

I'm really wondering how much I should update Marilyn with the new persistent entityCollection system... It seems to rely on basically the same principle as my "unitInfoManager" (keeping track of units and adding/removing them as they appear/die). Did you do any specific optimization? I might just use it for the enemy and the attack plans/ "micromanager" managers which I plan to implement.

[Almin]

I don't know, whether that's a bug or a feature, but you are aware of gameState.countFoundationsWithType(type) giving back the number of the foundations +1? Is this behavior intented? And just because I'm a little bit confused, this function returns only the number of foundation as not finished buildings. It does NOT include the number of buildings of the same type, which are already finished, does it?

[gudo]

[EDIT]Never mind, answered my own question.[/EDIT]

Edited by gudo, 10 April 2012 - 09:40 PM.

[Relish]

what do you think about adding a couple of external interface functions to UnitAI.js to let the entity object know which entity it is attacking and which are attacking it?

to enable something like this:

entity.underAttackByEntities() that returns an array with the ids of the entity attacking it

and

entity.attackingEntity() that returns the id of the entity that it it is trying to attack




this would make it a lot easier to develop any kind of morale system

[wraitii]

I've gotten a bug with the "Gamestate.getentitybiID" function as used by qBot... Apparently, you changed something, and now the Entity function wants to access "entity.template" when, in that case, it should access "entity._template._parent", unless I'm mistaken... Any information?

[quantumstate]

Almin, on 10 April 2012 - 06:57 PM, said:

I don't know, whether that's a bug or a feature, but you are aware of gameState.countFoundationsWithType(type) giving back the number of the foundations +1? Is this behavior intented? And just because I'm a little bit confused, this function returns only the number of foundation as not finished buildings. It does NOT include the number of buildings of the same type, which are already finished, does it?

Returning the number of foundations +1 is not intended, however I am looking at the function and it looks fine to me.

[b]GameState.prototype.countFoundationsWithType = function(type) {
	var foundationType = "foundation|" + type;
	var count = 0;
	this.getOwnEntities().forEach(function(ent) {
		var t = ent.templateName();
		if (t == foundationType)
			++count;
	});
	return count;
};[/b]

It is just meant to count the number of in progress foundations.

[Echelon9]

No off-by-one in there?

[wraitii]

Confirmed: you have introduced a bug between qBot and the common-api-v2: the gamestate GetEntityById function no longer works: this is because when creating an entity, it tries to access "entity.template", when it should try to access "entity.templateName" in that particular case (I think the other cases work properly).

[quantumstate]

Relish, on 13 April 2012 - 07:24 PM, said:

what do you think about adding a couple of external interface functions to UnitAI.js to let the entity object know which entity it is attacking and which are attacking it?

to enable something like this:

entity.underAttackByEntities() that returns an array with the ids of the entity attacking it

and

entity.attackingEntity() that returns the id of the entity that it it is trying to attack

This information is basically available to the AI. There are two different concepts of a unit attacking.

The UnitAI controls each unit, and is now exposed to the AI's, so you should be able to use a combination of UnitAIState and UnitAIOrderData to work out what target a unit is attacking or trying to attack. You can read simulation/components/UnitAI.js for details. This won't tell you directly which units are attacking a unit, this information isn't stored by the game, but you could construct it yourself.

Secondly there is a set of events sent each turn to the AI's, this is found in this.events if you are inheriting from the baseAI and contains a new set of events every time OnUpdate() is called. This will have an event for every time one unit does damage to another in an attack. You would again need to do some manipulation to get this information into the form you want.

wraitii, on 16 April 2012 - 03:21 PM, said:

Confirmed: you have introduced a bug between qBot and the common-api-v2: the gamestate GetEntityById function no longer works: this is because when creating an entity, it tries to access "entity.template", when it should try to access "entity.templateName" in that particular case (I think the other cases work properly).

Thanks, I have fixed this now.

Edit:

wraitii, on 09 April 2012 - 11:32 AM, said:

I'm really wondering how much I should update Marilyn with the new persistent entityCollection system... It seems to rely on basically the same principle as my "unitInfoManager" (keeping track of units and adding/removing them as they appear/die). Did you do any specific optimization? I might just use it for the enemy and the attack plans/ "micromanager" managers which I plan to implement.

The updating entity collections handle updates to properties, not just unit creation/death, this will be especially important when we have unit conversion happening since most of the time you filter by owner. There isn't an real optimization currently, but if it runs too slowly then I was thinking of adding a hierarchical system to help with filtering.

[Jubalbarca]

I'm not sure if morale would be an efficient system for an AI to use; what I'm working on is a system whereby it can run at the start of a battle, but if it commits it commits. Running away mid-battle is likely to lead to heavier losses for less gain/pain on the part of the enemy. Morale-based retreats happen in real life where people don't want to die; the AI has no such considerations really, it cares about whether its losses are efficient but not the life of any individual trooper.

(This is incidentally why apparently, when a team of computer gamers controlled the enemy in a war-simulation to train US officer staff, the gamers won by miles. The US officers, trained to fight a real war, were careful to avoid un-necessary losses. The gamers, only used to playing games where efficiency trumps loss of life, happily ran some of their best squads in on a suicide mission, losing most of their best fighters but managing to destroy all the US supply bases and thus effectively winning the war as their opponents had no supply lines).

[Mythos_Ruler]

Jubalbarca, on 16 April 2012 - 09:38 PM, said:

(This is incidentally why apparently, when a team of computer gamers controlled the enemy in a war-simulation to train US officer staff, the gamers won by miles. The US officers, trained to fight a real war, were careful to avoid un-necessary losses. The gamers, only used to playing games where efficiency trumps loss of life, happily ran some of their best squads in on a suicide mission, losing most of their best fighters but managing to destroy all the US supply bases and thus effectively winning the war as their opponents had no supply lines).

It's amazing what you can do when your soldiers have no fear of death.

[Relish]

Jubalbarca, on 16 April 2012 - 09:38 PM, said:

I'm not sure if morale would be an efficient system for an AI to use; what I'm working on is a system whereby it can run at the start of a battle, but if it commits it commits. Running away mid-battle is likely to lead to heavier losses for less gain/pain on the part of the enemy. Morale-based retreats happen in real life where people don't want to die; the AI has no such considerations really, it cares about whether its losses are efficient but not the life of any individual trooper.

(This is incidentally why apparently, when a team of computer gamers controlled the enemy in a war-simulation to train US officer staff, the gamers won by miles. The US officers, trained to fight a real war, were careful to avoid un-necessary losses. The gamers, only used to playing games where efficiency trumps loss of life, happily ran some of their best squads in on a suicide mission, losing most of their best fighters but managing to destroy all the US supply bases and thus effectively winning the war as their opponents had no supply lines).

In my AI I've tried a very simple approach (mainly to test how efficient my agent system was), making units escape a fight if engaged in an unfair fight (by number of enemy units) or if severely injured.


The agent's plan was to escape into a safe location like a base, a tower or a regroup point with another group of units.

In all the tests I did once the units escaped a difficult fight with minimal losses and their retreat to buildings or friendly units not only scattered my army but also turned the fight in their favour.

What you are saying may be right in a clean contest where no other factors come into play, but in a game like this, where you can exploit buildings and movement, I think it could work.

[wraitii]

Thanks for the answer Quantumstate... I guess I'll have to copy the code in a modified way for my unit/building managers, but i'll use entitycollections for the enemyWatchers.

Retreat must be dealt with for small raids if you want to keep the army... For anything else, unless a specific unit must be preserved, it can be overlooked, I think.

[wraitii]

I suggest, in entity.js, replacing the "ressourceSupplyAmount" and "RessourceCarrying" function by those, who check whether those parameters are defined:

	resourceSupplyAmount: function() {
		if(this._entity.resourceSupplyAmount == undefined)
			return undefined;
		return this._entity.resourceSupplyAmount;
	},

	resourceCarrying: function() {
		if(this._entity.resourceCarrying == undefined)
			return undefined;
		return this._entity.resourceCarrying; 
	},