The answer given there seems to refer primarily to in-game character control, which is a quite different problem from the long term strategy issue of building the team over time.

24 minutes ago, Kylotan said:

The answer given there seems to refer primarily to in-game character control, which is a quite different problem from the long term strategy issue of building the team over time.

Well I can see very easily how I'd be able to use the Utility method to handle both...

If, say, a player has a decision to make about whether to accept a lower offer to stay where he is or take a higher offer to go to a bad team, for example, I could use various personality traits like loyalty, greed, ImportanceOfWinning, etc to basically add or subtract dollars from the two contract offers, which is sort of what actually happens in their minds...if they are loyal and like where they are, that is "worth X amount of dollars" to them...likewise if they are greedy and not loyal than the offer for more money is the one they will likely go with...

So I can see how the Utility method could be easily modified to work with both but I'm wondering if the same could be true for the method he discussed as well...or is it possible utility methods would be used inside the behavior trees?

A behaviour tree is basically a large prioritised list of actions. It looks more complex than that, because the hierarchical structure makes it very easy to adjust the priorities for large groups of actions, and to make certain actions never run unless other actions have happened first, but ultimately it's a list based around some very binary decisions made at each branch of the tree. It's theoretically possible to inject utility scores in there, and this is commonly done for very specific sub-tasks, but it's not a practical approach on a wider scale.

4 hours ago, IADaveMark said:

A "state machine" isn't necessarily a decision architecture. It is a way of keeping track of what state you are in. You can use all sorts of stuff on each of your many transitions to determine what to do next. A BT is, ultimately, going to result in you being in a state of some sort. The difference is that you are lifting the transition logic out of the individual states and putting them into a single reasoner. The result is the same, but the decision logic is cleaner. A utility system will also put you in a state if you want it, but, like a BT, the reasoner is a separate entity. 

For your game, the heavy lifting is done in the reasoner itself. You actually will have few, if any, "states" that you are in. You may have "mindsets" that coaches and GMs are in (e.g. "rebuilding year") but those are just numbers that affect how you look at other numbers.

 

OK got it...that makes more sense now...

As for the "off year", that is a good utility function.

If all your options are to buy then that's all the AI will do.  The AI won't have an option to NOT buy because all the options available are to buy.  If you want the AI to have an option of not buying, you need to add those in as well.

The action could be something as simple as "don't buy". Or it could be "save for a bigger purchase", that could evaluate what is available right now versus speculation about what might be available later, and the costs of both. 

If you include additional options, "saving for the future", or "off year", or "nothing looks interesting", the new options provide an alternative to spending everything.  Each could have their own weighting functions, and there can be more than one of them.   A baseline "nothing looks interesting" is useful to have in nearly all scenarios, since you don't want the AI to spend every coin they've got.... unless you really do want them to spend everything.

1 hour ago, frob said:

As for the "off year", that is a good utility function.

If all your options are to buy then that's all the AI will do.  The AI won't have an option to NOT buy because all the options available are to buy.  If you want the AI to have an option of not buying, you need to add those in as well.

The action could be something as simple as "don't buy". Or it could be "save for a bigger purchase", that could evaluate what is available right now versus speculation about what might be available later, and the costs of both. 

If you include additional options, "saving for the future", or "off year", or "nothing looks interesting", the new options provide an alternative to spending everything.  Each could have their own weighting functions, and there can be more than one of them.   A baseline "nothing looks interesting" is useful to have in nearly all scenarios, since you don't want the AI to spend every coin they've got.... unless you really do want them to spend everything.

 

After more thinking about this, I actually am going to create enums with both team states and cap states because the two don'thave to be exclusive to each other...

For instance, the team states I have right now are TotalRebuild(What Jets and Browns did the last few years---complete firesale aiming for #1 pick in draft), Rebuild, Transition(when a team changes coaches/GM's and philosophies that go with it meaning players might be let go due to scheme fits), Building, WinNow and Reloading(when a team realizes the current key players aren't getting it done so they replace them but still expect to win(usually through FA))

Cap state will be tied to how they spend money under the cap and current options are CapConcious(sets a value or players and won't overspend regardless of how good they are), SpendOnOwn(team mostly focuses on resigning it's own payers they've drafted and very little in FA), SpendOnFA(teams focus on filling in holes via FA), and Flexble(meaning more or less they don't have a plan and do whatever---which is a lot of teams surprisingly--think Redskins)