/games/ - Games

replace sand with moondust

Weird Al??

>>39156
>Now with most shooters, this basic feature is no where to be found.
Why do they exist in the first place? If they can commit to neither realism nor arcadiness then why even bother? You get this boring poorly-designed mess instead.

Is this even truly a design flaw?

Consider this: All the enemy NPCs hiding behind cover so you can shoot them is realistic, but it isn't FUN. You, the player, want to shoot the enemies. If they're hiding behind cover, you cannot in fact do this.

You will enjoy the game more if it makes its enemies stupid, and you get your power fantasy, than if you're hiding behind cover and they're hiding behind theirs and none of you ever do any damage.

So basically there's a couple of problems to solve with this.

<1: scripting vs dynamic detection>
For any gameplay feature, there's a sort of tradeoff you have to make based on the way you're building the systems. On one hand you can program the features directly into things, like in this case giving a scenery object code to treat it as a potential piece of cover. On the other hand, you can have the game determine this stuff on the fly, like having the NPC scan the area around them looking for objects and then doing calculations based on things like hitboxes. Which version or which mix of both would work best for the project depends on a lot, including the way the game works and the way the dev team collaborates.

Bethesda games are kind of bad for either option. You don't want to program "use me as cover" into a rock scenery object, because a level designer can position that rock in a way that would make it unusable as cover, e.g. burying it mostly in the ground or placing it against/in a wall (they do this often). In those cases, the rock would be telling the AI it's valid cover and cause it to either act silly or just waste computation on invalid options. You also don't really want to have the game calculate things on the fly, since the games tend to be so full of clutter and have complex terrain meshes and broken navmeshes. You would need a more bespoke approach for that case.

<2: optimizing behavior and pathfinding>
Regardless of how you determine valid cover locations, the NPC has to determine where to go and how to get there. Bethesda games are pretty notoriously bad with enemy AI and pathfinding. Part of this is lazy AI design and part of it is bad navmeshes and part of this is little awareness of the environment. Idk how exactly the AI is set up, but it appears to prioritize aggression in combat ahead of seeking cover, meaning if they're in combat with you they'll just stand there and shoot without ever trying to take cover because they just don't ever check for it. This could also be ameliorated by including behavior for both moving to a target location and shooting (suppressing fire at least).


The simplest solution for a Bethsesda game is probably something like the one implemented by this mod https://www.nexusmods.com/skyrimspecialedition/mods/111890 where the NPC checks periodically if they are behind cover and moves to a new location if not. This is probably the most important component. You could add complexity on top of this pretty easily, like doing multiple raycasts from the NPC to the player to see where the limits on the cover are and what areas are exposed (like one for head, one for chest, etc) and determine whether they need to crouch to be protected. Another option is to have a top-level system in the combat AI that looks for available cover and then assigns it to NPCs in combat. For that you could spawn a very simple "virtual" character (invisible) at the cover locations to run the kind of checks described above to see if the cover is valid. The system could then be checked by NPCs when they lack cover to find the closest/best option (in complex environments, you would probably want to store the cover options in a quad tree to make the search as efficient as possible). A cover option should be rated based on its distance (inversely proportional, ideally based on pathfinding distance) and how effective the cover is determined to be by your virtual NPC.

>>39164
Most players find it more engaging to have some kind of challenge instead of NPCs just standing in the open to be shot. There is an ideal balance between a shooting gallery and realistic tactical behavior that would be most fun, depending on the player preference and other game mechanics. You probably want at least some tactical behavior though, since it adds more ebb and flow to the combat when you have to either wait for NPCs to move into the open or you have to actively move around them to negate the cover.

>>39164
Power fantasies aren’t really fun. Besides NPC fights are fun to watch

>>39166
every QA team disagrees with you,they hate covers,they hate not having yellow paint everywhere to follow,they hate being stuck for 5 minutes on a puzzle,they love being handheld the entire time and that's what the game designer end up recieving as feedback

>>39169
There ARE people who aren't into power fantasies, but those tend to be into multiplayer FPS, I think. Specifically the sort where there's 64+ people on your team and you're zerg rushing a choke point.

>>39164
It seems like it's a problem with military shooters where enemy design is virtually nonexistent. Doom, Quake, etc are all challenging and interesting games despite the enemy AI in them basically being "if you see the player move towards them and attack" because most of the enemies has a unique purpose that creates interesting situations you have to figure out when you mix them together.

Then you have military shooters where the enemies are usually: hitscan (mid range), hitscan (long range), explosives man, and armored man and you're mainly fighting the first 2 for 80% of it where the approach to them will be sitting behind cover and then shooting them when they pop their head out or run out into the open in a glorified game of whack a mole.

>>39156
>game developers assign certain objects marks that tells an NPC “hey you can take cover here.”
>>39165
>You don't want to program "use me as cover" into a rock scenery object, because a level designer can position that rock in a way that would make it unusable as cover, e.g. burying it mostly in the ground or placing it against/in a wall
If the level structure is static, you do this sort of precalculations for the whole level.

>doing multiple raycasts from the NPC to the player
>top-level system in the combat AI that looks for available cover and then assigns it to NPCs in combat. For that you could spawn a very simple "virtual" character (invisible) at the cover locations to run the kind of checks described above to see if the cover is valid. The system could then be checked by NPCs when they lack cover to find the closest/best option (in complex environments, you would probably want to store the cover options in a quad tree to make the search as efficient as possible). A cover option should be rated based on its distance (inversely proportional, ideally based on pathfinding distance) and how effective the cover is determined to be by your virtual NPC.
Thinking about this in a single-player context, how about this hacky way: You can just look at the scenery based on the POV of the human player, but much wider, and apply a shader that turns everything black that isn't an NPC and makes every NPC a unique garish color silhouette. Then do two-dimensional analysis with the pseudo-screenshot you got: How many pixels are exposed of whom and where are those pixels, near the center of the screenshot or near the edge of the player POV or outside? That gives you a measure of exposure (with distance baked in already).

But that doesn't yet take into account whether the player is seen by the NPCs. For that, we could do the same thing in reverse looking at pseudo-screenshots based on their POVs, but let's run a much cheaper check giving everyone an eyeball compass score based on whether they look in exactly the opposite direction as the player (high) or roughly opposite (lower). They might even score a zero, in which case they won't do a hiding action.

What else could go into the decision to do a hiding action: health and armed level (based on whether you are armed and if you got ammo and if so, how much; if not armed that's a level zero) and we should avoid dividing by zero, so the total scoring procedure looks like this:

(exposure × eyeball compass score) / (health × armed level +1) = hiding action score (HAS)

That score has to be above some threshold, aside from that we only allow up to X number NPCs to react by hiding at the same moment. We spawn some alternative poses for the NPC with the highest HAS, like ducking instead of standing, and moving a tiny bit to the left or right as well as back and forth. We check it with our shader-POV thingie and select the one pose that scores the lowest importance to hide (unless the current position is lower). After the position for that NPC is chosen, we do the same calculation of alternative poses for the NPC with the second-highest HAS (who can neither put a potential pose where another NPC currently is nor where the next pose of the one with the highest HAS is going to be), and so on.

>>39175
The image analysis method is extremely overkill especially since the game should know where all the opponents are. Even if you were going to use a method like that, it would make more sense to do a separate low-res image for each of them aimed in exactly their direction and using a rough estimate of how much screen space they should take up at a given distance. It would also tie the image data to the NPC instead of having to sort that out from one big image. Doing the checks individually would also mean that you don't have to do a whole sweep at once and only run the check when the AI of the NPC has moved to cover and wants to check if it's valid, plus periodic updates. This still seems like it'd be massively less performant than just doing a handful of raycasts which in context would be equivalent to a very low resolution screenshot.

And the other benefit of this is you could give the NPCs "foresight" by allowing them to check whether a spot would be viable by having an invisible dummy NPC spawn at the location when they scope it out. You can improve the performance by making the process take time in-game so that when the AI tells them they should find cover, they actually take several milliseconds looking at their various options. You can even give the NPC a cue to point their eyes and head toward the spots they are checking to give additional information to the player and make them feel more lifelike.

>>39175
>(exposure × eyeball compass score) / (health × armed level +1) = hiding action score (HAS)
The core idea is fine but the way you get the values could be optimized.

You could get an exposure value from the raycasts.

The eyeball compass can be derived from the player's average rotation, which you could just update each frame according to a rolling average calculation, like multiply previous value by 0.99 and add current value * 0.01 or whatever ratio you want. Realistically modeling this sort of thing is more where you'd use the screenshot type of method, to figure out what areas are exposed to the player character at their location, like a point light projecting outwards. This could also be baked into the level so that there are zones that have an associated "mask" applied to the navmesh to highlight optimal placement.

Health and armed level could also be modeled in a more dynamic way without that much cost, pretty hacky methods like average time between the player popping up to shoot. This would also mean that suppressing fire matters (especially if you incorporate location data for where the bullets are going), and would contribute to more ebb and flow in the combat pacing since you can help control when the NPCs are going to move.

>>39171
>Doom, Quake, etc are all challenging and interesting games despite the enemy AI in them basically being "if you see the player move towards them and attack
The single-player campaigns were like that, but the deathmatch bots got pretty sophisticated. When Quake III Arena came out in 1999, that game was only deathmatch and capture the flag and its bots were "aware" of weapons, ammo, health and could communicate through chat with you. See pdf.
>because most of the enemies has a unique purpose that creates interesting situations you have to figure out when you mix them together
Right. For instance, there can be different "magic skills", basically cheating to create crude models for guessing where the player is when out of sight:

1. Big Bubble: We draw a big sphere around the player actually is and randomly choose a point inside the sphere as the guess.

2. Slow Telepathy. We use rather accurate location data, but we delay the transmission to the AI.

3. Evaporating Trail. We put in a slowly evaporating trail that is following the player. It's invisible to the player, but the AI can "smell" it when standing inside of it.

If I had to choose only one of these, I would strongly prefer Big Bubble. That's because Slow Telepathy is thwarted by moving around and Evaporating Trail is thwarted by camping. Big Bubble looks robust. But a mix of some bots having the "magic skill" Slow Telepathy and others Evaporating Trail would also work.

Hmmm, what would a Pac-Man clone with these three AIs feel like?

>>39176
>The image analysis method is extremely overkill especially since the game should know where all the opponents are.
I said it's for single-player and was thinking about NPCs against the player only and not each other and only using the method for those NPCs registered in the pseudo screenshot. I don't believe that would be hard to do on hardware from twenty years ago. Maybe it's overkill in the sense of annoying to program rather than in the sense of eating much processing power.
>it would make more sense to do a separate low-res image for each of them aimed in exactly their direction
I agree with that low-res image is enough, but I do think that where the player looks should have weight. Remember I said the pseudo-screenshot would be broader than the actual POV of the player, so the approach isn't as limited as one might expect.
>give the NPCs "foresight"
They already have a tiny bit of foresight just because the pseudo-screenshot uses the broader POV, so they can also react to almost being seen. I admit this is not for foresight in the sense of planning something that takes more than two seconds to execute. It's barely more than a reflex.

I believe the most elegant way of NPC punishing both camping and "anticamping" (I mean running around a lot) would be directly scoring the player's behavior and shrinking or expanding the fuzzing factor applied to the player's actual location when generating the location guesses for NPCs to follow.

The area gets a virtual tamagotchi-resolution map that is initially grey. Over time, the pixels turn more and more pale. The pixels visited by the player turn black. This map's average brightness is the camping score. The brighter, the err campier.

NPCs tasked with punishing camping get less fuzzy location data of the player the higher the player's camping score is. NPCs tasked with punishing anticamping get less fuzzy data the lower the player's camping score is. NPCs that are jacks of all trades get less fuzzy data when the camping score is either very high or very low.

Somebody ought to make a shooter with a twist, where you wouldn't see much less defeat most enemies, to fuck with player.