Basic Keeper AI

[Bertram25]

The current AI is working, yet it still needs a few additions:

• The AI should be able to build treasure rooms, hatchery, quarters and a training hall
• The AI should take care of building rooms to get the maximum "active spots" (represented by room models), by using squares surrounded by accessible and claimable dirt.
• The AI should drop fighters near-by other enemy creatures to trigger some fun, once it is ready and has got a few fighters trained.

[Bertram25]

Ah, while I'm thinking about it:
The AI should check it's available rooms from time to time. In case it already has them at start, or whenever it has got a few ones even partially destroyed.

[Bertram25]

Also, IMHO, the AI shouldn't use traps atm, as they aren't fine tuned and may make the AI invincible.

[hwoarangmy]

IMHO, we should create some indicators telling the creatures needs. For example, the average hunger, the number of creatures without a bed, the average level (for training room).
This way, it would be easy for the AI to know which room is needed and when to build a bigger/new room

[Bertram25]

Yes, while you're already one step further. :)
I'd like the AI to create proper square/rectangle room shapes first and monitor their filling with convenient room tiles. Once this major step is done, the rest is just having fun with AI coding, IMHO. ;)

[hwoarangmy]

Fun... and lot of headaches ;)

[Bertram25]

Indeed!

[Danimal696]

i can remember neither in Dk1 or dk2 the AI put traps/doors, all were pre-laid at map design, even if the ai player had a full workshop

[Bertram25]

i can remember neither in Dk1 or dk2 the AI put traps/doors, all were pre-laid at map design, even if the ai player had a full workshop

True. Yet, even with starting lighter, I hope we'll make it better even if it will never be perfect. :)

[Bertram25]

Ok, it's official, I'll be on that from now on if nobody else strongly wants that one. ;)

[hwoarangmy]

Concerning AI, according to what we said during the lan, I've also had a look and do you think all those classes are really needed ?

• A factory, when we will have, at most, 4 or 5 AI. IMHO, it can be removed (and eventually be replaced by the AIManager if we want a wrapper for AI creation).
• The NullAI (which is not used and is the same than BaseAI excepted that it implements the pure virtual function from BaseAI). If we really need an AI that does nothing (I don't know why), changing BaseAI so that there is no pure virtual function is enough IMHO.
• The wrapper is also not needed IMO since its functions are really simple (almost wrappers for the gamemap). I could understand the reason if the AI did not depend on the gamemap but it is not even the case (as it does call the gamemap from the wrapper). IMHO, the point of having different AI is that they should not do the same things. Which means that a wrapper might not be the best thing. Moreover, adding the needed functions directly into the gamemap would allow to add console commands to test them more easily.

WDYT ?

[oyvindln]

The fancy factory thing can probably be removed. I do think however that we should have some sort of wrapper that the AI use to communicate with the map, reading from it directly is probably okay, but maybe it could do actions more like the clients, but without needing to go through through the network.

[hwoarangmy]

I do think however that we should have some sort of wrapper that the AI use to communicate with the map

I would agree if the gamemap was not used in the AI. But since it is, I don't really see the point of having it.

[hwoarangmy]

BTW, if we want to keep the wrapper, we should properly decide what it is for to make sure it is used as it should. IMHO, ATM, it is not used as it was supposed to be.

[Bertram25]

@oyvindln So the point of having a wrapper is only based securing getting/setting info to the game map?
Isn't this something from the time where OD had plenty of semaphore running within objects?
As @hwoarangmy said, if there is no other need for it to exist, I see no point in adding a useless layer.
But maybe have you got something else in mind?

[Bertram25]

Btw, I do think we can remove the BaseAI or NullAI class, too. It's just a matter of a few tweaks and keeping the favourite name. ;)

[oyvindln]

Well the original point was to have something easily scriptable, and having a dedicated API would be simpler than exposing everything to the scripts and hope they don't call the wrong functions (Not that the wrapper class currently solves that.)

My thought now though, is that it would be cleaner to have all player action happen in the same place in the code, and we could do that by treating the AI as another connected player (still in the server thread, but using the event system already in place). Right now the AI is run from within the gameMap, which is both confusing, and means there is a bunch of non-used code in the client-side gamemap, the class rather large already.

[Bertram25]

My thought now though, is that it would be cleaner to have all player action happen in the same place in the code, and we could do that by treating the AI as another connected player (still in the server thread, but using the event system already in place). Right now the AI is run from within the gameMap, which is both confusing, and means there is a bunch of non-used code in the client-side gamemap, the class rather large already.

That's very relevant, while different from keeping the AI wrapper. I do think you're right while refactoring some code here can be done step by step. Ok to open an issue about the gamemap god object problem and remove the wrapper for now?

[hwoarangmy]

Btw, I do think we can remove the BaseAI or NullAI class, too

Ok for NullAI but not for BaseAI. In the end, we will want to have several AI so it is not too predictable (and it would allow to make AI fight each others to test if them one against each other, which is interesting IMO) ^^
Moreover, in my mind, it was a class that could be used to store the shared function that all AI will use (more or less what is in the wrapper at this moment).

it would be cleaner to have all player action happen in the same place in the code, and we could do that by treating the AI as another connected player

Well, AI player is not a normal player. First, as it already uses the server gamemap from the server thread, its actions are already synchronized with the gamemap. Sending a message like the players do will result in the server checking everything (that has already been checked previously). So, it is twice the work. Moreover, concerning the events, most of them are created when something is added to the gamemap (creatures, rooms, ...), just like the AI does. And lastly, the server thread takes its messages from the network and checks that players actions are valid. It was never meant to be the entry point of all players (only for human players). The shared entry point for everybody is (and was) the gamemap. Which is also the case now.

[Bertram25]

Ok for NullAI but not for BaseAI.

Ok for me.

The shared entry point for everybody is (and was) the gamemap. Which is also the case now.

Maybe that's the point @oyvindln is talking about. I wouldn't like to speak for others also, but there might be a need to move or remove certain functions from this big object. Which ones, how and where must be taken point per point IMHO.

In any case, the current design is rather good already, and I do think we're in the right direction. :)
So without speaking of potential refactoring, the question of whether @oyvindln agrees to remove the IOHO (In Our Humble Opinions) (new acronyms FTW ;]) useless wrapper is still pending.

[Danimal696]

i also vote to have a few types of AI; Null, Normal, Agressive and Defensive

[hwoarangmy]

i also vote to have a few types of AI; Null, Normal, Agressive and Defensive

In the end, yes (but not NullAI - if we want the keeper to do nothing, we just have to not assign an AI). But for now, I would vote for: "doesn't work", "works more or less" and "buggy" ^^

[hwoarangmy]

Maybe that's the point @oyvindln is talking about. I wouldn't like to speak for others also, but there might be a need to move or remove certain functions from this big object. Which ones, how and where must be taken point per point IMHO.

I agree, the gamemap is too big ATM and it would be nice to split it. Concerning not exposing uneeded functions, I agree. But IMHO, it is not the good moment for that. When we will add support for scripting, we will have the opportunity to think about that.

You all seem to think that AS is a good choice for scripting. I am a newbie about that and I trust your judgement. But from my point of view, having integrated it too early has brought useless work. We have a non working AS and we have already updated it (for a version we are not even sure we will use as there might be another version when we will be there). Moreover, everytime we compile, we compile AS.
That's why I think we should not take scripting too much into account as long as we don't clearly have a vision of what we will use it for (AI ? Console ? Creature behaviour ? Map events ? Trap behaviour ? ...).
My point is not about removing AS but to decide what we want to use it for to prepare the needed wrappers and stuff. And not to prepare things that we will decide to not use.

[Teaser on]
I think you will see a PR about AI soon ^^
In this one, I won't remove anything about AI as I think it is better to do that in a dedicated PR if possible.
[Teaser off]

[Bertram25]

I agree, the gamemap is too big ATM and it would be nice to split it. Concerning not exposing uneeded functions, I agree. But IMHO, it is not the good moment for that. When we will add support for scripting, we will have the opportunity to think about that.

Agree as well. It's typically something to do along with something else, preferable not before a stable release, and why not when on improve scripting. My actual thought is that all three you, oln and me are the kind to add cleanups in our PR when we see ones to do, so I don't worry at all about the game map object. :)

You all seem to think that AS is a good choice for scripting.

Like anything else. it's, at least for me, a choice. It means only that. ;) More seriously, for you to get a bit more history about this, IIRC, I looked at several projects out there using it, and try to identify what was good in it, and what was bad, (there must be a forum thread about this somewhere. I'll try to find it back.)
Nidomedia (on free game dev) and I (and maybe even oln and paul424) had to make a choice and we decided to keep it because it seemed successfully used in several other projects, such as Overgrowth, and was already integrated. We also decided to upgrade it to the latest stable version available, to first see whether it was still doing fine with the current codebase, and to remove one excuse from starting to improve scripting support, so that if someone was ready to go after that part, everything was in place for that to happen.

This being done, I do think it would probably be better to restart working on this only after reaching a stable version first.
@oyvindln Feel free to correct me if you see something wrong in what I said. :)

I think you will see a PR about AI soon ^^

Cool :D Depending on your progresses, I may propose my improvement to yours if there is any fitting. Let's see. :) 0.4.9 is even closer. I can feel it!

In this one, I won't remove anything about AI as I think it is better to do that in a dedicated PR if possible.

Np at all. Just cleaning stuff can even done for the next release depending on our time. :)

[oyvindln]

You all seem to think that AS is a good choice for scripting. I am a newbie about that and I trust your judgement. But from my point of view, having integrated it too early has brought useless work.

Well I've allways been a bit ambivalent about it. We decided on it originally because it seemed simple to integrate, compared to say Lua or python, though the fact that it does not seem to be packaged is an issue. I agree that integrating it when we did was premature, though that was done by someone who has long left the project. It's not used for anything sensible at the moment, I am working on the console, and was planning to disable the wrapper thing for now, as it has to be changed to accommodate the client and server running in different threads anyway.

[hwoarangmy]

Well @Bertram25 argument about allowing someone who wants to mess with it to integrate AS seems pretty relevant. Even if, IMHO, it is not clear what we want to use it for.

Moreover, one thing I forgot to mention is that I've already reached a dead end while cleaning code because of AS wrapper that is exposing a lot of functions (IMO, some really too sensible). It's strange to see how far some people have been on integrating AS (looking at AS wrapper which is exposing loads of functions) but not making it work.

Depending on your progresses, I may propose my improvement to yours if there is any fitting

I have created another class for AI so if you want to improve yours, you can go ahead. IMHO, we should not interfere with each other AI directly. It is better to have 2 different available AI (even if some stuff can be shared).
That being said, I think we should go for a 3rd AI with the best of the 2 other ones so that we have some kind of "AI levels".

Concerning AI, it currently manages to place rooms and creatures behaves well. I will try tonight to make AI be able to save wonded fighters. Concerning attack, I think it will have to wait for a spell allowing to gather creatures in an ennemy dungeon.
From the tests I've done, the AI has a much harder time trying to kill another AI now that the dungeon heart is not a big open space anymore...

0.4.9 is even closer. I can feel it!

Well, now, it is a matter of days (and of what we want to improve) as we have all required stuff in the planning ^^

[Bertram25]

Even if, IMHO, it is not clear what we want to use it for.

Yep. It's clearly not decided yet.

I have created another class for AI so if you want to improve yours, you can go ahead. IMHO, we should not interfere with each other AI directly. It is better to have 2 different available AI (even if some stuff can be shared).

Ok, :) While I will gladly lose that competition since I'm unable to spend much time in spare coding atm. What matters is that one of us makes something cool. :)

That being said, I think we should go for a 3rd AI with the best of the 2 other ones so that we have some kind of "AI levels".

Yeah, hybrid death-incarnated AI brought to all players afterwards. :>

Concerning attack, I think it will have to wait for a spell allowing to gather creatures in an ennemy dungeon.

This can done later, of course:
In the meanwhile, I wondered, Isn't it possible to test and drop creatures on the nearest claimed tile when:

1. Having claimed tiles near enough a enemy room/trap?
2. Being attacked on a claimed tile?

I do think also the AI shouldn't react to attacks each turn and wait some time for an outcome before triggering another attack/defense mechanism.

From the tests I've done, the AI has a much harder time trying to kill another AI now that the dungeon heart is not a big open space anymore...

Eh eh. Good. :)

[hwoarangmy]

While I will gladly lose that competition since I'm unable to spend much time in spare coding atm

no problem, it is not a competition (and if you want to compete, I want a cup if I win ;) )

In the meanwhile, I wondered, Isn't it possible to test and drop creatures on the nearest claimed tile

I was planning on allowing the AI to pickup wounded creatures from battleground and take them to his dungeon heart (when they are not too near from it to allow killing creatures).

Having claimed tiles near enough a enemy room/trap?

That would mean to check around every claimed tile if an ennemy object is around...

Being attacked on a claimed tile

I will have a look if we can at least do something when a creature is attacked.

I do think also the AI shouldn't react to attacks each turn and wait some time for an outcome before triggering another attack/defense mechanism.

Yep, I agree. Maybe a random cooldown between each drop would be enough...

[Bertram25]

I want a cup if I win ;)

Of tea or coffee? ;)

That would mean to check around every claimed tile if an ennemy object is around...

Or check enemies rooms/traps, maybe? Yeah, not every turn also, btw.
EDIT: Btw, this might be worth waiting for the fog of war since quite the same kind of computation will have to be done...

[hwoarangmy]

Of tea or coffee? ;)

I was thinking about gold but I guess tea can do ;-)

Btw, this might be worth waiting for the fog of war since quite the same kind of computation will have to be done...

Yep and it might be interesting to try to go for events rather than by pulling.

[hwoarangmy]

Here is the PR ^^

[Bertram25]

Yep and it might be interesting to try to go for events rather than by pulling.

Might be worth trying, indeed. :)

I am working on the console, and was planning to disable the wrapper thing for now, as it has to be changed to accommodate the client and server running in different threads anyway.

@oyvindln When you say disable it, I guess you mean remove its use from the console, am I right?

[oyvindln]

Disable it's use in the console, and probably disable the wrapper class as it depends on everything else in the project.

[Bertram25]

Disable it's use in the console, and probably disable the wrapper class as it depends on everything else in the project.

I see no objection for the current release. we can always re-enable bindings little by little based on the need later.

[Bertram25]

Fully done with #325 . I'll open an issue about cleaning the AI files. Congrats @hwoarangmy :) I'll happily let your AI be the one used for the game. :D