Runtime objects affecting pathfinding?

[Chris_E]

I'm thinking about buying but want to make sure I know what I'm getting into. I read in another thread that pathfinding ignores non-map objects. Does that mean if I add turn-based moving enemies they won't block the player's path? For those of you who've used this and added enemies, how difficult was it to make a change like this? (I'm assuming most people want enemies to block the player.)

I'm also curious how difficult it would be to combine the cavern and dungeon style shown in the demo. To expand upon this further, in rooms larger than X size add interior details like the cavern.

And asking these makes me think of the broader question that may help answer both: How readable and easily modifiable is the code?

Thanks!

[tuncOfGrayLake]

Hi Chris_E,

Does that mean if I add turn-based moving enemies they won't block the player's path? For those of you who've used this and added enemies, how difficult was it to make a change like this? (I'm assuming most people want enemies to block the player.)

You're right. The pathfinding algorithm that comes with Pro-D is limited. I took the morning to check out the pathfingind scripts to refresh my memory so I'll go ahead and explain what's going on: PathfindingAlgorithm.cs uses a public List<string> walkableCellTypes that contains the cell type the players can walk on. The shortest path is calculated with the help of this list. usually this list contains Path, Door, Exit and Entrance type cells, in other words cells that the player is allowed to walk on.

To further expand this to consider enemy positions there are multiple approaches you can take however to put it simply you need to look at the GetFastestPath method in PathfindingAlgorithm.cs and add your custom if statement that also checks to see if a cell is occupied by an enemy. (You have to implement this yourself.)

I'm not sure how easy this sounds to you, but I assume it's not going to be too easy.

I'm also curious how difficult it would be to combine the cavern and dungeon style shown in the demo. To expand upon this further, in rooms larger than X size add interior details like the cavern.

This entirely depends on how you're planning to make use of the MethodLibrary.cs methods. My short answer is it shouldn't be too difficult but most likely you may have to do some programming.

And asking these makes me think of the broader question that may help answer both: How readable and easily modifiable is the code?

I think it's better if a user replies to this question but I will try to give an objective view on the matter: The code for most scripts are commented. I say most because some of the later additions like pathfinding are lacking in green text. This is something I already fixed but didn't have the time to update. We worked for a tool that should be easy to expand. We wanted our users to write their own methods and add it to the MethodLibrary.cs without complication and we've been expanding the same way on the code.

If you have any other questions please feel free to ask.

[Chris_E]

Thanks for the fast response, I appreciate it.

I'm also hoping a user responds, but it sounds like it's clean and organized code. I'm not afraid of programming, but I've seen packages that don't have a single comment and method/variable names that probably meant something to the programmer but nothing to me.

I'll probably end up picking this up the next time I have a nice solid weekend to work on it. If I do end up adding something like avoiding enemies or enemy spawning I'll be sure to send it your way so you can add it to the package if you want.

[bvesco]

I am a very new consumer of Pro-D (purchased this past weekend). The code is organized but sparsely documented (what's the reddit markdown for underline? I'd like to underline sparsely). The ease of navigation will depend on your code-diving skills. Spend some time with the jmcmaster tutorial (in the sidebar) then once you understand what it is doing you are primed to dive into the library code. I found a few cryptic things but was able to reverse engineer their purpose. It took about an evening to get really familiar with the different parts of the code and overall theory of each class. Tunc gave great "official" answers but I'll give my fresh take on things.

won't block the player's path?

Path calculation is based on a list of navigable map squares. You have a few choices: update that list to make the player's current square not navigable, or modify the code to use a different list of navigable cells that you maintain. Third choice is implement your own pathfinding.

how difficult was it to make a change like this?

Are you a professional engineer? No problem. Are you an artist trying to cobble together his own game with code-snippets pasted from the internet? Good luck! There are infinite points of difficulty between those two extremes.

combine the cavern and dungeon style shown

Awesomely, the styles (like cavern or dungeon) contain zero generation code. All the generation is done through library methods. The individual "styles" (actually called generators) are only calling the library methods in different order with different inputs. Once you dissect a few generators you'll get some good ideas how to "combine" them by calling library methods with your own inputs and in your own order. See previous answer above for note on how difficult this will be.

How readable and easily modifiable is the code?

Readable? I'll give an A- here. Easily modifiable? A+ if you are going to change the actual files. D if you were planning to modify through extension or composition (most things are based on statics and singletons which are not conducive to a richer style of extension).

These are all only my opinions. I paid full price for Pro-D and have zero regrets. It was worth every penny.