I’m diving deep into the design of my turn-based game, and I’ve hit a bit of a snag with how to evaluate actions for the AI without messing with the game state or duplicating logic. Here’s the deal: each unit has a bunch of different abilities—like various movement types (think run, teleport, charge in a straight line) and different kinds of attacks (melee, ranged, thrown). I’ve structured it with a pretty straightforward system using a `CanExecute` function to check if a unit can use an ability, based on things like time units, inventory, and state. If everything checks out, the `Execute` function gets called to actually perform the action.
This works beautifully for player-controlled actions, but as I implement Utility AI, I see a big issue pop up. For example, I want the AI to consider an action like “move and melee attack.” So, I can list all reachable cells using the `move` ability, but then I need to check all possible targets for a melee attack once the unit gets to those cells. Here’s where it gets tricky: my `CanExecute` function relies on the actual state—so doing a chain of `CanExecute` calls is leading me to incorrect results. Essentially, if the outcome of the melee attack depends on having first executed the move, I’m stuck.
I thought about splitting this into two actions (moving first, then attacking), but it still feels clunky since I need to validate that moving to a specific cell is meaningful. I might find myself in a situation where I move into position only to find out later that I’ve run out of time units to attack.
What I’m considering is simulating the outcomes of actions so I can effectively chain `CanExecute` calls without altering the actual game state. This would mean I’d need to simulate things like position, ammo, time units, and facing. I really want to avoid duplicating logic though. I’m starting to wonder if the functions should lean more toward being stateless and if I should be looking at immutable objects.
Am I on the right track here? Should I keep the AI validation logic separate from the overall ability system, and would that truly count as duplication? I’m really unsure about what the best approach might be, and I’d appreciate any insights or perspectives from those who’ve faced similar challenges!
Your inclination towards stateless evaluations and simulating outcomes with immutable objects is precisely the right approach. Ideally, your action-checking functions (like
CanExecute) should accept a snapshot of the game state as input and produce their validation results without modifying that original state. By structuring these game-state snapshots immutably, you can safely and efficiently simulate “chains” of actions to feed your Utility AI, leveraging the same logic for checking action validity without side effects or unintended changes to the real game state. This method allows you to test various scenarios in isolation, ensuring your AI reliably evaluates each potential move without duplication of validation logic or inconsistencies.Additionally, focusing on immutable inputs and pure functions naturally encourages reusable, reliable, and easily testable logic. This does not constitute logic duplication as long as the shared input structure and validation logic remain centralized in your core system, reusable by both player control and AI decisions. Maintaining the action-validation code shared between the user interface and AI modules prevents branching or diverging logic paths. In short, you’re on the right path: by maintaining clear separation of validation and execution layers, using immutable snapshots as inputs and keeping the logic shared, you’ll design a robust solution that is simultaneously flexible for your AI evaluations and maintainable in the long-run.
It sounds like you’re hitting some classic design challenges that come up when creating AI for games, especially with turn-based systems. You’re definitely on the right track by considering how to simulate actions without directly affecting the game state. That gives you the opportunity to test combinations of moves and attacks without consequences.
One approach could be to create a temporary “simulation” object that represents the state of the game as it would be after performing a specific action. This would allow you to call `CanExecute` on this temporary state, which can model the game conditions post-action, without modifying your actual game state. With this setup, you can keep your ability logic intact and avoid duplication.
Regarding your concern about separating AI validation logic from your ability system: you can definitely maintain a single source of truth for abilities and checks, but implementing a simulation layer gives you the flexibility to evaluate different action chains effectively. This way, you leverage your existing logic for both the player and the AI while ensuring the AI can explore decisions without disrupting the current game state.
Another option might be to refactor your action logic into a more functional approach, where each action takes inputs (like current state) and returns outputs (like the result of an action and whether it can be executed). This would help you keep things stateless, making it easier to chain actions for the AI and compute what the best moves are without side effects.
Keep experimenting and refining your approach! Every game design challenge is an opportunity to learn and grow your skills.