3

Many games (such as Breath of Fire III for the PlayStation) have computer-controlled characters as members of your party. When you walk around the game, the others in the party follow your footsteps, apparently in the same path as you walked.

Frequently, however, these non-player characters get stuck in the environment. They may get 'caught' on a piece of scenery, or take a "wrong turn" at some point. BoF has two NPCs that follow the player, and deals with this issue by "teleporting" the stuck character to where the human player is now. I doubt the developers wanted the game to work like that: I'm sure they'd prefer their computer-controlled characters to follow the player character in a realistic manner. It seems to me that teleporting a character when they get stuck is more work than making the "pathfinding" routine solid.

Why was it not practical for the designers of this game (and others of the same era) to implement a fully functional pathfinding routine for their NPCs? I'd expect it to be straight-forward for them to just follow the human player's path, and thus not get stuck.

Additionally, what causes them to take different turns sometimes (apparently) since they get stuck in the environment? (If they did follow the same path as the player, they shouldn't get stuck, as the player evidently made it through.)

Kaz
  • 8,086
  • 2
  • 38
  • 81
T. F.
  • 67
  • 1
  • 2
    Another question at the crossroads of retrocomputing and arqade... do we need retrogaming.stackexchange.com? – fadden Dec 31 '20 at 19:12
  • 2
    @fadden no we dont; we need more traffic to this SE. – Omar and Lorraine Dec 31 '20 at 19:19
  • 7
    We need more actual retrocomputing traffic to this SE, not volume for the sake of volume. – dave Dec 31 '20 at 19:23
  • 1
    Without seeing the code, I can see some that might give this problem. The NPC might have a different size of collision box than the player. The NPC also have to check collision with the player and the other NPC when pathfinding. Depending on the game the NPC might also have a different movement speed than the player. – UncleBod Dec 31 '20 at 19:38
  • 4
    @OmarL No, we d onot need traffic at all cost, we need more retrocomputing traffic. As Fadden implies: retrogaming is not retrocomputing. – Raffzahn Dec 31 '20 at 20:39
  • 4
    @Chenmunka There are tons of "retrogaming" questions on this site. https://retrocomputing.stackexchange.com/questions/17526/why-didnt-snes-doom-use-mode-7 https://retrocomputing.stackexchange.com/questions/17516/did-the-saturn-fail-because-of-game-distribution-issues https://retrocomputing.stackexchange.com/questions/17483/why-the-50-60hz-speed-rule-didnt-apply-for-arcades-but-did-for-consoles https://retrocomputing.stackexchange.com/questions/17385/player-1-player-2-input-for-space-invaders just to name a few recent ones. What's wrong with you misanthropes? –  Jan 01 '21 at 18:28
  • 1
    According to the current guidelines , "Retrocomputing involves the restoration, preservation, history and maintenance of computer and gaming systems of yesteryear." (my bold), and "Questions are most welcomed on [...] how to use [...]" If gaming questions are not to be allowed, I think these guidelines need to be updated or at least clarified. – Dampmaskin Jan 04 '21 at 07:46
  • @Dampmaskin True, but isn't that rather a question about a game and it's usage, not a gaming system? As with many areas in life, there is a spectrum what fits and what not, and this question lies for many, including me, rather on the what not side. – Raffzahn Jan 05 '21 at 12:55
  • @user722 citing relevant examples might make a point, calling names doesn't. In addition, if you take a close look at all questions you mention, you may notice they have focus on hardware and/or history, not game play. For such Arquade is a way better forum - or maybe better, go ahead and propose a retrogaming site - I'll support that motion right away. – Raffzahn Jan 05 '21 at 13:01
  • 1
    @Raffzahn But "software, including [...] applications" is also mentioned in the "most welcomed" list. The list doesn't specifically mention games, but after a bit of googling, it seems that many or most sources do include games in their definition of applications. Again, if the guidelines indeed misrepresent the attitude of the community, I think the guidlines should be amended. – Dampmaskin Jan 05 '21 at 14:49
  • 1
    @Dampmaskin Erm, here is a little misunderstanding - in my understanding this question is about the game (gameplay, behaviour) or in fact about games in general, not a specific software. It's about generic programming considerations (which are in no way retro related as well), something Kaz' rather generic answer shows. As with anything in RL RC.SE covers a spectrum of issues. Compared to other SE sites a rather wide one. So decision about OT or not isn't a simple one but gradual. The same way as a question about the workings of a transistor are our of scope, game issues can be as well. – Raffzahn Jan 05 '21 at 15:02
  • @Raffzahn My answer had to be pretty generic, as I've never actually played the game quoted by the asker! – Kaz Jan 06 '21 at 10:42
  • @Kaz that wasn't meant as a negative critique to your answer. The problem is that the question is for one not really about a game, but game design/gameplay and in itself way too broad. – Raffzahn Jan 06 '21 at 14:14
  • 1
    @Raffzahn No slight was taken: I was just adding a little bit of context to my answer. :) – Kaz Jan 07 '21 at 15:35

1 Answers1

10

Firstly, on the "difficulty" of programming a teleport routine:

Teleporting an NPC when it gets stuck is actually a relatively straight-forward task to achieve. Identifying when an NPC has gotten caught is simple: you can calculate the Euclidian distance between the NPC and the player, and if it exceeds some threshold X, then you conclude that the NPC has gotten stuck and needs to be teleported back to the player. (Though it may be the case that the NPC is lagging behind, rather than trapped.)

Finding a suitable place to teleport the NPC to is a little more complicated to do - you don't want to teleport them into a wall, after all. Though I have no direct experience of this style of programming, I anticipate that it could be done by a combination of using the player's current location and orientation, adding an offset so they spawn behind the player, and using the game's existing clipping algorithms to ensure that the NPC isn't "out-of-bounds" relative to the player's position.

You might choose to zone particular areas of the map as being unsuitable for teleporting into, or alternatively use a whitelist of "safe" locations to teleport the NPCs to, and let them catch up with the player from the last teleport location they passed.

On why NPCs would get stuck in the first place:

The example you mentioned (Breath of Fire) has two NPCs following the player. These NPCs can't occupy the same space at the same time - not if we're aiming for realistic gameplay. And while you could write a pathfinding algorithm for the "permanent" structure of the level (rooms, corridors, etc), it wouldn't include moving objects that the NPCs would encounter.

The designers will have written some rudimentary AI to stop one NPC constantly trying to run through the leading NPC in an attempt to catch up with the player. In a game like GoldenEye for the Nintendo 64, where there are numerous NPCs, you could have two that each want to be where the other is stood (or somewhere beyond), and just try running through each other - at least until James Bond opens the door and shoots them both! That sort of unnatural movement and behaviour would break the player's suspension of disbelief.

Instead, when an NPC finds an obstacle between them and their immediate objective, they're programmed to respond in a slightly more realistic manner. An example would be for the NPC to turn slightly to the left, and try again to find a path to their objective. In the scenario of the two NPCs facing each other, if they both turn to their left they'll get out of each others' way, and can continue to their objective. These same collision avoidance routines are typically used for NPCs that are part of the player's party, too. Why reinvent the wheel, after all?

This illustrates how NPCs can stray "off the beaten path" that the player takes, in an attempt to respond to their environment in a realistic manner. Other ways they could get "caught up" or delayed when following the player include if their "hitbox" (which dictates whether they can stand on a ledge, fit through a gap, or be hit by a bullet) differs to that of the player, or if there are doors or platforms that operate on a cycle.

On the limitations of pathfinding algorithms for NPCs

While it is possible to calculate the shortest path for an NPC to take to catch up with the player, such calculations are not "free" - they have to compete for CPU time with everything else the games console is doing, such as rendering graphics, responding to user input, and calculating actions for all the other NPCs in the level too. Consider also the fact that these routeing calculations need to be updated as the player moves through the level. Spending ever more processing power on NPC AI would have diminishing returns beyond some given point, and with the limited power of early 3D consoles such as the Playstation and N64, you will reach that threshold sooner rather than later.

Even if you manage to route your NPC out of their trap, they can still end up lagging behind the player. If the player notices, and they want the benefit of having their party members alongside to help them through the level, they'll either have to stop and wait for the NPC to catch up, or (if they're still stuck) double back and go find them.

Encouraging the player to do either of those actions will break the flow of their gameplay, and probably leave them cursing the stupid NPCs for getting lost again. It is a more enjoyable experience if the game can make up for its technological shortcomings by teleporting NPCs back to the player. Ideally, if they reappear outside of the player's field of view, they might never know what happened!

Kaz
  • 8,086
  • 2
  • 38
  • 81