Behaviour AI System v1.5

Moderator · Feb 24, 2014

22:08, 6th Jul 2014
PurgeandFire: (old) Review:
http://www.hiveworkshop.com/forums/2552185-post29.html

Changes made, approved. Great AI system!

gorillabull · Feb 24, 2014

this can bring more life into any map, great success

Kingz · Feb 24, 2014

I am contemplating of adding a check whether a unit is controlled by a user or computer to not have odd unit actions of players own units.

I am waiting to see more feedback tho.

Malhorne · Feb 24, 2014

JASS:

private static method create takes nothing returns thistype
        local thistype this = thistype.allocate()
        return this
endmethod

->

JASS:

private static method create takes nothing returns thistype
        return thistype.allocate()
endmethod

Or simply don't write it since JASSHelper will generate it.

Kingz · Feb 24, 2014

Will probably convert the methods into functions since they are all static and scrap the struct model it is using atm.
I am holding it in a struct form only until i figure out if there is any point in doing so since im not really using any of it's feature.
If people throw some ideas at me which would use the struct for anything id probably keep it, maybe for some extensions on the system.

Thanks for the feedback tho.

Malhorne · Feb 24, 2014

No problem at all.
I'll review again if you change the format (I didn't finish but don't have the time atm)

BPower · Feb 24, 2014

I wouldn't use stub methods, yet I'm certainly not demand a change here.
You may face criticism, as many people here try to enforce a higher efficency.

I've been working alot on better AI behaviour over the last month for a project of mine.
I turned out to be extremly powerful, but can only used for RPG maps (1-x heroes vs mosters). Admittedly it does only support AI for each UnitTypeId and can't work different for two units of the same type.
My approach is 100% different to yours and I'm really excited how this one will develop over the next time.

I will release my version aswell as soon as it has a better API.

Btw 0.1 timeout is a really short interval for AI responses. I mean 600 potential actions per minute is a lot! No player can do so not even half.

Kingz · Feb 25, 2014

That is quite nice to hear as we lack AI systems on THW.
I am still in the process of modding this AI interface and model and i am mostly looking in for feedback at this point of development.

I have been thinking of developing an OrderQueue which would be able to index unit orders and decided based on their priority what to do, with an aging factor.
So for example you define multiple behaviours which issue orders, you then put them in the queue and as time passes the orders in the queue gain in priority so you start seeing pseudo random acts.
Tho this would require remembering only the recent n orders (where n would be < 10 for common sense sake).

I am not sure if i want to make it that complex yet.

Zwiebelchen · Feb 27, 2014

This thing has a great synergy with this:
http://www.hiveworkshop.com/forums/...tem-2-6-a-156179/?prev=status=a&u=Zwiebelchen

You can use ZTS to handle all the basic attacking and apply threat based on the "value" of an action and then use this AI system to do dynamic responses based on the threat tables.

Kingz · Feb 27, 2014

Yes i think it does provide a nice synergy.
Users could implement that system, and then in their handler methods issue orders at the units with most threat.

I will probably add an example to the map and link it for future reference.

Atm i am thinking of doing a CustomOrder struct to allow priority order selection from user methods and internal cooldown handling.
Something like this inside a user method:

JASS:

call CustomOrder.register(orderedUnit, orderString, cooldown) // registers the order inside a table
if(CustomOrder.canIssue(orderedUnit, orderString)) then // checks the order for it's internal cooldown
 call CustomOrder.targetOrder(orderedUnit, orderString, targetWidget, priority) // order is valid, adds it as a contender for execution, if it isn't executed the internal cooldown won't be triggered
endif

Then after going through all behaviours it would execute the order which had the highest priority and ignore the rest or maybe queue them up?
Anyhow after the order would be issued it's internal timer would reset.

I will probably make it optional so users can still use normal orders if they want to.

Anachron · Feb 28, 2014

ForGroup are so damn slow callbacks

Zwiebelchen · Feb 28, 2014

Anachron said:
ForGroup are so damn slow callbacks

Yeah but in this case, it makes sense to use ForGroup simply because you want the different threads to avoid operation limit for larger numbers of units.

BPower · Feb 28, 2014

ForGroup are so damn slow callbacks

How to avoid ForGroup and use FirstOfGroup:
- Make linked lists of size i.e 10.
- Units in one list are considered friendly.
- Once unit is activated the system checks for close allied groups/list, if they are not full the unit is pushed into that list.
- Units beeing pushed into a list by activation event (DDS, EVENT_UNIT_AQUIRE_TARGET, ...), also activate nearby allies. Those will be pushed into the same list ignoring the size limit.
- Each list has its own timer to evenly spread actions. i.e NewTimerEx(list), avoiding the op limit and reducing laggs to zero.
- Units are only part of the list for a specific time i.e 20 seconds. Incoming damage, unit events refresh the time member. When time hits < 0 they are removed from the list. Once the list is empty it gets destroyed and the timer will be stopped /released.
- Clock timeout can be huge for instance 2.5 seconds.

A list size of 10 probably won't have a noticeable impact on the game perfomance at all. Also they allow intelligent group behaviour (surrounding, positioning, helping ...)
The big advantage is that if noone is fighting the system does absolute nothing. No function call, no timers, nothing

Some thoughts out of my own Threat system:
- The loop only collects information (Alive, x, y, facing, life%, target, target x, target y, angle, ..) other members are set once the unit get pushed into the list (UnitId, UnitIndex, ranged or meele, ...).
No locals all of these are struct members.
- Use one or two spam protection member (integers). Units which just performed an action should be ignored for x loops.
- User can define pluggins (modules/textmacros) which can be implemented into the loop like HelperPluggin, EngagePluggin, ...

JASS:

            loop
                if UnitAlive(who) then
                    /*
                    *   Each units is only part of the loop for
                    *   THREAT_TIME seconds.
                    */
                    set time = time - CLOCK_TIMEOUT
                    /*
                    *   Spam protection for engage response event.
                    */
                    set spam_protection = spam_protection - 1
                    /*
                    *   Last taken damage is only stored for 3
                    *   clock timeouts
                    */
                    set counter = counter - 1
                    if (0 > counter) then
                        set lastDamage = 0
                    endif
                    /*
                    *   Some actions require more than
                    *   1 clock timeout, hence pause was implemeneted.
                    */
                    if (0 < pause_threat) then
                        set pause_threat = pause_threat - 1
                    elseif NotStunned(who) then
                        /*
                        *   Gathering information for the Threat unit.
                        */
                        set who_x = GetUnitX(who)
                        set who_y = GetUnitY(who)
                        set life  = GetWidgetLife(who)/state
                        set e     = (aim != null) 
                        
                        if e and UnitAlive(aim) then
                            set aim_x = GetUnitX(aim)
                            set aim_y = GetUnitY(aim)
                            set angle = Atan2(who_y - aim_y ,who_x - aim_x)
                        else
                            set e = false
                            set lastDamage = 0
                        endif
                        /*
                        *   The flee pluggin pauses the unit for 2 clock timeout.
                        *   Certainly not finished yet ....
                        */
                        //! runtextmacro optional THREAT_RETREAT_PLUGGIN()
                        /*
                        *   The helper pluggin is checking for injured units.
                        */
                        //! runtextmacro optional THREAT_HELPER_PLUGGIN()
                        /*
                        *   Per loop only 1 unit performs a unique action. d is a local boolean which will become false within then POSITION_PLUGGIN
                        */
                        if d then
                        /*
                        *   The position pluggin checks if the target should be
                        *   surrounded or demands a special assault tactic.
                        */
                        //! runtextmacro optional THREAT_POSITION_PLUGGIN()
                        endif
                        /*
                        *   Action response fires individual unit spells
                        */
                        //! runtextmacro optional THREAT_ACTION_RESPONSE_PLUGGIN()
                    endif
        
                    if (0 > time) and (0>spam_protection) then
                        call display(false)
                        call remove()
                    endif
                else
                    call display(false)
                    call remove()
                endif
        
                set this = next[this]
                exitwhen 0 == this
            endloop

How to fire events, making every unit unique:
Use Table like Bribe did in SpellEffectEvent, based on UnitTypeId.

JASS:

    function RegisterThreatEngageEvent takes integer id, boolexpr expr returns nothing
        if not Threat.ENGAGE.handle.has(id) then
            set Threat.ENGAGE.trigger[id] = CreateTrigger()
        endif
        call TriggerAddCondition(Threat.ENGAGE.trigger[id], expr)
    endfunction

    if Conditions and OtherConditions then
         set Threat.current = this//readonly static thistype current  
         call TriggerEvaluate(Threat.ENGAGE.trigger[this.id])

Allows

JASS:

private function FootmanResponse takes nothing returns boolean
    local Threat threat = Threat.current
    local Charge charge = Charge.create(threat.who, threat.aimX, threat.aimY, ...).
    set charge.damage = 100.
    set charge.duration = 15.
    //
    set threat.spam = 4//method operator spam, this unit is now ignored for the next 4 loop

That's some of the stuff I did in my Threat system.
Furthermore single unit events are better than player_unit_events. Couple UnitIndexer, a onFilter method and a modified version of TriggerRefresh to rebuild triggers for an excellent result.

Kingz · Feb 28, 2014

The ForGroups aren't spammed that often, i will push the timer to 0.3 or 0.5 interval and cleanup timer is already running only every 60 seconds. So in one minute there will be about 121 calls to it.
If that however makes a hit on performance i will consider alternatives.
I will probably do some stress tests with a large number of units inside the group and look for the optimal cleanup / tick intervals when i get the time.

I noticed a flaw in my documentation/implementation.
Periodic behaviour for unit types will only trigger for units already inside the UNIT_POOL group.
This could be offseted if i indexed all units always on map entering, or created a trigger which would add the unit to the group when entering the map if there is a behaviour for such a unit defined which is probably gonna be implemented in the next version.

Tho i will still have to add all units of type to UNIT_POOL after calling the attachBehaviourType already present on the map which aren't in the group, or again leave it to the user.

I could switch from ForGroup handling to a GroupEnum condition handling probably, if it would make a big difference.

Edit:

I thought about implementing a Threat system inside the AI but i decided to leave it to the end user, since it's way easier to add one to those who need one than it is to modify one out for those who don't.

So atm i am focusing on the CustomOrder thingy to see how will it play out, will leave it optional tho.

Edit2:

I heard that the trigger destruction errors are now a thing of the past since the return bug is no more, i think i read it on TheHelper.net.
If true it would mean that you wouldn't need to recycle triggers and could just recreate them.

Furthermore single unit events are better than player_unit_events. Couple UnitIndexer, a onFilter method and a modified version of TriggerRefresh to rebuild triggers for an excellent result.

Can i ask you for the source of this discovery? First time i hear about it. (unit specific > player unit specific thingy)

BPower · Feb 28, 2014

Can i ask you for the source of this discovery? First time i hear about it. (unit specific > player unit specific thingy)

I'm talking about for exmaple EVENT_PLAYER_UNIT_ATTACKED vs. EVENT_UNIT_ATTACKED
the latter will only fire, if that specific unit is attacked, while the other one is fired if any unit is attacked.

Yes you can rebuild a trigger by simply recreating it and re-register all conditions.

Kingz · Feb 28, 2014

My initial design did include trigger evaluations and conditions also but i scrapped it because you cannot remove conditions dynamically as far as i remember without recreating and re-registering other conditions.

Unit specific events do work nice when there is trigger recreation, however if you for example wanted to change the AI of a boss by removing some old behaviour and adding new ones at some points of the fight you would have to recreate the trigger.
I opted for a simpler solution.

Kingz · Mar 2, 2014

Bump for update notice:

Users can now (if they wish) add prioritized orders with internal cooldowns to their behaviour structs.
This is limited to specific units at the moment, if you wish to make it work with unit types there is an example showing how to. (do note this causes some unneeded calls as you need to add a CustomOrder.registerOrder() call in behaviour methods before calling a specific registerOrder$Target/Point/Instant$ method)
If you wish to update the cooldowns you can do so at any time by calling the CustomOrder.registerOrder() method for the specific unit, do note, you CANNOT reset an internal cooldown.
User can also indicate whether he wants the AI to apply on user units also or just non human controlled units.

NOTE: CustomOrder struct is meant to be used exclusively with the system, it will NOT be generated at all if you say so in the configuration (static if). Calling any method of the struct while specifying you do not wish to use custom orders will result in compile errors.

Custom orders will always take priority over user issued orders due to them being issued last.

Next update will probably show how to use this with a threat system and will contain quality of life changes.
The BAIS Extension library is an optional library i am thinking of developing which can extend the system to allow ally methods. This is still not confirmed.

As always any reports considering more efficency are fairly welcome.
Edit:

Another plan for next update is prevention of preemption, that is an custom order taking over while a different custom order is executing.
Will have to modify the canOrder method for that.

Can't think of a good way to do this, scrapped the idea for now.

Edit:

v1.3 updated
New test map, ZTS threat system included in the test map to show how would you set it up along something like this.
Both player and AI forces are now equal, try to see if you can outmicro the enemy heroes and win.
I might include proper functions for use with ZTS and custom orders later (since a registered order may not be issued it would be wrong to add threat anyway), but BPower is working on a threat system also so i am gonna wait and see how that works out.

TriggerHappy · Mar 8, 2014

Hey, nice idea. I have some code suggestions for now.

You should be using thekeyfor your key constants.
GetHandleIdandOrderIdcalls should be stored inside a local, to avoid so many unnecessary function calls. The sames goes for the rest of the functions, but those are the ones that stood out.

I don't see the point of this.

JASS:

local integer pkey = GetUnitTypeId(u)
local integer uid = GetUnitTypeId(u)

You need to null all struct members which are handles, to prevent leaking.

Kingz · Mar 8, 2014

TriggerHappy said:
Hey, nice idea. I have some code suggestions for now.

You should be using thekeyfor your key constants.

GetHandleIdandOrderIdcalls should be stored inside a local, to avoid so many unnecessary function calls. The sames goes for the rest of the functions, but those are the ones that stood out.

I don't see the point of this.

JASS:

local integer pkey = GetUnitTypeId(u) local integer uid = GetUnitTypeId(u)

You need to null all struct members which are handles, to prevent leaking.

Thanks for the review, will fix those things asap.
Edit:
v1.4
Updated code.

Using

JASS:

key

throws error in my JNGP for some reason so it stayed a constant integer.
Removed as much redundant calls as i could track down and stored them into locals, didn't bother storing them into locals where there was only one call.
Nulled struct members in onDestroy method, all leaks should now be covered.

Edit:
According to a THW member a "Double free of type: CustomOrder" messages seem to appear.
I will look into this, probably calling a destruction somewhere where it is not needed.

BPower · Mar 23, 2014

Looks quite nice. You could restructure your code and put methods beeing called from other methods above them.
In structs it is possible to call any method no matter the position, because vJass generates a copy if that method in question is below.
Basically just needless extra code is generated.

if UnitAlive(unit) == false then --> if not UnitAlive(unit)
In general boolean == true --> boolean // boolean == false --> not boolean

Maybe you could run a stress test to see how this system performs for let's say ~50 -100 units.

A few comments in the example code would be a win. Just comment in 3 or 4 lines how you set up the unit/hero.

Kingz · Mar 26, 2014

I am bussy with some shool projects, update won't be soon.

BPower · May 8, 2014

It's quite a good system. I'll leave this for now as pending.

Kingz · May 13, 2014

I will see if i get the time to update this this weekend, if not will be some time because uni is keeping me busy a lot.

rezurect15 · May 16, 2014

Interesting.... I'll keep track on this one... nice work bro..

Johnromar09 · May 19, 2014

i copied it in a new map,but
Why is this?
cause i'm no expert in triggers

pred1980 · May 21, 2014

You have to use the JNPG Editor instead of the normal World Editor. This system is written in vJass.

Johnromar09 · May 25, 2014

Ok, Thanks

Kingz · Jun 19, 2014

Update coming 3rd or 4th week of july.

PurgeandFire · Jul 7, 2014

When you update it, here are a few things for you to do:

Move clean, castHandler, deathHandler, loopHandler, and ddHandler all above onInit so that jasshelper won't generate a bunch of extra code.
Make a separate library with Behaviour spelled as Behavior for the non-Brits. (jk)

This:

JASS:

set i = LoadInteger(thistype.UNIT_DATA, pkey, DEAD_KEY)
set i = i + 1
call SaveInteger(thistype.UNIT_DATA, pkey, DEAD_KEY, i)

Can be:

JASS:

set i = LoadInteger(thistype.UNIT_DATA, pkey, DEAD_KEY)
call SaveInteger(thistype.UNIT_DATA, pkey, DEAD_KEY, i + 1)

You can also make it a one-liner, but that hurts readability.

Move handleUnit above loopHandler.
When you use the textmacros, you always have to redeclare a variable for offset, behavior, i, etc. You may want to consider making globals for them (non-configurable) so that the code becomes simpler. It is good to avoid repeated code, whenever possible.
Just for future reference, for static variables you can always just use type the name without the thistype. e.g. thistype.UNIT_DATA -> UNIT_DATA. It might help with readability. In general, I would recommend JPAG's convention (all caps for constants, but regular globals are camelCase -> unitData), but that isn't required for the spell section.

You can consolidate this:

JASS:

    public static method removeBehaviour takes unit u, Behaviour b returns boolean
        local integer pkey = GetHandleId(u)
        local integer offset = LoadInteger(thistype.UNIT_DATA, pkey, OFFSET_KEY)
        local integer i = 0
        local Behaviour temp = 0
        loop
            exitwhen i >= offset
            set temp = LoadInteger(thistype.UNIT_DATA, pkey, DATA_KEY+i)
            if(temp == b) then
                set temp = LoadInteger(thistype.UNIT_DATA, pkey, DATA_KEY+offset-1)
                call SaveInteger(thistype.UNIT_DATA, pkey, DATA_KEY+i, temp)
                call SaveInteger(thistype.UNIT_DATA, pkey, OFFSET_KEY, offset-1)
                return true
            endif
            set i = i +1
        endloop
        return false
    endmethod
    
    public static method removeBehaviourType takes integer ut, Behaviour b returns boolean
        local integer pkey = ut
        local integer offset = LoadInteger(thistype.UNIT_ID_DATA, pkey, OFFSET_KEY)
        local integer i = 0
        local Behaviour temp = 0
        loop
            exitwhen i >= offset
            set temp = LoadInteger(thistype.UNIT_ID_DATA, pkey, DATA_KEY+i)
            if(temp == b) then
                set temp = LoadInteger(thistype.UNIT_ID_DATA, pkey, DATA_KEY+offset-1)
                call SaveInteger(thistype.UNIT_ID_DATA, pkey, DATA_KEY+i, temp)
                call SaveInteger(thistype.UNIT_ID_DATA, pkey, OFFSET_KEY, offset-1)
                return true
            endif
            set i = i +1
        endloop
        return false
    endmethod

Into:

JASS:

    private static method removeBehaviourEx takes hashtable hash, integer pkey, Behaviour b returns boolean
        local integer offset = LoadInteger(hash, pkey, OFFSET_KEY)
        local Behaviour temp = 0
        local integer i = 0
        loop
            exitwhen i >= offset
            set temp = LoadInteger(hash, pkey, DATA_KEY + i)
            if (temp == b) then
                set temp = LoadInteger(hash, pkey, DATA_KEY + offset - 1)
                call SaveInteger(hash, pkey, DATA_KEY + i, temp)
                call SaveInteger(hash, pkey, OFFSET_KEY, offset - 1)
                return true
            endif
            set i = i + 1
        endloop
        return false
    endmethod

    public static method removeBehaviour takes unit u, Behaviour b returns boolean
        return removeBehaviourEx(UNIT_DATA, GetHandleId(u), b)
    endmethod
    
    public static method removeBehaviourType takes integer ut, Behaviour b returns boolean
        return removeBehaviourEx(UNIT_ID_DATA, ut, b)
    endmethod

I wonder if it is possible to somehow consolidate the macros a bit as well. I don't know. Food for thought.

This:
JASS:
```
        method onDestroy takes nothing returns nothing
            set target = null
            set source = null
        endmethod
```
Can become:
JASS:
```
method destroy takes nothing returns nothing
    set target = null
    set source = null
    call this.deallocate()
endmethod
```
The method above rewrites the destroy method. The onDestroy method uses a trigger evaluation to evaluate the code whenever an instance of the struct is destroyed. That is only useful for polymorphism, so it is better to just rewrite the destroy method. Also, you should put it above your other methods to make sure it won't make any extra code.

The "register<>Order" functions can be consolidated as well. Simply make a big helper function and then use the other 3 as wrappers to call it:

JASS:

        private static method registerGeneralOrder takes unit u, widget target, string orderstr, real x, real y, integer priority returns boolean
            local thistype co
            local integer saved_prio
            local integer pkey = GetHandleId(u)
            if(thistype.canOrder(u, orderstr) == false) then
                return false
            endif
            if(HaveSavedInteger(thistype.ORDER_DATA, pkey, ORDER_KEY) == true and LoadInteger(thistype.ORDER_DATA, pkey, ORDER_KEY) != -1) then
                set co = LoadInteger(thistype.ORDER_DATA, pkey, ORDER_KEY)
                if(priority > co.priority) then
                    call co.destroy()
                    set co = CustomOrder.create(u, orderstr, target, x, y, priority, false)
                    return true
                endif
            else
                set co = CustomOrder.create(u, orderstr, target, x, y, priority, false)
            endif
            return false
        endmethod

        static method registerTargetOrder takes unit u, widget target, string orderstr, integer priority returns boolean
            return thistype.registerGeneralOrder(u, target, orderstr, 0, 0, priority)
        endmethod
        
        static method registerPointOrder takes unit u, real x, real y, string orderstr, integer priority returns boolean
            return thistype.registerGeneralOrder(u, null, orderstr, x, y, priority)
        endmethod
        
        static method registerInstantOrder takes unit u, string orderstr, integer priority returns boolean
            return thistype.registerGeneralOrder(u, null, orderstr, 0, 0, priority)
        endmethod

Feel free to take your time. This looks like a promising system! I might have a bit more to review, but that should be enough for now.

Kingz · Jul 7, 2014

Thanks purge, much appreciated.

Kingz · Jul 11, 2014

Code updated with suggestions made by PurgeandFire, excluding:

Just for future reference, for static variables you can always just use type the name without the thistype. e.g.

Reasoning: I prefer clearly defining what is a static variable by putting thistype. in front of them, makes it easier to understand and follow imo.

When you use the textmacros, you always have to redeclare a variable for offset, behavior, i, etc. You may want to consider making globals for them (non-configurable) so that the code becomes simpler. It is good to avoid repeated code, whenever possible.

The macros use local variables when expanded, i do not see the need for globals. You wouldn't use a global var for looping for example.
I might have not understood your comment tho, feel free to elaborate.

Anyway, real changes (Ally and Enemy extensions) are under consideration i guess?
I feel like maybe it would stress the system too much and allow for infinite loops if configured badly so it could destabilize the system.

Edit:
Thinking of adding a helper library:

JASS:

library BAISHelper requires BAIS
/************************************************************************************************/
/*  Behaviour AI helper                                                                         */
/*  by Kingz                                                                                    */
/*                                                                                              */
/*                                                                                              */
/*  Info:                                                                                       */
/*  Provides constant methods for getting source/target units for BAIS stub methods             */
/*                                                                                              */
/************************************************************************************************/

struct BAISHelper

    static constant method getDamageTakenSource takes nothing returns unit
        return GetEventDamageSource()
    endmethod
    
    static constant method getDamageTakenTarget takes nothing returns unit
        return GetTriggerUnit()
    endmethod
    
    static constant method getDamageDealtSource takes nothing returns unit
        return GetEventDamageSource()
    endmethod
    
    static constant method getDamageDealtTarget takes nothing returns unit
        return GetTriggerUnit()
    endmethod
    
    static constant method getCastUponSource takes nothing returns unit
        return GetTriggerUnit()
    endmethod
    
    static constant method getCastUponTarget takes nothing returns unit
        return GetSpellTargetUnit()
    endmethod
    
    static constant method getOnDeathSource takes nothing returns unit
        return GetKillingUnit()
    endmethod
    
    static constant method getOnDeathTarget takes nothing returns unit
        return GetTriggerUnit()
    endmethod
    
    static constant method getOnKillSource takes nothing returns unit
        return GetKillingUnit()
    endmethod
    
    static constant method getOnKillTarget takes nothing returns unit
        return GetTriggerUnit()
    endmethod

endstruct

endlibrary

But not sure if needed, i think it might be useful for some people.

Edit2:

I am open to suggestions about adding more functionality, if anyone has any ideas feel free to say.

Edit3:

Forgot to change boolean == false to not boolean. Will make that change in the next version.

Edit4:

Thanks for approval Purge.

Nestharus · Sep 4, 2014

I think that local/global behaviors would be trivial with Trigger. It would improve your API and add some more flexibility too. Give it some thought

. What's especially cool is that you could inherit behaviors and build on top of them. You could also create behavior plugins, a set of behaviors, and easily add this set to a unit or set of units. There is just a lot ;D.

Kingz · Sep 5, 2014

Nestharus said:
I think that local/global behaviors would be trivial with Trigger. It would improve your API and add some more flexibility too. Give it some thought . What's especially cool is that you could inherit behaviors and build on top of them. You could also create behavior plugins, a set of behaviors, and easily add this set to a unit or set of units. There is just a lot ;D.

I will be honest and say that improvements are probably possible (like removal of stub methods) but i feel like the current api is really simple to use.

You can already inherit behaviours by extending an existing behaviour struct i think (didn't test to be honest and haven't looked at this in some time).
If someone wishes to make a more effective AI system based on this code they are free to do so, as we do lack AI systems on THW.

And id rather not complicate the code, it's really easy to use atm if you have any knowledge of jass, adding behaviour plugins, behaviour sets and such things might just make it harder to use (but more modular).

So if you think it deserves an upgrade Nes, you are free to build atop this or write your own AI system, more of them certainly wouldn't hurt.

Thanks for the opinion tho.

mr po · Dec 8, 2016

the game cant play the map

Behaviour AI System v1.5

Behaviour AI System (Map)

Moderator

Moderator

Attachments

Similar threads