External AI for MoM?

[Anthony]

I would be tempted by a 'simulated attack' routine for deciding on targets. Basically, just run a quick simulation on attacking each target, with some scoring system to decide how useful it is to hurt that target (possibly via a reverse simulation), and then attack targets that have the highest net value.

[I like Serena]

I would be tempted by a 'simulated attack' routine for deciding on targets. Basically, just run a quick simulation on attacking each target, with some scoring system to decide how useful it is to hurt that target (possibly via a reverse simulation), and then attack targets that have the highest net value.

That's doable.
We can get the statistically expected outcomes for unit vs. unit and such.

We would still need some rules using that information though...

For instance, what if you have multiple units that can have multiple targets with the same hurt-rating?

And what if the possible target is faster?
If it attacks you that's okay, but if it runs away, we should not pursue.

[Anthony]

Thinking of AI, I've been poking around at Battle for Wesnoth, which has a number of similarities to MoM combat (you could maybe design a MoM variant for it, actually, but it would be a bunch of scripting), and it's got a decently smart AI.

[I like Serena]

Thinking of AI, I've been poking around at Battle for Wesnoth, which has a number of similarities to MoM combat (you could maybe design a MoM variant for it, actually, but it would be a bunch of scripting), and it's got a decently smart AI.

Sounds good.
We should indeed get an AI engine somewhere else.
Perhaps here?
What's the kind of stuff we might want to use from it?

I also remember white mage mentioning C-Evo.
Who knows (or can find out) about the kind of stuff we could use from that?

[I like Serena]

To get external AI from the ground, I propose we create 4 new threads:

1. External AI - MoM internal changes (for changes to wizards.exe)
2. External AI - Assembly interface (for the external executable that interfaces with wizards.exe)
3. External AI - Engine (for the interpretation and execution of rules - using Wesnoth and/or C-Evo)
4. External AI - Rules (for textual rules that we think will improve the AI)

Any supporters?

[FrancoK]

To get external AI from the ground, I propose we create 4 new threads:

1. External AI - MoM internal changes (for changes to wizards.exe)
2. External AI - Assembly interface (for the external executable that interfaces with wizards.exe)
3. External AI - Engine (for the interpretation and execution of rules - using Wesnoth and/or C-Evo)
4. External AI - Rules (for textual rules that we think will improve the AI)

Any supporters?

I'm in for point 4.

[Jtm]

To get external AI from the ground, I propose we create 4 new threads:

1. External AI - MoM internal changes (for changes to wizards.exe)
2. External AI - Assembly interface (for the external executable that interfaces with wizards.exe)
3. External AI - Engine (for the interpretation and execution of rules - using Wesnoth and/or C-Evo)
4. External AI - Rules (for textual rules that we think will improve the AI)

Any supporters?

Sounds good! Would save us from a lot of reinventing of the wheel! This interface still requires possibility for manually moving the units from place A to B. That's what I'm trying to accomplish. And accomplishing that is a complicated task.

By the way, I've updated the external ai demo so that it allows changing the strategy. I suggest trying strategies 104 and 105 lol. Demo also allows manual targeting of any coordinate but the functionality does not work well if at all. Also, unfortunately the 106 does not look like the moving strategy.

[Asfex]

Yes, we need a kind of interface engine, on 2 levels I think.
....

You appear to have a couple of ideas to refine the assembly engine...
Can you make them more explicit?

Plains: i have idea to attach special neyron net as an artificial ai. So, i need low-level interface.

Detailed:

we must have acess to every significant variable,and a points when it can be changed. So, we must have 'table of hooks'. This table shows points, where (in overlays) the control goes to resident program.(use DOS only,to be platform undepended).
This is 'internal hook table'. We must patch mom procedures at the time it loads from file 'wizards.exe'.
It can be done via int 3f. If you look at interrupt vector 3f,then add 17 ofsett, you got DS (word). The table at DS:1A0 is the mom relocation table,8 bytes for each segment.
This 8 bytes contain:type of segment,cs in memory when it was loaded,and status,if loaded.
This information is enough to patch mom in memory only.(if you see call b0: d8 ,use DS:1a0+B0 to get cs. Then your call goes to cs: d8,if segment has been loaded into memory already)

Then each hook may call your external module, but this is other story.

[kyrub]

Hi guys,

if there's any need of my help, I am ready to offer full support to this effort, for points 1) and 2). The idea is lovely, and I am still very fond of it. It would be truly revolutional, as I think this was never done on this level (DOS game + external AI module). If you need the crucial AI variables, it's quite easy for me to retrieve them.

On the other hand, I don't want to spoil the fun for other colleagues who like disassembling and who (probably) want to take it on their own (?).

[Jtm]

If you need the crucial AI variables, it's quite easy for me to retrieve them.

On the other hand, I don't want to spoil the fun for other colleagues who like disassembling and who (probably) want to take it on their own (?).

Could you provide the crucial AI variables in spoiler form? This way those who dont want to reinvent the wheel will benefit from your findings and those who want to be unspoiled can choose so. Your knownledge of AI would certainly help us

I've a question about AI combat unit strategies. To me it seems game developers did not implement move-to-coordinates strategy. Am I wrong? In Unit_strategy_exe() the unit either attacks, moves towards target, casts spell or does nothing.