Some questions

[jjbrunton]

Thank you for this great library,

A couple of questions:

• Should we be storing the state across frames or recreating it based on the actual state of the world?
• Your example shows startPlanning producing a state which is then fed to getPlan which mentions in the documentation as the "end state".. Is that correct?

[negativeview]

Oh wow, issues are not highly visible!

I generally stored WorldState across frames. Either way works, depending on what works best for your code. Creating a new WorldState in every frame would likely lead to a lot of garbage, though. (Note: this library isn't ideal for garbage generation as-is, I've started and then abandoned a few ways to mitigate that over time.)

State and GlobalState, as indicated by being in the internal namespace, are meant to be treated as a sort of black box. They are messy for the end user.

But the way it works internally is that when you start planning, you provide it with the initial WorldState, which represents the world as it is now. This library creates a whole host of internal information about what actions are possible, what happens when different actions are run, etc., all wrapped up in a GlobalState. It also keeps track of the most promising chains of events it has found thusfar. The class State represents the current state of the planner.

Eventually, Planner.stepState returns true, which indicates it thinks that it has found the best possible solution. But that solution is still in an internal format that is hard for an end user to parse (and also in theory might change). You pass that into getPlan to convert it to a stable, end-user-friendly format.

Does that make sense?

[jjbrunton]

Thanks for taking the time to respond. That's really helpful.

You mention in Goal that it isn't necessary to return true in the case of isSatisfied, in that case, surely a plan would never be generated? Essentially I'm trying to maintain a loop of something similar to a leveling up sequence:

Goal level up woodworking

Achieved by

Gather x resources
Craft y items from x resources
Level achieved

Apologies if these are stupid questions!

[negativeview]

So, generatePlan will generate a plan from the best looking path it has found, regardless of if it is "done" or not. The whole isDone thing is just to make the common case easier.

I show an example of not using isDone at all here: https://github.com/negativeview/gracefulcode-ai/blob/master/src/test/java/A005_Happiness.java

My intention was to be able to a) have AI that is kindof "dumb" by not letting it make complex plans and/or b) to limit the amount of cpu time the AI can take up by only giving it a fixed amount of processing time before just choosing the best plan. But it can also be used for something for which there is no "end," such as happiness.

[jjbrunton]

Perfect, thank you. I had looked at the unit tests but had missed that the happiness test returns false!

Final question if you will. Should the behaviors need to null check the worldstate? I've got a somewhat working solution but I am finding that isRunnable is sometimes fed a null by Planner:105 (prior state).

At a high level, I have a flow of:

Gather resources
Get tool to process resources
Empty inventory
Get tool to process previously processed items
Craft final items

Thanks again and thank you for this library!

[negativeview]

In theory, no, you shouldn't need to. There is at least one rate bug that I know still exists and has been a bear to track down because of a lack of consistent test case. After a meeting I'm about to go into I will look into when worldstate could be null. I don't believe that's ever intentional though.

[negativeview]

@jjbrunton Is it possible that you are calling stepStateWithBehavior when the plan is already "finished?" It looks like that can cause the NULL issue you described. I should have put in guards for that case, but it looks like I did not. If that's definitely NOT what you're doing, I can look for another potential cause.

[jjbrunton]

@negativeview Thanks for that. Sorry for the delayed response.

I think it could possible that my engine potentially calls it when finished so I'll put it down to that.

Thanks for answering all these questions!