Interested in contributing

[hotmustard]

Hello, I'm interested in contributing to a thriving game engine community where I can add value. 10+ years of basic c# experience. Looking for opportunities to pitch in and help - do you have a bug/requested feature list somewhere?

I'm having a little trouble with the IB2Engine GH build around SharpDX - please let me know if it is broken. Cannot convert SharpDX.Matrix to SharpDX.Mathematics.Interop.RawMatrix3x2 and SharpDX.Rectangle to SharpDX.RectangleF. Maybe I am using the wrong SharpDX version - are you using the latest?

Thanks much!

[slowdive]

Welcome to the IB forums! Karl mostly has been working on IB and I have been working on IBbasic. IB is just for PC (although I have tried to bring it to iOS and Android with xamarin, but it has some issues) and IBbasic is for PC, iOS, and Android. IB has a separate Toolset app and IBbasic has a built-in Toolset.

The newer versions of SharpDX have changed a number of classes so we have been using an older version (SharpDX 2.6.3.0). Use the DLLs that are included in the IB v197 folder and reference/point to them from inside VS.

viewtopic.php?f=1&t=6&start=110#p286

We don't really have a requested features list so anything is fine that you think is needed. We usually add features and then set some type of flag if possible to use them or not so that builders can choose to allow them or not in their module. I think something we have needed is better and more varied AI for creatures in combat if that is something that interests you. Right now we just have BasicAttacker and GeneralCaster. Also, I started adding things like two-weapon fighting, threat range, and critical multiplier to IBbasic, but they haven't been added to IB. Any additional combat mechanics are much needed to keep them interesting.

IBbasic, the new version, is found here (IBbasicJr for iOS/Android and SolentarrEngine for PC):
https://github.com/slowdive-fan?tab=repositories

[hotmustard]

Fantastic. AI sounds great. I'm no expert on it, though. I have worked with / am working with the DungeonCraft AI system (http://ua.reonis.com/) and from that work, I strongly recommend that you incorporate a scripting language to control AI. Since you are already into JSON, I will float Jint (https://github.com/sebastienros/jint) - it has a lighter footprint than V8 and is currently active and I have had success embedding it into Unity. Unless you object, I will make use of that for a first cut.

I will also suggest i18n work if you haven't done it yet. We are doing it right now in DungeonCraft and that community is finding that there is a lot of interest from other parts of the globe. As a westerner in my western bubble, I was surprised.

Generally speaking, I prefer to work on things that are high-impact and have a large return, whether they be easy or hard. So if you have something that would benefit a large number of designers and/or players, feel free to toss it my way because that is what motivates me.

For any development, shall I do a pull request and then you review and do a merge?

Thanks for getting back to me!

[slowdive]

We are very much self taught coders so you will quickly find that our code is messy and may not have the best structure. We used to use C# as the scripting language back in the early days, but out of concern that anyone could create malicious code that could be executed within IB (not fully sandboxed), we abandoned that (you can look at early versions of IB on GitHub to see how we used C# and all the hooks to call for scripts in combat and elsewhere... see IceBlinkEngine/scripts on the GitHub page). We now use a built-in scripting language for IB (see IBScriptEngine.cs and some script examples in the "default/NewModule/ibscript" folder), but it is clumsy at best. It is really an interpretive language (doesn't compile), I think that is what it is called. Replacing our IB scripts with a true scripting language that is fully sandboxed and with appropriate hooks would be a great benefit to builders. As a transition, we can add the hooks for the new scripting and leave the old ibscripts hooks (so have both in parallel) so builders can slowly transition their modules over to the new system as they go (unless there is a better way of course).

As far as GitHub goes, we really haven't fully understood how it works and we have been a little scared to use the pull and merge functions. Karl has mostly just been working on IB and making pushes as he goes. If you are familiar with how it works (pulls and merges) and can do it safely, maybe you could teach us that. Karl and I did this years ago, but it seemed to be buggy for us so we tried to avoid stepping on each others feet. We haven't really tried to learn how to use the full push/pull/merge features because we have been working on seperate versions of IB and IBbasic so it hasn't been needed.

[hotmustard]

Alright, let me take a crack at some AI and integrating Jint and we shall see how it goes. I am looking into utility-based AIs but not finding any great frameworks to steal. I'll keep trying - I hate rolling my own.

For GitHub, the last SO answer here is a very nice tldr along with a link for more details:
https://stackoverflow.com/questions/174 ... -on-github

When you get my pull request, if there are conflicts, we straighten them out at that time. I'll help you out with it if/when you decide that you want to merge my stuff in.

[slowdive]

Sounds like a plan, keep us posted on any progress and questions along the way.

[hotmustard]

So here are two things off the top of my head that I think I notice/see from the code that you maybe want to change a little (always leaving the option to use the default behavior alone, of course):

- Creatures are either ranged or melee and can't switch between them, even when they suffer an attack penalty - allow them to switch when it is "smart"
- Creatures will target the closest pc in the party regardless of their health and in order of the party order (always attacking the 1st person within range in the party) - they should probably choose a character that is the most threatening? Or most vulnerable? Or make that behavior configurable (would anyone really bother using that, though)? Possibly introduce some configurable level of randomness to target selection if people think that would be useful.

How about I start there? If I am wrong about the behaviors above, please let me know. Casters will be a whole other story, and I haven't dived into how those are working yet, but I will try to modularize it so that the same framework can be used for them in time.

I have been working in the IB2Engine project/repo, btw, and all comments are in regards to that.

[Dorateen]

hotmustard, what you described is true of the default AI behavior. However, Karl added some AI settings to the PC build if IceBlink that allowed the AI for a creature to be modified as a BloodHunter (go after character with lowest hit point) or MindHunter (target character with highest spell points) or Soft TargetHunter (target character with weakest armor class).

These are setting under the cr_Ai tab that brings up a drop down menu on the creature blueprint. But it would definitely be nice to have a more reactive AI in place. So perhaps this is a start.

[hotmustard]

Yep I see them in there. Didn't know if people were using them, though. If there's a dropdown, I'm sure people are, though! Thanks! I will be sure not to disturb that logic.

[hotmustard]

I started by refactoring a little to suit the different kind of AI models. Preserved all existing code for the BasicAttacker & GeneralCaster, but moved them into a Factory pattern and added a ScriptedAttacker type. Integrated Jint and put some wrapping around it in an new Scripting namespace. Nothing should be disturbed from the existing logic:

https://github.com/grannypron/IB2Engine ... 6f3b52b46a

Next I'll write the actual AI scripts and tweak the UI so that designers can choose the ScriptedAttacker type. I just wanted to share this earlier than later in case there are questions/objections to the refactoring.

I didn't include the Jint binaries, but just add the latest stable NuGet Jint version and you should be fine.

[slowdive]

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

[hotmustard]

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.

[hotmustard]

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.

[hotmustard]

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.

[hotmustard]

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.

[hotmustard]

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.

[slowdive]

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.

[hotmustard]

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

[hotmustard]

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.

[hotmustard]

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.

[youngneil1]

Heyho hotmustard! That's impressive stuff you are working on - even more so when considering that the state of IB (toolset and engine) is not easy to get into due to lack of comments and refactoring (which is my fault, not Jers). Keep the good work coming!