Cover Based Mechanic

[Skormeus]

@agoose77

Running for cover can usually be a decision that’s evaluated prior to the execution. In some cases, you might have to handle dynamic cover (e.g using your team-mates as cover(!)), in which case you should be able to quickly perform culling tests to determine relevant parties.

For example, if such a feature existed, there would come a point where it is performant to have an AI manager build some kind of partitioning structure (e.g a quadtree) that allows fast near-neighbour lookups, or for simple games, just use a coarse grid.

For best results, AI needs to be a system unto-itself - there’s a lot of theory behind the subject.

Well the reason i update the nearest cover is cause the unit moves around. i guess i could make the list once of all the cover but id still have to constantly update the relationship of each cover to each unit

[Smoking_mirror]

Have you thought of using a more formal AI structure? I use a fairly simple Finite State Machine where each agent is only in one state at a time. This keeps them much more focused and reduces overheads. They perform checks like looking for the nearest enemy only about once every half second and otherwise continue to carry out their current task.

[Skormeus]

@Smoking_mirror

Have you thought of using a more formal AI structure? I use a fairly simple Finite State Machine where each agent is only in one state at a time. This keeps them much more focused and reduces overheads. They perform checks like looking for the nearest enemy only about once every half second and otherwise continue to carry out their current task.

No i have not thought of that. Well kinda but I’m terrible at all this so I just kinda do whatever comes to mind until someone tells me how wrong I am
that does seem more efficient though.

[Smoking_mirror]

You dont need to qrite your own state machine, blender game objects already have states. If you have one state for each action and an aditional state for decision making you can build quite an efficient and robust system with logic bricks and a couple of python scripts. What really slows down the majority of blender games is having sensors always sensing 100% of the time.

In my own game I’ve split the world in to tiles, and characters navigate between them. They only do checks when they reach a new tile.
The rest of the time they spend walking between tiles, or if in combat, doing their combat animation. 99% of the time the characters are carrying out a task, not making checks or doing processor intensive things. The trick is to make sure that they react to player input within a short space of time, otherwise they can feel very unresponsive. To do this I use message queues.

Say I want my character to jump, but he’s currently walking and won’t be finished walking for 0.6 seconds. So I give him a message;

player_commands.append("jump")

When the character has finished moving he picks up that message and acts on it. The 0.6 second delay isn’t really noticable.

Really your characters don’t need to be listening and looking all the time. Let them do a task and when they’ve finished they can evaluate any commands they’ve received, and act as seems best.

I sometimes even give my characters thinking time. Just a state with a count down and an animation to show them looking about deciding what to do. I use this after they did a pathfinding check and couldn’t find a valid route. It stops them spamming requests for a new path and it also makes them seem more alive, less machine like. Also after a while it’s lkkely that other characters will have moved or died or whatever and a valid route will have opened up. Sometimes I send them to the idle state for a while for no real reason. Maybe they’ve been patrolling for a while and didn’t find any targets. It looks nice to see them stop and look around.