So the next GG update is to be "AI improvements", specifically to allow NPCs to "work" on "internal" levels, for example to climb stairs in buildings, be able to shoot through windows etc.

I think that before any "improvements" can be embarked on we need to define what we actually require the GG engine to provide and what should be left to the user to script, i.e. at what level the internals should be exposed to Lua scripting and what we should expect the engine to handle automagically.

For example; should the engine handle all aspects of locomotion or should aspects of it be externalised? What about steering, at what level should steering be defined? Should the engine handle all path smoothing or should this be externalised to scripting?

Another problem is that most people think of "physics" as being separate from "AI" but they are intrinsically linked as collisions (or more correctly collision predictions) are a core requirement for handling AI (in that in order to determine the next action selection for an entity you need to know whether the entity will collide with something in the next frame). What level of feedback from the physics engine should be exposed to scripting?

Another aspect involves libraries to handle AI behaviour, i.e. do we want hard coded state engines or a more generic implementation that is customisable by Lua scripts?

Currently only "active" entities are accessible to Lua scripts, "static" entities are effectively invisible, should there be another "type" of entity which is "static" in the current sense but can be "seen" by scripts and details of them available to allow scripts to take account of them?

Please feel free to discuss any aspects of this that you feel qualified to engage in but refrain from simply spouting what other engines provide (for example if all you have to add is "we need navmesh" then you are just showing everyone that you have no idea what you are talking about ).

Not to show everyone that I have no idea what I am talking about, but the ability to dynamically generate a collision-mesh used by the engine upon which enemies could walk based on your level geometry (or even just your EBE geometry, going forward) would be an excellent idea for Gameguru.

I remember old FPSC with darkAI and show/hide AI outlines allowing me to see that FPSC was totally capable of doing this on it's old segment system, and considering enemies in GameGuru are already capable of moving UP and DOWN on the y axis without waypoints, such an idea would not be so farfetched for the EBE.

I'd also like to see some customizability. It would be nice to be able to fine tune places enemies prefer to shoot from or where they will run if hurt, even better if that's using the editor with "zones" and whatnot to customize enemy path choices. (this requires "zones" to be improved and be actual 3d meshes) but such things are not needed. I think the most important thing is a building editor that works with the existing AI system and allows for navigation on multiple levels/floors.

The enemies on terrain should be able to go from it to a building floor on a similar level, this is also important. I also think that with such AI and pathfinding improvements, there will be a need to include stock allied AI scripts.

Don't forget the next update is actually the EBE first ..
Then the AI starts and its unlikely to be a quick job... But I'm sure its going to be worth it

I have a question (mainly to Lee) about the AI in build 1.14, I am not sure if this is the right place to ask.

So in v1.14 Progress Update Lee says "Added missing DarkAI commands". Which commands? All of them? If tis is the case it is great news indeed because (looking at the original DarkAI plugin documentation) we get the command "AI SET PLAYER ANGLE Y" which effectively means that we finally get a command to control camera direction! In addition, previous work by several members of this forum gives us the possibility to control Player (hence camera) x and z position. In short, can we expect in 1.14 to be able to finally control the camera by script.

In the same vein, do we get "AI GET ENTITY X" / "AI SET ENTITY X", "AI GET ENTITY ANGLE Y" / "AI SET ENTITY ANGLE Y" etc.?

And finally, if I am not asking too much, best would be if Lee would give us the list of newly added DarkAI commands.

They could be defined with default values working for common usage, but defined in Lua file to let people change values like acceleration, deceleration or cylinder collision.
The more you get exposed, more the engine is flexible , more new gameplay and new scripts people can do.


Detect when something enter collision with a model and get informations from the colliding model like : name, collision position, collision normal (Same for exit or Stay in collision). Raycast collision is included in Bullet, exposing it would allow users to make lot of new gameplay.



Perhaps state machine editor calling Lua functions like "player in range" , "player visible" , "go to player" , "attack player" , "do player damage", "go to cover". A beginner can create it's own AI behaviour , while a coder can create new lua functions for blocks.


The only interaction you can need is if you collision or raycast with static geometry, otherwise add Lua to the 3D model to make it dynamic if you need more functionnality.

I think it's too early, and better let Lee does it it's way first then give feedback.

@synchromesh, there isn't much point discussing requirements after the code is written so we can take the EBE as we find it but "AI improvements" is such an open-ended aim that I believe we need some sort of discussion even if it is just to define the scope of the changes.

I too am intrigued to find out what all those DarkAI commands are, it may be that they already provide some of the missing functions I would require to generate some 'proper' AI scripts. For me though the biggest issue is the Physics/AI interaction and the ability to access the properties of entities, both dynamic and static, at runtime.

The principle that GG seems to have at present is that 'character' entities are completely autonomous, by that I mean if the script says 'run to x,y,z' then the engine handles the path finding and locomotion aspects for that character. This works fine if the 'character' is one of the standard soldiers but it does mean that they all run and react the same way. For example if you have ten RPG guys in front of you they all trigger the same way and animate the same way and usually end up firing at the same time, it is possible to make ten copies of the script and give them all slightly different behaviours but users probably don't want to do that so maybe the engine could provide a more generic 'fuzzy logic' state engine to add more realism to the 'default' behaviours.

One thing I have mentioned before, and volunteer to do if Lee agrees, is a major rewrite of the existing Lua scripts to separate out the 'common' functions and add some new functions (like 'RunAway' for example ). The advantage of doing this is improved performance and less memory usage plus the individual character scripts become much smaller and easier to understand which in turn makes editing them for specific game needs less of a chore. I have actually already done this for the basic characters and it works well, the AI overhead is considerably reduced.

"Upcoming"? Do you know something we don't?

Upcoming as in what Lee is planning on working on next. Next as in after the thing he is working on now, the EBE, which he has indicated is nearly complete, or at least complete enough to start Beta testing soon.

He knows what everybody else knows, we have EBE coming soon, then there will ba an AI update, then the votes will be reset.

@AmenMoses

You write "I too am intrigued to find out what all those DarkAI commands are". I am not sure I read you right, but if you mean the original DarkAI commands, I can email you the help file, provided this is OK with the TGC (i.e., no copyright issues involved etc.). In the meantime, you can check https://www.thegamecreators.com/pages/newsletters/newsletter_issue_39.html#4, it gives a brief description of DarkAI and lists some of the commands.

Suppose we are doing the typical shot to the target, some bottles on a table and shoot.
I want to know:
When a bullet hits the target
The name of the target
The position of the target
And be able to count the number of times a bullet hits a certain target, in order to break the bottle, say after five hits.
All this without having to add a bone to each bottle, and work with limbs.
Currently the system knows when the player collides with a box, and this box has no bones, then use this same system.

If we can handle collision via scripts, perhaps with has no more problems with the trees, and fps dropping; we just has to start all the trees with physics off, and work as distance based, so trees just get collion on, when the player is nearby, when player is interacting with.



Perhaps Lee cuold do something about, so any script can get info about static entities, just setting it as "always active" via properties panel.

physics has much to do with navmesh and pathfinding algo (nodes), to get the most better way to go from point A thru B.
I have not idea how GG does, but I think engine should work with a "collision map", all the obstacle zones represented there, let's say in a red color, that map should help render to calculate/add obstacles in the map, in test/play level stage.


I think it has something to do with this thread

3com

Hi Guys - I would not get too excited about the DarkAI commands...
I think Lee is only adding the declarations for the commands we already have..
As someone in another thread was asking where they where..
So Lee said he would add them maybe at end of the global.lua...
I know some Lua commands where not setup as global functions in the global.lua..
but must be directly called to the engine somehow...

3com you beat me to it..

I was under the impression that the re-write to C++ meant that some of the original AI features no longer work so it will be interesting to see what Lee has included in the next update (hopefully the Beta isn't too far off).

For the AI update I would like to see some sort of expansion on the 'zone' principle, for example instead of just 'cover zones' I'd like to be able to specify a set of 'firing' zones which the AI should try to use, if the firing zone is in use then it should select the next nearest etc. 'Retreat' zones, when the NPCs become diminished in number they should retreat in an orderly fashion to the nearest one.

Now I could code these things in Lua but I think more support from the engine would make this a lot easier, even if zones could be created in the editor and given a set of parameters to be passed down to the scripts would be an improvement.

Sorry for the exciting entry in my progress bulletin! The DarkAI reference was merely in response to a user who wanted to see the documentation for the current subset of DarkAI commands in the current version, so V1.14 will include this extra information. Having resurrected the documentation for DarkAI and moved the correct pages over to the GameGuru Docs folder, I did see a number of commands which might work really well in GameGuru, and the AI update 'may' include some of these. My main focus for the AI work will be to deliver a system that's as customizable as possible (so you can tweak it to your own needs) and will control an enemy character to shoot, move, flank, hide, enter buildings, through corridors and rooms, run upstairs, fire out of windows and generally behave sensibly both inside and outside. If I can decouple the system from the engine enough (i.e. move it to LUA) there should be no trouble turning him into an ally or neutral character, but as this was not the original goal I will leave that bit of fun for you guys and gals to work out. As much as possible, I want to avoid hard-coding anything in 2017 and move as much as is practicable to LUA, opening up the logic to anyone who wants to fiddle about with the subtle art of game mechanics.

i know this will make the short term work longer but it will definitely decrease the long term work for you so happy to hear that.

But Lee: " I did see a number of commands which might work really well in GameGuru, and the AI update 'may' include some of these"! Why not a many or all of these? It seems to me that the coding required to add the entire DarkAI command set cannot be that great. Indeed, I did the same thing for FPSC in a couple of days (admittedly using DarkBasic, I do not know how different the process would be with C++).

Nice!

3com