Search the Community

I use Entity:GotoPoint() on my AI character. It moves perfectly from point A to point B If my player controller stands between A and B, this AI character will push it. If I set my character mass greater than AI's , AI character will be stuck a bit and take time to "slowly" move around my cylinder physic shape. How can I make my AI move around my player character properly when using GotoPoint ? I need him to avoid my player character's position. I am sure that I can't use world:BuildNavMesh() every frame for this kind of pathfinding...

I'm running into a problem with pathfinding where you have a ledge like this: <- enemy ----------- player | ---------------- The problem is that if the ledge is big enough, a path can't be created (which makes sense). However, GoToPoint still returns true (presumably because the point that the enemy is trying to go to is on an unconnected navmesh). Anyway, all I need is for the enemy to be able to walk over the ledge. How would I recognize that the enemy reached the edge of the upper platform though?

Working on two principles K.I.S.S. (keep it simple stupid!) and more for less. I spent a lot of time researching (read playing) certain games that have what I call an ambient NPC population. This is specifically those NPC's that reside in the background and generally have no real or very limited interaction with the player. Two such areas of research <coff> included Assassins Creed and Fable 2. Although both of these games have a far more complex general NPC population than what I am setting out to create, but the "research" was most enjoyable. First Step: Machine Intelligence "Kinda Almost": Machine Intelligence "Kinda Almost", simply gives an illusion that there is intelligence at work but there is not, sort of like, the lights are on but no ones home. There are several subsets to this group but the obvious one is simple animation. Also this can include proximity reaction behaviour, a posh and complicated way of saying when the player is near, stop what you are doing, and do this instead. But that's as far as interaction goes for those NPC's in this group. This simple ambient NPC type could also use lua scripts, loaded with the level and be left to attend to themselves. For example, just two chaps having a chat: Having a chat is basically all they do, its simple per character animation's controlled by lua scripts. The purple block volume is the walkable area that would be utilised by more "advanced" ambient NPC's, typically those that move about, particularly those that would use Pre-Loaded and Pre Calculated path routes for this particular level. The purple block volumes are simply required by the application I wrote to generate the route node data for the pathfinding tools I created and have demonstrated here. Not that this is a level just something thrown together for testing but I think I should unarchive some of my GMF format models and put together a small town/Village for testing this, rather than another simple "BlocksVille". There are obvious limitations to consider with this approach to the first tier of the Ambient NPC population for a "busy" town/village. The NPC's need animation's, most come with maybe 15 animation's (if you're lucky). My intention is to surmount this by adding animation's to them, primarily Mo-Caps. This will require a little work but will be the bedrock for the construction of this "tier". There are some very good applications on the market for achieving this. For me I prefer Fragmotion, there is also a free alternative that I also use on occasion called Pacemaker. But don't be fooled though, none of these applications will do it all "for you", you will need to skin the mesh to the correct rig for the plethora of free to use Mo-Caps, or indeed ones that can be purchased. It will all depend on budget and or requirement. This is still only a very basic outline for this "packing" stage, it will still require a lot of work but my goal is to get the impact of it at runtime to an almost negligible effect even when including proximity reaction behaviour.

Following on from "On The Right Path, A* Pathfinding In Leadwerks" I thought before I archive the code, I'd have a little "dabble" with a basic function to get an NPC reading the path data and then following it to the "target" I had a couple of ideas on how to do this but as time for playing in leadwerks was running out I opted for a basic idea. 1. Target Position Selected 2. Path from NPC to selection calculated. 3. Path transfered to a temp storage array for that particular NPC 4. An NPC Pilot reads that data. 5. NPC follows the pilot. Think of the "pilot" as the plastic stick thing on the underside of a scaletrix car .. it follows the groove in the track and the car follows right along. This was the quickest and dirtiest method but solved a variety of issues in one. Plus I just wanted to get the NPC moving and the sands of time were running out. So an hour later and I have not only the NPC following the generated path but the path is updated with a repositioning of the target and the pilot takes the NPC off onto the new track. This is all still quick and dirty, when I can remember what the code does and does not need, I will up a small demo.exe to the thread Pathfinding With A* EDIT: I have uploaded a demo.exe here : Hide And Seek Demo

Well, it has been a while since I made a blog entry, let alone done any work in LE. But I do keep an eye on the forum and Leadwerks in between Daily life and working on my project(s). I have also been going through my Blitzmax code archive, where I stored all my Blitmax/LE projects and code snippets (finished and not completed). One idea I had been playing with before, was basic NPC AI. I had some small success with some Bugs using autonomous logic. See Here In my "treasure trove" of unfinished and messy development code I found what was going to be the next step (for me) with AI functionality. The dreaded "pathfinding". I have read that Naughty Alien said he will be doing a two part tutorial on this and I am looking forward to that, having followed his work with Hidden Dawn I expect the tutorial to be top notch. But I wanted to get to grips with the in's and out's myself. So I started with the basics. I spent some time looking for code snippets and A* lib's in any language that had them to see of I could follow along what was being done ... Not a good place to start, in the end I spent some time reading "A* Pathfinding for Beginners", very helpful.I decided it would be best to start with a "2D" approach and maybe use nodes. Most 2D implementations use a grid based on the X and Y co-ordinates of the screen and tiles to represent an "unwalkable" tile. So I thought I would translate this approach to a 128 x 128 flat terrain with some primitive models to define the "unwalkable tiles". As this was a time limited "side-track" in LE from my other projects, it was all going to have to be quick and dirty. I wrote an app to calculate which "tiles" of the 128 x 128 terrain did not have an obstruction and then squirted this data out to a text file to be read into another app as a 2D array. The map data loads in a few milliseconds so this eliminated having to wait for the same data to be generated by the application I wanted to use to try and get the pathfinding working. One problem I did encounter was that I ended up trying to reconcile three different centre of origins for the co-ordinates. The map data had 0,0 at the top left, the terrain of course has 0,0,0 in the centre and my maths managed to get the A* to read 0,0 at the bottom left, after some profanity meditation I used some quick and dirty and hastily constructed math functions to bring them all into focus, thus as per usual the dev. code was a complete mess, atleast on that score I am consistent lol This version of pathfinding is very limited, mainly due to the way I created the node info. But for a first attempt I was quite happy. I have uploaded a demo App to the showcase , the picking can be a little temperamental and sometimes the quickest path is not always found and some "sightseeing" seems to find its way into the route. But on the whole I think it is definitely a platform on which to build.