Java AI interface suggestions

[Tobi]

I'm messing around with Java AI interface, and I stumble upon some walls occasionally when trying things out.

Hoijui already knows some of these, but I thought it would make sense to document them a bit better, and offer others the chance to give input too.

Also I'd like to say that having this interface available is really epic win, good job hoijui

So here are my comments:


Unit testing - 1

Unit testing anything significant in a Java AI is currently not possible*, because the com.springrts.ai.oo classes can not be instantiated outside the AIInterface package. Even if they could be instantiated, they couldn't be used because they depend on a running instance of Spring.
*unless I make boring proxy classes for everything in com.springrts.ai.oo


My request is to generate for all classes not only the class, but also a public interface, to allow creation of mock objects, which in turn allows unit testing.

For example, what is now the Unit class, would become an UnitImpl class that implements a public Unit interface. All public functions would refer to the interface only, instead of referring explicitly to UnitImpl. (I assume internally only getUnitId()/getUnitDefId()/etc. are needed.)


Unit testing - 2

With the above in place at least unit testing is possible, but one still needs to make mock objects. Since I think these mock objects would be nearly identical for everyone who wants them, and it should be relatively easy to generate those, they should be included IMO.

They could just consist of a field and a getter/setter for every get* method in the respective interface.

E.g.

Code: Select all

package com.springrts.ai.test;
import com.springrts.ai.oo.Unit;

public class MockUnit implements Unit {
  private float[] pos;
  public void setPos(float[] pos) {
     this.pos = pos;
  }
  @Override
  public float[] getPos() {
     return pos;
  }
  // etc.
}

OOAIFactory access problems

Now I was trying to get rid of duplication because of the different but quite similar events, since I've lots of forwarding/filtering of events in the design I have in mind. (based on C.R.A.I.G.)

• unitCreated
• unitFinished
• unitDamaged
• enemyEnteredLOS
• enemyLeftLOS
• etc.

I wanted to do this by using a class for each event, and creating a single method interface similar to this:

Code: Select all

interface {
  void gameEvent(AIEvent event);
}

However, first issue I faced is that OOAIFactory isn't extensible. Because it's properties ais and ooClbs are private, I can not simply override handleEvent and supply my own customized implementation of it.

Suggested fix: Make OOAIFactory.ais and OOAIFactory.ooClbs protected, or offer public or protected accessors that return (readonly views of) these maps.

Then, I tried to just copy the OOAIFactory class (as this implements AI, just like NullJavaAI), but this didn't work because OOAICallback.getInstance is not visible outside the AI interface package. So it seems I do not have access to all the OOAICallback functionality unless I use OOAIFactory...

Suggested fix: make OOAICallback.getInstance public, or offer some other way to get/create an instance of this class.

EDIT: hmm, this applies to Unit.getInstance too. So AFAICS it's currently impossible to reuse the event classes in any way, I can only copy/reimplement them all, and then instantiate them in the OOAI.unitCreated/unitFinished etc. methods. (Resulting in a chain of conversions: event class based->method based->event class based.)


AIEvents

This is a bit more controversial suggestion; maybe it's too specific to my AI ideas.

I've noticed the fields of this class are just public and there are no getters. Also I've noticed this is a quite flat inheritance hierarchy and it's without any interfaces. Many of the events are quite similar however.

Hence, for reasons mentioned above, I would like it if similar events would implement the same interface. E.g. all Unit*AIEvent would implement the interface UnitAIEvent { Unit getUnit(); }, all Enemy*AIEvent would implement the interface EnemyAIEvent { Unit getEnemy(); }, etc. Note also the similarity between EnemyDamaged and UnitDamaged, and UnitGiven and UnitCaptured.

Having such common interfaces available would really ease filtering events when one implements them as I mentioned above.

For example, I could then just do something like:

Code: Select all

unitSpecificEvents.get(unitEvent.getUnit()).gameEvent(event);

Instead of a bunch of if it's this event, cast to this event's type and get unit, if it's that event, cast to that event's type etc.
(In Lua this was really easy due to the dynamic nature of the language )

[hoijui]

ok...
the second unit testing thing could be done already.

the others two things i do not really want to mess with, as it will get very diferent anyway, once i am done with the move to float[3]. actuay, this refactor will change some other things too, and in case i want to merge master back in.. it will get a pain, and would mean quite some additional work.
i already agreed to the first unit testing suggestion (though i do not know yet how to supply default values for a MockObject, but that is a detail).
Best is, if this thread could be pumped once the refactor is done.

edit:
made the getInstance() method public (for all classes).
be awayre though: the event classes will most likely not be there anymore after the refactor, so if you use them, you will have to change your AI again when its done.
so far, put only efforts into the redesign of the callback and commands, and did not mess with the events. will have to think about that. do not yet know whether to call java methods from the native part or create event class instances. anyway, for a less flat hirarchy model, we would need a new meta data model for the events (-> describe the hirarchy with in C comments)