EggPlant AI ramblings

[Rman Virgil]

.

....

how you figure an advantage if all start the same - newbie to "pro" ?......

It is a start of game level playing field so there is none.

Here, it is something else. It's called Selective Exposure in cognitive science and - it prevails.

.

[aubergine]

So, because of this discussion, I'm trying to work out how to make an AI adapt its research based on what the opponent is doing.

I'm running in to lots of problems:

* I can't work out what sort of units the enemy is producing
* Even if I could, I don't know what research adaptations would be needed to be effective against that enemy
* And if there are multiple enemies on a map, which one do I use to determine what I should research?

Short of attaching Illuvar's brain to my AI via synaptic link, I'm stumped.

Any ideas?

[Emdek]

aubergine, for second point you would need create hash of goals (predefined data structure with data what to research if enemy has specified weapon / droid type), for paper vs rock vs scissors strategies.
For third one: the closest, most advanced or that one which appears to try to attack AI's base (or anybody bases, if you have data to detect that event).

[aubergine]

From map data I should be able to get some idea as to who is attacking who on the map, and who has the most units. If the API starts to expose more data about units, etc., (eg. propulsion, body, turret) then I can probably determine what research branch a player is using and might be able to guesstimate how far they are in to that branch.

My main issue is trying to categorise the research tree and then build up that hash of goals. From reading other topics, I can see that there are some obvious branches like machine guns, cannons, rockets, flamers. However, I don't know how all the lines interrelate, at which point is a change in research direction good or bad, what research is the rock to the enemy's scissors, etc.

I'm also guessing that map type will have an effect - currently the only data I have about a map from the JS API is it's width/height/name. I don't have any data about continents, or what sort of terrain is prevalent on the map (eg. if mostly water I want to be using more hover/vtol).

[Emdek]

Yep, research tree is another wild animal, however your needs a bit converge with my proposition for research queue with would contain some goals, maybe in that case we could gather data what is best to fight with other weapon types (some data already exists as descriptions - best targets, but need other form for JS scripts to be usable).
To get map type etc. you could iterate through all tiles at start and guess by title types, but such things would be more efficient as "in engine" code.

[aubergine]

As far as I'm aware, the JS API doesn't currently expose tile data of any kind. I can enumerate through objects (features, droids, structures) but not actual map tiles.

[Emdek]

Well, then we need one.
Also I think (I'm not sure how it is done right now) functions should be grouped into objects, like Maps.tile(x, y), Game.time(), Players (array) etc.

[aubergine]

Yup, I'm creating objects like that in EggPlant, but I need to finish vQuery first (and before that I need to finish my JS API docu site that I started for some unknown reason).

The stack looks something like this:

Code: Select all

EPAI - EggPlant AIs
  ^
EPOM - EggPlant Object Model
  ^
vQuery - jQuery-esque selectors
  ^
VAULT - object storage
  ^
JS API - WZ Javascript API
  ^
Warzone 2100

VAULT includes about 100 object wrappers that extend almost every type of game object with useful functions and properties.

VAULT also provides a new extensible event system - the diagram below shows part of it. The plan is to make EggPlant almost completely event driven and use as few timers as possible.

[Emdek]

So, now we need to convince Per that this is good idea.
Also, existing scripts could be converted easy, we could even introduce kind of comment based file headers (also good for storing author data etc., to display somewhere maybe) which could contain information about used API level (if it will be introduced), so simple string replacing could auto convert older ones to current API.

Also, using diagrams is good idea in such posts, also from "marketing point of view".

[aubergine]

I think the JS API should continue on it's current direction - in other words a bunch of functions, constants, globals and events, rather than some cohesive model. The JS API is then the core foundations on which JS devs can design their own wrappers and try out different approaches and making abstraction layers, some of which will work well, others will fail horribly.

So far, I've created detailed documentation for most of the JS API - here's one of the index pages:

[Emdek]

The point of using "prefixes" is to make it more future proof and consistent, also with JavaScript conventions (like Math.something()), such global objects maybe even could (or should) use WZ prefix, to be 100% future safe (well, it is hard to imagine JS introducing such names, but in times when they make it possible to make browser based photo booth then everything is possible).
Also to avoid possible name conflicts, if one function name would make sens in more than one object (especially when allowing to script UI etc.).

[aubergine]

Yes, but until the JS API is given time to mature (at least 12 months I'd say) it's not going to be clear what sort of prefixes, etc., should be made. If more JS devs come up with their own abstraction layers, we'll see which ones work best and can then possibly use that as the basis of a future JS API.

I've been using wz prefix for my Vault objects wrappers, here's an index page from the vault documentation:

[Emdek]

Yep, I also suggested marking current one as purely experimental and redo it for next big release.

[Rman Virgil]

.
Nevermind, my bad.

Oh yea, dots connected & ... mighty nice.
.

[milo christiansen]

One thing: How MP/SK specific is the vault? If I wanted to use it in the cam4 JavaScript port would I run into all sorts of annoying assumptions?

I know it's not done yet but nether am I ready to start porting