Development Blog

I would think that your time would be more valuable in getting other parts of the upcoming game engine polished.

 

Marley's Ghost and myself have both created reasonably solid libraries in a reasonable amount of time, both in C# and Lua varieties. I would think with your advanced knowledge, and the assistance of the community, you could create an entirely custom pathing system that is optimized for your engine!

Yes, but those are all node or grid based, are they not?

I'd say get in touch with this guy: http://www.arongranberg.com/unity/a-pathfinding/ and see if he'd want to do it.

 

His Unity implementation is pretty nice, offers good performance and a bunch of features including grid based, point based, imported navmesh and recast based navmesh generation.

 

I like having the option of using different types, as navmeshes are very performant if you don't need to change it at runtime, but grid based is a lot faster to update if you need to dynamically add obstacles at runtime.

 

Multithreading is also a huge plus, since I usually don't care if a path takes a couple frames to solve, as long as it doesn't impact framerate while it's solving.

 

Anyways, just my two cents, which isn't worth much in this economy.

 

P.S. I *think* recast works by voxelizing the poly mesh then generating a navmesh that fits that. But that's just the impression I got from reading something somewhere and may be totally incorrect.

I vote a mix of 1 and 2. Hire someone to do it, but make sure they knowledge transfer to you so you can maintain it.

 

I would think that your time would be more valuable in getting other parts of the upcoming game engine polished.

 

I view pathfinding as a critical piece in any game engine. I'm using a grid based Lua library, you and Marley have libraries, Pixel wrote his own editor even, but think of the time you put into those. Would be so much easier (and cheaper if your time is worth money) if Josh has it in the new LE. If people did all that for learning purposes then that's cool, but I'd prefer to just use a library built into the engine myself.

P.S. I *think* recast works by voxelizing the poly mesh then generating a navmesh that fits that. But that's just the impression I got from reading something somewhere and may be totally incorrect.

Yeah, but 2D voxels are just a fancy way of saying a grid.

No, I was talking about actual 3D voxels, then reskinning it to create a (hopefully) simplified mesh.

I found some recast code that actually makes some sense. Fingers crossed...

Yes, but those are all node or grid based, are they not?

 

 

A* is A* its an algorithm .. nothing more nothing less. Nodes, Waypoints, Grids, names and addresses, towns and roads and Navmeshes are just what can be used to create the data that makes up the graph that it uses. Recast makes a navmesh its Detour that does the pathfinding and spatial reasoning. A tile map is a collection of grids, waypoints are a collection of linked nodes and a navmesh is a collection of polygons. tile or waypoint or ploygon makes no difference essentially they are all just a collection of nodes with connection information. All I am doing currently is experimenting with different ways to assemble that graph data. The A* remains unchanged except for the interface between it and the data.

Okay, I have a large amount of navmesh generation code compiling. It's nowhere near working, but I have learned some things.

 

The most important thing to understand is that recast is NOT a library; It's an open-source program. The code doing the heavy lifting is very impressive, but this thing was not designed as a general library with commands to be called from an external program. You've got to extract the parts of the program you want, and try to comment out all the calls to things you don't want, like OpenGL rendering, the GUI, etc.

I can't assist on code but what I learned the last two years is that you can't do everything on your own. I used to try to do everything on my own too but at a certain point this is just unproductive. I COULD do high-poly trees for projects myself but its just more cost efficient if I buy a library and invest this free time in other things.

 

Same with outsourcing to freelancers. Before you get mad with recast hire someone if you can afford him and invest this time other LE3 work. Imagine what you can do in 6 months if you outsource this problem.

I would guess you could find someone here:

 

AI Game Dev

I vote a mix of 1 and 2. Hire someone to do it, but make sure they knowledge you and Marley have libraries, Pixel wrote his own editor even, but think of the time you put into those. Would be so much easier (and cheaper if your time is worth money) if Josh has it in the new LE. If people did all that for learning purposes then that's cool, but I'd prefer to just use a library built into the engine myself.

 

 

I assume Pix wrote his editor to be able to create the graph data for the pathfinding to work on, the A* is the easy bit. My solution in Bmax took a week, 2 days to write the A* as I had no idea what it was and the rest of the time to find a way to generate data from a test level on which it could chew. My Lua A* took a day to write from scratch, with most of that time spent learning Lua, I am now still finding ways to generate the data for a level on which it can chew. This time had to be spent, as LE has no inherent pathfinding. I'd prefer to just use a library built into the engine also, but until there is a version of LE that has that functionality there is not a lot of options.

I would think that your time would be more valuable in getting other parts of the upcoming game engine polished.

 

i agree with Rekindled here... right now we have several options in the mill... this is something that definitely can be added later if you deem it necessary...

 

besides... what's wrong with some decent node based A* pathfinding anyways

 

 

--Mike

I'm focusing on the gameplay features first and foremost. Pathfinding and flowgraphs are more important than having another post-processing effect.

I'm focusing on the gameplay features first and foremost. Pathfinding and flowgraphs are more important than having another post-processing effect.

 

not to somone who can add their own gameplay logic and not to someone who really has no interest in joining lines together...

 

and there are plenty of those people here...

 

 

gimme a good post processing effect though, (water was what you were jabbing at)... and, i'll be a sold pony!!!

 

 

but hey, i'll be content to leave all that up to you... seems like you've been making steady progress so far... so...

 

and after all, this is your baby... you know how you want her to turn out...

 

i was just adding my 2 cents to the discussion... as i thought that feedback from the peanut gallery was what this was all about...

 

sorrrrryyyyy... my mistake...

 

--Mike

Right, a lot of people can do that, but the problem is we then branch the code, and each programmer becomes an island. This causes the rate of collaboration to be pretty low.

 

With a built-in navigation system, we can share AI scripts and they will all work together. We can even write different AI scripts and make them battle.

 

In the past, I figured that my job is to provide the graphics and physics foundation on which gameplay is built, and then let the user take over. I don't think that approach has worked out very well, except for a few people who already know how to write games.

I don't think that approach has worked out very well, except for a few people who already know how to write games.

 

Making video games is an interesting thing because the reality is there are many common tasks that the majority of them have. Who plays a video game and thinks that the pathfinding in this game is amazing and really makes this game stand out from others? These tasks just have to not suck instead of being revolutionary.

 

People aren't redesigning entire car engines for each new car because there are parts that are tried and true. The same should be for game engines. It shouldn't be just about making drawing and physics easier, but to provide the tried and true parts of a game.

 

I wouldn't even consider pathfinding a gameplay feature honestly. It's as essential as physics in modern 3D games and generally physics isn't considered gameplay. Bullet time, combat systems, weapons and things of that nature is what I would classify as gameplay and those are the things that make games stand out from each other. Those are the things that I don't think you want to get into the business of making and those are the things that dreaming game designers think of first when they think of a new game. When you dream of your amazing game that you want to make you aren't dreaming about pathfinding or networking code, you are dreaming about the unique gameplay features like the cool kinds of guns you want or the different abilities you want your character to have access too

 

30 years ago maybe pathfinding would be considered a gameplay feature, but I think it's graduated to essential core engine feature.

Just realized this...

 

The pathfinding stuff is actually the last bit of research I have to complete before I know how everything in Leadwerks3D works.

Does this mean you know how to do water/ocean/river like you want to???? Because I think that was an unresolved challenge some months back, if I remember right and caught all the news.

 

Also, Rick, good point. Some things are simply expected of games, just as they are of engines. People don't notice if they work but they definitely notice if they don't.

I know enough about how it will work, it's just a matter of hard work.

Ah, great news. All the best with that too then.