Pixel Perfect

It's a nice idea but unfortunately my experience of community projects in general has not been a good one, they tend to collapse long before they produce anything useful and that's if they even get that far! I looked at Dark AI initially and although I could see the possibility of it integrating into Leadwerks it didn't look immediately obvious how easy that integration might be and would involve registering entities rather than DarkBasic objects with it and reading back their positions rather than have it directly control the movement. Plus it looked like you needed to register all of the geometry vertices for the path finding side. On top of this it didn't appear on the face of it to offer the level of AI I wanted and wasn't really capable of any degree of customization coming as a DLL encapsulated plugin or lib file. Whilst it may have represented a quicker route of getting something up and running it was never going to substitute for a custom designed AI system. As I never actually purchased it to play with it I may be completely off the mark again here so feel free to correct me if any of those assumptions are incorrect. It's great to hear that you have it integrated though and I'd certainly be interested in seeing a working demo at some point but my interest in it is more out of curiosity than a real need.

Nice solution Mack.

From my experience most users care little for what is going on 'under the hood' just simply that it works and looks realistic. If something doesn't look right they will say. Any demos I've ever shown people pick up on all sorts of things even though they are often not the focus of the demo at all. It's all good feedback which isn't a bad thing. Whether we do anything with that feedback is entirely up to us, but it's good that people take the time to provide it imho.

My understanding is minimal, Josh would be better explaining this, but I believe the engine creates an internal structure presumably for each object which is associated with picking. Large objects with lots of surfaces seem to take a while to construct and I believe Josh suggested he might do this internally at the time the model was loaded but for now we have to do it ourselves by triggering this with a raycast. It only occures the first time the model is raycast. If I'm way off the mark I'm sure someone will correct me on this or fill in the detail. lol Yes and thanks, this would be of interest. I'm part way through my own AI implementation but I'd be interested in seeing how this performs!

The starting point is always the location of the character, unless you want your character to teleport It then moves to the first node selected in the path. The first node needs to be the closest node in the intended direction of travel as I'd previously suggested. Simply choosing the closest node is not always good practice as this may lead your character away from the goal initially which is exactly what is happening here! As obstacles may sometimes result in the path going away initially from the intended target to avoid the obstacle this is not always as straight forward as it may seem. Welcome to the world of path finding I would say that if moving to the first node in the path results in you getting further away from the next node in the path then you probably lie between the two and should ignore the first node and head for the second so long as there is a clear line of sight between you and the second and no unwalkable areas in between.

Looks to me as if its just chosing the nearest node as the starting node when the previous path is invalidated rather than the nearest node in the intended direction of travel! With sizable node spacing this is quite noticable.

Works fine on my system and I really like your little animated character ... great fun! Only criticism is it seems to suffer from some very zig zag path generation at times which looks every un-natural and also (my system also got criticised for this same thing) it doesn't attempt to smooth the direction turns at all. I would like to see this in a densely populated environment too to be able to better assess it, just about any algorithm should be able to negotiate its way round this test level without any issues. Looking good though, nice to see so many alternate path finding systems coming on line now

I was interested to see how you got on with the DarkAI library when you previously indicated you were using it. My personal feeling is that you are better just settling down to writing your own AI routines. AI tends to be fairly well tailored in most games to the games needs and you will never get better results for 'your' game than by designing it yourself. Path finding is a separate thing, but just as necessary and could be provided (and in my opinion should) by the game engine SDK. But personally I'd not wait for that either, just roll your own! I can't see Josh ever providing AI other than maybe some very simplistic functions which would be unlikely to be sufficient for any serious game. With regard to the raycast pause problem, I believe the current workaround is to raycast all objects after loading them (presumably on a per level basis) which then avoids this initial first time pause issue in gameplay, but I've not tried it myself.

OK, that's reassuring. Thanks for the confirmation.

One more question regarding the new development. For all of us who have currently invested heavily in version 2.x development how long can we expect support to continue for this and will it simply be dropped on the release of version 3.0 or is there some intended support plan for version 2.0 users above and beyond that point?

Thanks Lumooja, just what I was looking for

So without committing yourself in anyway Josh ... what are the key additional features you have in mind for Leadwerks Engine 3.0 ? What should we be looking forward to?

Static linking with a .lib file requires no dll at all, nor does it when the .exe is executed. The lib contains the object code. Both are normally delivered to give you the choice between static and dynamic linking.

Agreed, STL is definitely the way to go.

Sounds like a great move. I'm encouraged by you taking your time before diving into the code and putting issues out the community for feedback before committing yourself

Looking good MG! Nice to see other people tackling this too. Path finding is an essential foundation for most games that intend to have any kind of NPCs or dynamic moving animated objects that are not directly controlled by the player or players. Not surprising Josh is now talking about including some form of it in version 3, it's just so fundamental I was surprised it wasn't an inherent part of Leadwerks 2. Look forward to seeing how this develops.

This is the natural inflation in Lumoojaworld Joking aside, it's nice to have the choice, by the time lots of other third party code has been included you can end up with a lot of DLLs.

But then you can't have a static build! Would be nice to have the choice to statically or dynamically link if it's not going to cause Josh too many problems maintaining it.

.lib for me too please

The resynthesizer plugin for Gimp is just the Dogs Danglies How did I live without this before!!!

That was the confirmation I was looking for and good news as I'm still working on my Leadwerks engine and keeping my options open.

Simply stunning! The poppy field was a favorite.

That really made me laugh

Hi Andrew, most people seem to go with third party networking libraries. RakNet appears to be the one most commonly recommended. The rest is down to you! There are quite a few people designing networked games so I'm sure if you have any specific questions they will be happy to help.

Seems to work well enough, quite impressive really! I'm not sure how far you can take this but it has to help reduce the workload conciderably. Good solution.