1
\$\begingroup\$

input reading = NPC reads the input of the player and instantly reacts to counter everything the player does.

So, is it like :

if player in range and key is being pressed : 
   
Npc reaction 

Is that right? What would happen if there more players? is it as easy as getting the input of the closest player?

What ways are there to predict the input of players? Like say some players are spamming dodge and parry like DarkSouls is their middle name, how do I make the enemy NPC adapt to player patterns?

\$\endgroup\$
7
  • 3
    \$\begingroup\$ You'd be better off having AI react on state that results from the key being pressed (or gamepad, or joystick, or touch), rather than on the keypress itself. So in your input processing phase, you'd set e.g. if (up arrow pressed) then set playerJumped = true, and thereafter in your AI reaction phase code, check if (playerJumped) ... Prediction is a hard topic. I'd keep my expectations low if I were you, as it sounds like this is one of your first projects. \$\endgroup\$
    – Engineer
    Commented Jul 6, 2023 at 1:22
  • \$\begingroup\$ @Engineer i heard they did it as far back as in the arcade games era, apparently this is a perfect example : github.com/K4thos/UMK3_3DO/blob/master/src/MKBOSS.C but i can't read that \$\endgroup\$
    – Cei
    Commented Jul 6, 2023 at 1:31
  • \$\begingroup\$ What is it about this example that you need help reading/understanding? Edit your question to reflect that and folks can post answers to help demystify it. \$\endgroup\$
    – DMGregory
    Commented Jul 6, 2023 at 11:30
  • \$\begingroup\$ @DMGregory it's written in C, the last time I used it i made my first std : hello world \$\endgroup\$
    – Cei
    Commented Jul 6, 2023 at 16:40
  • \$\begingroup\$ The more specific you can be about the problem, the faster you'll get help. If you say "I understand this bit, but I don't know what these lines are doing", you'll get useful answers much faster than saying "I understand nothing, explain everything". \$\endgroup\$
    – DMGregory
    Commented Jul 6, 2023 at 18:29

1 Answer 1

1
\$\begingroup\$

You can have the NPC read input, yes. However, that is unlikely to be enough to counter the player, as - chances are - positioning is important.

For example, having the NPC to shoot a projectile leading the player requires to look into the player character speed, the distance to it, and the speed of the projectile to compute the optimal direction to shoot. There are question on the topic on this site, try searching.

In that case the speed of the character, and its position, are part of its state. We can easily turn input into state with the approach that Engineer comments: if player is performing an action (e.g. because of user input) set a bool flag, or change a state variable.

Then, for the case where there are multiple player characters, the NPC can use a "sight" area where it detects player characters, keep track of them, and pick the closest one. Having a reference to the player character, it can read its state.

Furthermore, changing the input scheme would not require to update the NPC code.


Adapting to player patterns require to first identify the patterns. And then have some strategy to counter them. Presumably you would have a finite number of strategies programmed (barring machine learning), thus I suggest to think about the problem the other way around: for each strategy the NPC can use, what are the conditions for it to work, and then figure out how to check for those conditions. You would, of course, use feedback from player testing to improve it.

Checking if an strategy might work could - again - require to check positioning (e.g. distance to the player character), and might involve line of sight (i.e. raycast) or dedicated detection areas, in addition of checking the state of the player character (e.g. check if it is invulnerable to some attack).

In fact, you might not limit yourself to a single player character! That is, instead of checking which strategy can be applied to the closest player character, you might check on which player character each strategy can be applied. You might have it pick an strategy at random until it finds one that works, or go down the list in a predefined order, but be careful to not harm performance by doing too many checks in one frame.

About prediction, you need to think how the states of the player character will change. For example, you might know that a typical jump of the player has it landing in 1.5 seconds (again, as an example), using that the NPC can use an attack that - approximately - will hit the player when it lands. Something similar can be applied to temporary buffs or player abilities that have timeouts.


I will ultimately depend on your game mechanics, but I hope this give some idea of how to go about it.

\$\endgroup\$
1
  • \$\begingroup\$ To add one advantage of countering on state, but not on input, is that if you're countering at input, it'll probably get frustrating as they seem to have invulnerability - you don't want your A.I. to always act like Daigo, usually. \$\endgroup\$ Commented Jul 9, 2023 at 0:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .