I meant as in before the AI does anythign that is affected by it, so say before any commands are given.
I'd say that checking every frame would be a shortfix till an engine change is made.
Besides I'd rathr build ym own unti than risk an even mroe expensive unit trying to capture an enemy version.
Better to resurrect enemy untis if you want their tech.
ZcAIn introduced - 0.02
Moderators: hoijui, Moderators
some design tought that I've done now that the basic of the ai are working (well, almost)
courtesy of bouml (freeware modelling tool)
well, I know it's not soo clear.
Te idea is a deferred event loop and intelligence at the base of the chain.
so the event parser basically "understand" what is going on, event handler
distribute appropriate event to "whom it may concern". The unitmanager make sure that every task handler could access the needed unit, provides a locking mechanism; the unit starts all locked by the taskhandler that builded them, and released when it feel so. this means that everybody shares the resources of the builders. the unitmapper takes care of make it work, and provides helper function to loockup necessary builder to build particular units. The task are sequence of command (in a spring sense: command.h), but those command are interpreted in two pass: first the task are bound to a zone, so the build site is decided to be the most useful for this zone (so base zone couls put turret on front, factory in the middle and resources on back, where front and back depends from the dispusition of other zones - especially the enemy_attacked_from_there zone). then the command is readed by the task handler wich find the best way to accomplish it: if is a move command then take care of moving the group preserving formation (artillery back, for example) if is a build command will take care of finding the necessary builders or building them if not avaiable, and so on.
And then there is the zonemanager, the core of the ai where the magic of interpreting data into areas is done.
the strong point of this approach is that we have a centralized event driven way for process intercomunication, a sort of threaded messaging without the hassle of build it. The task/ticket system ensures that every taskhandler get the control of what it builds for first, the relase mechanism provide some way to provide other task with already avaiable units, the eventparser interpreting the world takes care of low energy or low metal situations raisin "build mex/plant" tasks.
some more details on the factory/pattern: as generic event raises (low energy, for example) we need a system to build task to cope with ever changing situations. the patterns are the ai "knows solution" for common problem, wich all toghether build up the I of the AI. for example a pattern for low metal is mex/mex or for energy is solar/solar or if low energy and low metal wind/wind/mex and so on.those task also come with a "strategy" wich is "build" in the three latetr case, and could be scaut raid attack defend for unit group. thanks for zaphod for the idea. so we could have a fark/fark assisting or a stumpy/stumpy raiding and so on. the Factory takes care of selecting the appropriate task basing on it cost/return value. (return icould be seen similar of the "level" of the zaphod unit groups)
courtesy of bouml (freeware modelling tool)
well, I know it's not soo clear.
Te idea is a deferred event loop and intelligence at the base of the chain.
so the event parser basically "understand" what is going on, event handler
distribute appropriate event to "whom it may concern". The unitmanager make sure that every task handler could access the needed unit, provides a locking mechanism; the unit starts all locked by the taskhandler that builded them, and released when it feel so. this means that everybody shares the resources of the builders. the unitmapper takes care of make it work, and provides helper function to loockup necessary builder to build particular units. The task are sequence of command (in a spring sense: command.h), but those command are interpreted in two pass: first the task are bound to a zone, so the build site is decided to be the most useful for this zone (so base zone couls put turret on front, factory in the middle and resources on back, where front and back depends from the dispusition of other zones - especially the enemy_attacked_from_there zone). then the command is readed by the task handler wich find the best way to accomplish it: if is a move command then take care of moving the group preserving formation (artillery back, for example) if is a build command will take care of finding the necessary builders or building them if not avaiable, and so on.
And then there is the zonemanager, the core of the ai where the magic of interpreting data into areas is done.
the strong point of this approach is that we have a centralized event driven way for process intercomunication, a sort of threaded messaging without the hassle of build it. The task/ticket system ensures that every taskhandler get the control of what it builds for first, the relase mechanism provide some way to provide other task with already avaiable units, the eventparser interpreting the world takes care of low energy or low metal situations raisin "build mex/plant" tasks.
some more details on the factory/pattern: as generic event raises (low energy, for example) we need a system to build task to cope with ever changing situations. the patterns are the ai "knows solution" for common problem, wich all toghether build up the I of the AI. for example a pattern for low metal is mex/mex or for energy is solar/solar or if low energy and low metal wind/wind/mex and so on.those task also come with a "strategy" wich is "build" in the three latetr case, and could be scaut raid attack defend for unit group. thanks for zaphod for the idea. so we could have a fark/fark assisting or a stumpy/stumpy raiding and so on. the Factory takes care of selecting the appropriate task basing on it cost/return value. (return icould be seen similar of the "level" of the zaphod unit groups)