IceBlinkEngine.com

The code looks amazing! It will take me some time to wrap my head around it as I haven't used interfaces that much. I used them a bit for NWN2, but they still are a bit confusing to me, haha

I grew up coding on my c64 and amiga500 with Basic (that was about the extent of my experience as I made simple text RPGs with a D&Desque combat system) so this whole OOP and other non-procedural coding is still confusing to me

Sure just lmk if you have questions. A quick Google will give you info on the Factory Design pattern. It's shit simple.
https://www.c-sharpcorner.com/article/f ... n-c-sharp/

Alright, so I got an implementation working with a simple script and here's what it would look like:
https://raw.githubusercontent.com/grann ... _script.js

So, your designers would put that js file in their module and they can go to town. Devs get to add more elements to the "inputs" variable as designers need them for their enemies to make decisions - like "TargetACs", "AttackerHP", "AttckerAC", etc. Or you could just expose your whole object model to the JavaScript scope. You'll probably want to let them specify a js file for each ScriptedAttacker so they can choose behaviors as they see fit.

Apart from fiddling with the Jint dependency, this branch should compile and run just fine if you want to try it out:
https://github.com/grannypron/IB2Engine/tree/NewAI

It will fall back to BasicAttacker if it can't find an ai_script.js file, so no harm done if no one wants to use it. If you guys like the direction, I will just tweak the UI to allow designers to choose ScriptedAttacker and choose a js file. I haven't looked at the editor yet, but I assume it's a pretty straightforward thing when you are creating a creature type. Then, you can feel free to merge it in if it adds value.

oh yeah & I started with the C64 copying those fortune teller or whatever programs line by line from inside of one of those magazines. Hooked ever since.

You could also test the ScriptedAttaker without the UI change just by changing the cr_ai attribute to ScriptedAttacker in the creatures.json as well. The ai_script filename defaults to ai_script.js.

The Toolset interface was relatively straightforward to tweak. Very little code to change:

https://github.com/IceBlinkEngine/IB2To ... pron:NewAI

I have filed two pull requests for the two libraries. If you review and like where it is going, you can go ahead and merge them in. Again, shouldn't be any disturbance to existing logic. Future pull requests would be to ScriptedAttacker.cs to provide additional values to ai_script.js and then tweaks to ai_script.js itself for more complex logic.

I can see that my idea of AI switching between melee and ranged attacks would have a rather large scope. As far as I can tell, there's a good bit of code structured around the idea of a creature being one or the other. There's only a single attack sound/sprite so it wouldn't make much sense for a ranged attacker to use that sound/sprite when they were converted "on the fly" to a melee attacker. Idk if people would even like that behavior. If there are any ideas as to specifically what behavior we would like to change in the AI, I can try to script it up.

Having the option for some creatures to have a melee and a ranged attack or just melee or just ranged is a nice feature for builders to have. I do understand that it would require a lot of code revisions. Maybe we put that on the future features list and have it sink in for a bit. I guess we should have a features list I wonder if a features list would be better to house here on the forums or on GitHub. I think it may be easier for most if it was kept here on the forums and we updated the list periodically. Maybe have the list stay on the first entry of a thread and just edit it as we go. We have done something similar over the years on the old forums.

I STRONGLY recommend feature / bug tracking on GH for these reasons:
- Standardized way of marking completeness and commenting on a bug/feature and watching its progress
- Automated release notes
- Code commits can be tied to a feature/fix so that code changes' purpose can be easily understood and rolled back if necessary

Also posted a pull request that incorporates the scriptable AI for the IBx engine:

https://github.com/IceBlinkEngine/IBx/pull/1

The "log" function causes an error in this version, but that is probably a Jint/Xamarin thing. The logger will need to be swapped out eventually anyway, though. Should be no disturbances to the existing logic.

I propose two "capability areas" for AI.

1) "Team awareness" - each enemy will be aware of the actions of other enemies attacking the player's party
2) "Attacker memory" - each enemy will have access to the actions that they took in the last round - or possibly all rounds

These areas would allow a developer to implement two features:

1) Enemy coordination. Enemies could attack with a shared goal in mind.
2) Long term planning. Enemies would be able to attack with a longer term goal in mind.

Finally, these could result in two example behaviors, which could be scripted up in the default AI:

1) Ranged attackers should coordinate on one PC at time. Ranged enemies with a choice of PCs will choose the ones that other enemies are already shooting at with the goal of knocking one out at a time. Possibly the same for melee, though this would be restricted by adjacency.
2) Once an enemy chooses a PC to attack, they will continue to attack that PC until / unless the PC moves out of range (be it melee or ranged)

A future possibility is line-of-sight awareness. That is, if a scripter has access to the "cover" on the battlefield, they may choose to have their enemy move into cover in certain circumstances. This sounds a little daunting to code in efficiently, so I will not commit to making it accessible to the scripter yet.