This system operates off of discrete event subsystem. This is because triggers are event systems, and as such model well into the system for our input. Triggers represent limited If, then arguments, known as modus ponens. If we are to perform decision making, then we must grant additional logical operators for our use. Luckily, we can do such through the use of triggers. Basic trigger AI will function as:

Input → Processing → Output

Various expansions to this concept will be introduced and expanded on. These take the following form.

Input → Processing → Output
||||||||||||↑↓
|||||||||Database

This additional storage of information has various advantages over the previous system. Rather than things like build orders, objectives, and various other knowledge having to be hard-coded into the processing unit, we can instead separate it out and put it in an easily accessible format. All data will be stored virtually, and so it is possible to add data while a game is being played. The most notable application of this is in the implementation of simple self-learning algorithms. It is possible to apply Darwin's theory of natural selection, and reward those actions which achieve prolific results, while punishing those that receive negative outcomes. This "blind" self-adapting system would change its tactics based on the opponent's tactics; ultimately creating a more fulfilling game experience.



(In Progress)

The above post will be updated as I finish writing more and more. I promise I do have it all planned out, I just need to put into words / add graphics. The above post is separate because I will add more and more as more and more theory is stacked on it.

I always thought something like this could work. might take some time but everything in mapmaking does. A large amount of triggers could make a pretty extreme Desert Strike AI no? This is exciting! Also in color!

Sorry, but IMHO a large amount of triggers could make a pretty extreme lag...

If there are 8 players in the game, and you have a trigger owned by All Players, then the conditions and actions for that trigger are executed 8 times every 2 frames, assuming you are using Hyper Triggers and no other waits.
You can reduce execution time by running very specific conditions, and ordering the condition most likely to be false at the top of the list.

Computers will have a hard time choking on one hundred thousand triggers (if that's the case..). It's like running a brute force algorithm for a 6-digit numeric password every 84ms.

It seems that actually using this to make anything practical would take prodigious amounts of effort. And there might be bugs in the underlying system, too.

A large amount of triggers will also cause lag.


Indeed, the number of triggers must be kept at a minimum.



Dealing with this issue partially tonight. The computer will be player 1 and thus at the top of the list. Triggers that have no use will be turned off.


Depends how meticulous I am in my work. My maps are typically obsessively organized, I should have little problem finding and fixing bugs.

Note that Comment and Preserve Trigger are iterated and treated like other actions.
You can reduce a call by unchecking/disabling Comment actions until map completion.
Every condition is read until one of them returns false, so (as I said before) make sure you put the conditions most likely to be false at the top.

The behaviour of "Always" is the same as Comment. It' calls another function, and you can reduce that call by having no conditions at all, or unchecking/disabling Always.

You ever going to write this?